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

[Brian Campbell <[e-mail]>]

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]>
Date: Wed, Apr 3, 2024 at 7:43 AM
Subject: Fwd: [media-types] Thoughts on suffixes, single and multiple
To: Kristina Yasuda <[e-mail]>, Daniel Fett <
[e-mail]>, bcampbell <[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]>
Date: Wed, Apr 3, 2024 at 1:30 AM
Subject: [media-types] Thoughts on suffixes, single and multiple
To: IETF Media Types <[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]
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._