Re: [media-types] Media subtypes containing "+"

[Carsten Bormann <[e-mail]>]

> Your argument seems to boil down to "it doesn't bother anyone, why not?"

Indeed.
But it seems to bother you, so let’s find out why.

> If you can't articulate the actual utility brought by the proposed feature, alarm bells are ringing.

It is not a feature, it is a convention.

> While what you say above may be true, adding new features to the architecture is not zero cost; people have to take on the cognitive load to understand the new feature, and given that it's poorly articulated, it's likely that will be non-trivial. 

I’m sure that there always will be enough people on this list that understand the convention that people registering new media types don’t have to.
People implementing media types named after this convention don’t need to understand it either — all the information about the media type is in its registration.
The convention just helps remembering the media type name, and, if you are so inclined, possibly helps in streamlining an implementation that needs to handle multiple media types of the same structure syntax suffix.

> Furthermore, implementations will need to know how

Actually, they don’t. 
You don’t “implement” structured syntax suffixes — you implement media types that have been named with this convention in mind.

> to handle ordering of suffixes; is application/foo+ld+xml the same as application/foo+xml+ld, or different?

I don’t think so, but most likely only one of those will be registered, so the question does not come up for an implementer.
If both are registered (unlikely, as the latter doesn’t seem to make sense), I would insist on text explaining the difference (whether structured syntax suffixes are used in their naming or not).

> If someone registers one of them, can I still register the other?

Sure, if you use the convention in the right way (as I said, unlikely in the specific case).

> Are there different forms of comparison, as there is for URIs? Does the chain of suffixes imply a processing model? Can someone who defines a suffix use it to imply a processing model?

All defined by the media type.
Again, media types don’t spring into life magically by defining structured syntax suffixes; a registration still has to use one for it to have an effect on the real world.


So I truly believe this is a zero-cost convention for those who don’t care about it.

Grüße, Carsten


PS.: We spent considerable amounts of time grappling with making the structured syntax suffix convention work for the names of all media types when SenML (RFC 8428) was defined.
We even wrote an (abortive) draft, https://datatracker.ietf.org/doc/draft-shelby-exi-registration/.
Find the odd one in what came out as RFC 8428:

   5.  JSON Representation (application/senml+json)  . . . . . . . .  13
   6.  CBOR Representation (application/senml+cbor)  . . . . . . . .  19
   7.  XML Representation (application/senml+xml)  . . . . . . . . .  21
   8.  EXI Representation (application/senml-exi)  . . . . . . . . .  23

But the trouble here was caused by the structure syntax suffix convention as is, and would actually have been eased if we had had a hierarchical way of naming available to us.