[media-types] Thoughts on suffixes, single and multiple

[Mark Nottingham <[e-mail]>]

After the meeting in Brisbane, some of us went aside to continue to the multiple suffixes discussion. There, we quickly came to the conclusion that we should deprecate the concept of suffixes in media subtypes -- i.e., they would still be syntactically allowed, but would have no meaning or registry. Martin Thomson and I took an action to write something down about this.

Once I was home, I started to think more carefully about this and do research. One thing that I haven't yet seen is a summary of how suffixes are currently used (apologies if I missed someone else's effort there). These are the counts for each suffix in the registry that I came up with about a week ago:

+xml = 439
+json = 145
+ber = 0
+cbor = 16
+der = 1
+fastinfoset = 1
+wbxml = 7
+zip = 24
+tlv = 1
+json-seq = 2
+sqlite = 1
+jwt = 6
+gzip = 2
+cbor-seq = 4
+zstd = 0
+yaml = 2
+cose = 0

As you can see, we have a few very widely used suffixes (in a registry of 1,588 entries as of that survey), and many very seldom used ones - with a few not used at all.

The widespread use of +xml and +json in particular made me more cautious about deprecating suffixes altogether -- especially since we still sort-of believe that they are indeed used by (or at least potentially useful to) things like editors to hint syntactic conventions.

So, that leaves a few different options, considering the constraints we have:

1) Disallow more than one "+" sign in media subtypes, as floated at the meeting. This would put a fair amount of pressure on the registry's ability to reflect reality, depending on how widely deployed some things get (although we could grandfather some types in to ease the pressure here).

2) Syntactically allow suffixes before the last one, but not assign them any meaning or register them; e.g., application/foo+bar+xml would be an XML format, but who knows what bar is; effectively, it's just part of "foo+bar". This would allow people to define suffix-like things, but wouldn't give them any recognition or coordination -- potentially leading to the need to formalise things more down the road, just as we did in the first round of suffixes.

3) Consider multiple suffixes, when they occur, to be unrelated hints as to the syntax of the format -- i.e., there is no processing model, there is no ordering (although a registrant would have to choose an order; registrations with different orderings should be refused). Effectively, suffixes would just be a 'bag of hints' about the format being used. 

I'd be interested in hearing people's reactions to these. 

Separately, I think we need to settle a few other matters to make progress:


### Defining What Suffixes Are For (no matter how many there are)

After the discussion in Brisbane, I strongly believe that suffixes should ONLY be for hinting about the syntax or format convention in use, as an aid eg to editors, syntax highlighters, etc. This is the proven use case for media type suffixes. Suffixes should not be used to hint semantics; only syntax. We should have strong language about the dangers of using suffixes to hint particular kinds of processing; cf the previous discussion on the 'polyglot problem' and the potential security issues around performing processing based upon suffixes.

The suffix registration process should be designed to assure that only such suffixes are registered. 

Note that in this view, "+ld" is very likely unregistrable. 


### Cleaning Up Existing Suffixes

+gzip and +zstd are problematic; the former should be disallowed for new registrations, and the latter should be removed or obsoleted in the registry. Likewise, I am highly suspicious of +jwt and +cose. +zip _is_ a format convention, so I suppose it's OK?


Cheers,

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