Since the ServiceDescriptor object is the object in which the specifics about programs are to be stored, it is impossible for the authors of this standard to construct a ServiceDescriptor object for each and every use case. As a result, community sourcing of this attribute is needed.

Should there be a distinction drawn between how a servicedescriptor name is used? Eg. to follow the HTTP header standards, the 'well known' accepted values are named such as Foo, whereas unofficial/vendor specific/etc headers are generally denoted as x-Foo or similar.

Basically, the intention here would be to define it in such a way that 'well known'/defined keys are officially included in the standard, but then there is also a way for 'custom' values to be included in a way that won't clash with other implementations.

This could also be achieved using some form of project/domain specific prefix, eg. how java uses com.foo.bar.project type namespace notation for packages. Perhaps the prefix could be com.foo.bar.project:customKeyName or similar?

Eventually these custom prefixes could be collected/elevated into the 'well known' category, if they apply to more general usecases.