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

[Michael Jones <[e-mail]>]

Not only is +sd-jwt planning to be registered, it’s used by a W3C specification for securing Verifiable Credentials.

I understand pushback on multiple suffixes, but using a single suffix to indicate syntax is useful, and common existing practice.

                                                                -- Mike

From: media-types <[e-mail]> On Behalf Of Brian Campbell
Sent: Wednesday, April 3, 2024 9:07 AM
To: [e-mail]; Orie Steele <[e-mail]>; Kristina Yasuda <[e-mail]>; Daniel Fett <[e-mail]>; Oliver Terbu <[e-mail]>
Subject: [media-types] Fwd: Thoughts on suffixes, single and multiple

Indeed there is work in progress that plans on requesting registration of "+sd-jwt" https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-structured-syntax-suffix-re based party on anticipated/suggested usage https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt#name-explicit-typing similar to "+jwt" that Mike mentioned here https://mailarchive.ietf.org/arch/msg/media-types/WgnX1lyhUMR2M82HRlsegEGg8j0/. And other work in progress that plans on requesting registration of "vc+sd-jwt" https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc#name-media-types-registry.  I suppose "+jwt" and the nascent "+sd-jwt" fall into the "seldom used" category mentioned by Mark (and those he's suspicious of) but they are used in practice and expected to be used going forward so deprecating them or the use of suffixes in media types would have ramifications with respect to that.




---------- Forwarded message ---------
From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Date: Wed, Apr 3, 2024 at 7:43 AM
Subject: Fwd: [media-types] Thoughts on suffixes, single and multiple
To: Kristina Yasuda <[e-mail]<mailto:[e-mail]>>, Daniel Fett <[e-mail]<mailto:[e-mail]>>, bcampbell <[e-mail]<mailto:[e-mail]>>

Please remind this group that you are about to register +sd-jwt, and give any comments that might support arriving at some kind of consensus here.

OS
---------- Forwarded message ---------
From: Mark Nottingham <mnot=[e-mail]<mailto:[e-mail]>>
Date: Wed, Apr 3, 2024 at 1:30 AM
Subject: [media-types] Thoughts on suffixes, single and multiple
To: IETF Media Types <[e-mail]<mailto:[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/

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

ᐧ

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.