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

[Michael Jones <[e-mail]>]

I believe that the media type suffix is useful for declaring that the syntax of a media type uses a particular data structure.  That's why, for instance, in the JWT BCP [RFC 8725] recommends that explicit typing be performed with media types using +jwt:

        "it is RECOMMENDED that a media type name of the format "application/example+jwt" be used, where "example" is replaced by the identifier for the specific kind of JWT."

I would be strongly against deprecating the use of suffixes in media types.  They are useful in practice and that horse has long since left the barn.

That said, I'm quite ambivalent about media types with multiple +s in them, and would be fine with us saying that no more of them will be registered.  Per my message https://mailarchive.ietf.org/arch/msg/media-types/cryCVgjewUShbc9u6XgPkeHmbeg/, when I tried to faithfully register multiple suffix media types for the W3C VCWG, the results were decidedly mixed.

                                Best wishes,
                                -- Mike

-----Original Message-----
From: media-types <[e-mail]> On Behalf Of Mark Nottingham
Sent: Tuesday, April 2, 2024 11:30 PM
To: IETF Media Types <[e-mail]>
Subject: [media-types] Thoughts on suffixes, single and multiple

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/

_______________________________________________
media-types mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/media-types