Clarify usage of "otel." attribute namespace

[tigrannajaryan]

I noticed developers adding their own attributes to this namespace
without going through the specification. We need to regulate this
namespace through the specification, just like we do it for other
semantic conventions.

[yurishkuro]

No objections, but what practical impact (aside from being a warning) do you foresee here? Do we need some prescription of how to handle the non-spec attributes that start with otel.?

[arminru]

Sounds reasonable to me but I also wonder about the practical implications as Yuri already stated.
Also, please mention this change in the changelog.

[Oberon00]

Nitpick: I wonder if you can call that an attribute. This string will only appear in the Jager/Zipkin exporters at which point its debatable if this is an attribute or another kind of key/value pair.

[tigrannajaryan]

It is supposed to be recorded in the same map (tags in Jaeger vocabulary) where we record attributes. So, it occupies the same namespace of attribute names. I am not sure if there is a better term for this, I am open to suggestions.

[Oberon00]

what practical impact (aside from being a warning) do you foresee here?

We might define an optional collector filter that discards/warns about unknown otel attributes? Although that might be useful only for testing and not an actual production deployment, as it would hamper forward compatibility.

[carlosalberto]

Looks good to me! let's merge this once the feedback has been addressed ;)

[bogdandrutu]

Overall LGTM, please resolve the comments :)

[tigrannajaryan]

No objections, but what practical impact (aside from being a warning) do you foresee here?

No other impact. Just a warning to prevent people from polluting "otel." namespace.

Do we need some prescription of how to handle the non-spec attributes that start with otel.?

We do prescribe behavior for each individual attribute (e.g. otel.library.name mentioned in the text). I do not think we need a generic prescription.

One more thing we can do is to refactor the spec a bit and have all otel.* attributes listed and defined in one place (currently we have duplicated info about otel.library.* for Jaeger and Zipkin exporter, with exactly the same prescribed behavior). This refactoring can be done in a separate PR (not directly related to this PR).

[carlosalberto]

@tigrannajaryan I think we are ready to merge this. Could you add a CHANGELOG entry before we do so?

[tigrannajaryan]

@tigrannajaryan I think we are ready to merge this. Could you add a CHANGELOG entry before we do so?

Done.