Where/how *.system and similar should be defined

[lmolkova]

Currently messaging.system and db.system are defined as enums, but it creates certain issues:

• stability: if *.system attribute is marked as stable, it does not mean that all of the tech-specific semconv are ready to be stabilized. E.g. kafka can be marked as stable, but azure_servicebus could still change.
• scope: OTel does not have to own/document/maintain extensions for all dbs or messaging systems. They could be defined elsewhere and OTel can link to them in the list of known systems

Proposal: #669

• *.system type changes from enum to string and no longer lists all members
• tech-specific extensions MUST define and document a specific value. They mature and stabilize independently from generic part and each other.

[Update]
Other attributes that share the same list of problems:

• cloud.platform
• rpc.system

[lmolkova]

One of the options is to add stability to individual enum members.
Then a subset of *.system can go stable (just the constants, not necessarily corresponding extensions), while others could remain experimental.

[pyohannes]

One of the options is to add stability to individual enum members.
Then a subset of *.system can go stable (just the constants, not necessarily corresponding extensions), while others could remain experimental.

I like this option, I think it provides the necessary clarity and flexibility.

[trask]

@lmolkova is this resolved now by open-telemetry/build-tools#267?

[lmolkova]

yes, thank you and closing it.