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

[Mark Nottingham <[e-mail]>]

> On 3 Feb 2021, at 12:06 pm, Carsten Bormann <[e-mail]> wrote:
> 
> 
>> 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.

Perhaps, but people make assumptions about conventions and build features based on those assumptions. That's when the fun starts.

>> 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.

Which brings to the fore -- what actual value does this convention, feature, whatever you want to call it, bring? Why are we structuring data and saying that it doesn't mean anything?

If the answer is "because people have started using this and we've painted ourselves into a corner" say so.


>> 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.

And I strongly suspect that as soon as this is allowed, people are going to start to build a processing model around the suffixes, and make other assumptions that extend media types in ways that aren't a good idea.

Anyway, the question was asked and I've said my piece.


> 
> 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.
> 

--
Mark Nottingham   https://www.mnot.net/