Related to: open-telemetry/opentelemetry-java#6850

The env var configuration interface defines a variety of options related to exporter timeout settings:

• OTEL_EXPORTER_OTLP_TIMEOUT
• OTEL_EXPORTER_ZIPKIN_TIMEOUT
• OTEL_BSP_EXPORT_TIMEOUT
• OTEL_BLRP_EXPORT_TIMEOUT
• OTEL_METRIC_EXPORT_TIMEOUT

While the spec states that:

Any value that represents a duration, for example a timeout, MUST be an integer representing a number of milliseconds. The value is non-negative - if a negative value is provided, the implementation MUST generate a warning, gracefully ignore the setting and use the default value if it is defined.

Implying that zero is a valid duration in addition to positive values. However, there is no explicit mention of zero, and how to interpret it.

Does zero mean indefinite? If so, that's a really important piece of information for implementers.
Does zero actually mean zero, and represent a degenerate case which is valid but always ends up with timeout? This seems useless.

I think the more likely case is that the spec overlooked zero for exporter timeouts.

I propose we clarify that zero is an invalid duration for all exporter timeout settings, and characterize this as a bugfix. Any language implementation which doesn't validate exporter timeout at all, or accepts zero as valid can fix their implementation as a bugfix. If a language implementation is insistent that switching from no validation to validating that timeout is positive is a breaking change (I disagree but this is a hypothetical), then they can continue without adding the new validation. This would be similar to how we changed the default protocol from grpc to http/protobuf, carving out an exception for backwards compatibility.