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

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Feb 2021 22:49:48 +0100

On 2020-07-03, at 03:19, Mark Nottingham <[email-masked]> wrote:
> 
> The argument for media type suffixes, as I understood it, was that it gave a way for generic parsers to somehow process the document based upon the more general conventions, even if they didn't know about the exact format in hand.
> 
> That always struck me as a fairly weak motivation;

Adding my .2 base points:

The argument that the argument for suffixes is weak is itself a little weak :-)

(1) If you don’t care about the suffixes, just use the whole of the subtype and ignore the plus signs.  Solved.

(2) If you do care about them, the hierarchy proposed does make a lot of sense.

(And, if you don’t care from a machine processing point of view, the scheme still generates a useful way to remember/decode media type names.)

I’m a little disappointed that this is taking us so long; JSON-LD is a format that is relevant for IoT-oriented specifications, and I would prefer if we don’t throw around unneeded process obstacles for using it for new media types.

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Feb 2021 10:46:32 +1100

> On 3 Feb 2021, at 8:49 am, Carsten Bormann <[email-masked]> wrote:
> 

I suspect it's turtles all the way down, Carsten - see below.

> (And, if you don’t care from a machine processing point of view, the scheme still generates a useful way to remember/decode media type names.)

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

If you can't articulate the actual utility brought by the proposed feature, alarm bells are ringing. 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. 

Furthermore, implementations will need to know how to handle ordering of suffixes; is application/foo+ld+xml the same as application/foo+xml+ld, or different? If someone registers one of them, can I still register the other? 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?

And so on.

> I’m a little disappointed that this is taking us so long; JSON-LD is a format that is relevant for IoT-oriented specifications, and I would prefer if we don’t throw around unneeded process obstacle…

Process obstacles are an annoying problem when they're in my way too.

Cheers,

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Feb 2021 02:06:53 +0100

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Feb 2021 12:03:45 +1100

> On 3 Feb 2021, at 12:06 pm, Carsten Bormann <[email-masked]> wrote:
> 
> 

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

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

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