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

Hi Murray,

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; for example, the most one can do with XML is make sure it's well-formed, pretty-print it, and if you're lucky, apply a stylesheet or check a schema if they're inline. You can also colourise the elements and attributes, I suppose. For JSON, there's even less (e.g., there aren't any rigorously defined hooks for applying a stylesheet or attaching semantics).

So I'm not excited about adding more complexity to names, or leading people to believe that the structure actually does something useful. The questions you ask are relevant, and are similar to other issues we've faced (e.g., when people try to make field name prefixes meaningful). I suspect people want to do this sort of thing mostly because it gives their format convention more visibility (because it will appear in more places) than any technical reason -- but I'm happy to be proven wrong there.

So I'm -0.5 on accommodating this; there may not be any great harm, but specifying it consumes resources and makes things more complex.

Getting some more data about how media type suffixes in general have fared, as well as details about the use cases being promoted, might change my mind.

Cheers,

> On 3 Jul 2020, at 3:29 am, Murray S. Kucherawy <superuser@gmail.com> wrote:
> 
> Before I joined the IESG, we (the media type reviewers) processed a request for a media type that included a "+" character.  Specifically, the request was to register "application/ld+json", and an implied media type suffix of "+ld+json".  This was a revision to an existing media type.
> 
> It included an implicit media type suffix registration, i.e., prose that said:
> 
> "Other specifications MAY create further structured subtypes by using +ld+json as a suffix for a new base subtype, as in application/example+ld+json. Unless defined otherwise, such subtypes use the same fragment identifier behavior as application/ld+json."
> 
> We had the applicant remove this text and instead suggest that they need to register "+ld+json" independently as a media type suffix, but that such a registration would likely be denied until such time as the community has had a chance to discuss its implications.
> 
> The question is around nested suffixes like this.  There's already a "+json", of course, but we should probably be clear someplace (maybe an "updates" document to 6838, maybe a revision) about how to process these if we're going to allow them.  One might think that "+json+zstd", for example, would do the "obvious" thing, but that's not the kind of thing that should be left to interpretation.
> 
> More generally, if I were to see application/foobar+a+b+c, should I be looking for one suffix called "+a+b+c", or three individually named suffixes, or other combinations, and in what order would they be applied, etc.?
> 
> -MSK
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types

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