Consider: Banning usage of multiple suffixes

[msporny]

During IETF 119, @martinthomson noted that suffixes, and therefore multiple suffixes, might be a bad idea that should be deprecated.

One half-measure that the group needs to consider is banning the usage of multiple suffixes (because the rules on when to use them are more complicated than not having to deal with multiple suffix rules). IOW, it is being asserted that the benefits of the additional rules do not outweigh the drawbacks of having to understand them.

[martinthomson]

If we work out what to do with suffixes more generally, I don't see any reason that multiple suffixes couldn't follow. If we're eliminating the idea, then obviously multiple suffixes go away as well, but anything that is salvaged from one might still be useful for many.

[OR13]

Given JSON-LD is afaik the only serialization that uses multiple suffixes today, I think it might be easier to simply grand father it in, and then recommend against repeating the pattern for other serializations.

Something like:

+ld+json is a structured syntax suffix that indicates the full media type is JSON-LD, "JSON-LD is a concrete RDF syntax as described in [RDF11-CONCEPTS]. Hence, a JSON-LD document is both an RDF document and a JSON document and correspondingly represents an instance of an RDF data model."

There is no IETF consensus on the exact meaning of multiple suffixes. Based on feedback from W3C Tag and IETF Media types working group, new structured syntax suffixes SHOULD NOT be registered for polyglot media types.

• New principle: Discourage polyglot formats w3ctag/design-principles#239
• New principle: Text-based syntaxes should be designed to be usable by humans w3ctag/design-principles#453

[msporny]

Given JSON-LD is afaik the only serialization that uses multiple suffixes today, I think it might be easier to simply grand father it in, and then recommend against repeating the pattern for other serializations.

-1, I've discussed this with some individuals in the JSON-LD community and they are unwilling to register a pattern that is going to immediately be recommended against (if things go that way).

There is no IETF consensus on the exact meaning of multiple suffixes.

There is no consensus on:

1. What a "polyglot media type" is, nor agreement around the "goodness" or "badness" of "polyglot formats".
2. The rules for multiple suffixes.
3. What makes a "good suffix" vs. a "bad suffix".
4. What to do with the 600+ existing media type registrations that are (debatably) polyglots and that use suffixes today.

Based on feedback from W3C Tag and IETF Media types working group, new structured syntax suffixes SHOULD NOT be registered for polyglot media types.

There is no "W3C TAG" feedback, and no "IETF Media Types WG" feedback. At present, all we have are a handful of individual positions. Please be careful on how you represent individual positions vs. TAG/WG positions.

[hoehrmann]

Instead of multiple suffixes, it would be better to reserve a generic parameter for all media types to specify alternative valid interpretations of a given resource like Content-type: example/a; also#="example/b, example/c" where it is very unlikely that any registered (or unregistered, really) type already makes use of the new global also# parameter. Protocols that do not allow specification of parameters (I have probably seen this in some XML schemas eons ago), and thus cannot use this identification method, probably already have other problems, like that they cannot handle version parameters that are widely used.

[alvestrand]

Generic parameters are usually a Bad Idea, and "alternative valid interpretations" is something I don't think happens in practice.

I don't think that the proposal made was to ban suffixes, it's to remove the special meaning of the "+" sign, saying "if you want to know what this media type means, you have to look up its registration".

[hoehrmann]

If there is a dire need that multiple suffixes address, I think naming the relevant base types is definitely better than turning the right hand side of a media type into some kind of tag cloud (I came here after running across application/vc+ld+json+jwt).

I think it unfortunate that we have registered structured suffixes that do not follow the traditional »if you do not know example/x+y then process it like example/y« scheme (where example/y is a registered type). I would like to see suffix use restricted to that (and only one level of that).

I do not think that, say, web browsers will stop treating example/x+json as non-JSON because the type is unknown to them, so I am not sure how the Internet Community is served by removing +s special meaning.

As far as I can tell, right now there are no registered media types with multiple + signs in them (good).

It might be useful to turn https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-07.html into a document that explains the need that multiple suffixes are supposed to address, and discuss available alternatives. For instance, in HTTP there are alternatives for many situations (send a Content-Type header that matches something in the Accept header, Link: <>; rel="alternate"; type="example/b", or Alternates: {"" 1.0 {type example/b}} all with possible downsides of course).

[TallTed]

I think it unfortunate that we have registered structured suffixes that do not follow the traditional »if you do not know example/x+y then process it like example/y« scheme (where example/y is a registered type).

Yes. However, I think it not unfortunate that we have prospective (registration has not yet been approved) media types that extend that tradition to »if you do not know example/x+y+z, you can process it like example/y+z; if you do not know example/y+z, you can process it like example/z; in all of these cases, fragments are handled as described for example/z.«

I would like to see suffix use restricted to that (and only one level of that).

Why would you restrict to only one level? What's the harm you anticipate from the extension I describe above?

[msporny]

The use of multiple suffixes has been banned, we seemed to achieve consensus on this at IETF 120.