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

[Michael Jones <[e-mail]>]

I think of it as a convenient naming convention that mainly helps the human beings involved choose reasonable and meaningful names.  For instance, I believe that the JWT BCP [RFC 8725] recommendation to choose names of the form "application/example+jwt" to explicitly type JWTs, where "example" is substituted with an identifier for your specific type of JWT, is useful to people developing new protocols and specifications.

I've never believed that the suffix alone should lead to processing of the data structure without considering the entire media type.

                                Cheers,
                                -- Mike

-----Original Message-----
From: Mark Nottingham <[e-mail]>
Sent: Wednesday, April 3, 2024 9:26 PM
To: Michael Jones <[e-mail]>
Cc: Brian Campbell <bcampbell=[e-mail]>; [e-mail]; Orie Steele <[e-mail]>; Kristina Yasuda <[e-mail]>; Daniel Fett <[e-mail]>; Oliver Terbu <[e-mail]>
Subject: Re: [media-types] Thoughts on suffixes, single and multiple

Is there a reasonable use case for knowing the syntax without knowing the specific semantics or processing model? E.g., an editors' highlighting mode (keeping in mind that we're not seeing great deployment for that in eg browsers for even +xml or +json)?


> On 4 Apr 2024, at 13:22, Michael Jones <[e-mail]> wrote:
>
> In general, you'll need to know what kind of JWT or SD-JWT the object is to process it.  For instance, you won't necessarily know where to get the keys and you won't know which claims are required and optional, and importantly, you won't know the processing rules for those claims - for instance, what can you do (and what are you REQUIRED to do) with the "iss" (issuer) claim value.
>
> But yes, you will know the syntax from the structured suffix.
>
>                                -- Mike
>
> -----Original Message-----
> From: Mark Nottingham <[e-mail]>
> Sent: Wednesday, April 3, 2024 5:19 PM
> To: Michael Jones <[e-mail]>
> Cc: Brian Campbell <bcampbell=[e-mail]>;
> [e-mail]; Orie Steele <[e-mail]>;
> Kristina Yasuda <[e-mail]>; Daniel Fett
> <[e-mail]>; Oliver Terbu <[e-mail]>
> Subject: Re: [media-types] Thoughts on suffixes, single and multiple
>
> So that focuses nicely on the relevant question -- is +sd-jwt (and by extension, +jwt) really just flagging syntax, or is implying that the format can be processed in a certain way?
>
>
>> On 4 Apr 2024, at 03:54, Michael Jones <[e-mail]> wrote:
>>
>> 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 herehttps://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/.
>> i%2F&data=05%7C02%7C%7Cc5eb654f5eaa41eb95b208dc545f6b83%7C84df9e7fe9f
>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638478016017710679%7CUnknown%7CTWFpbG
>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>> %3D%7C0%7C%7C%7C&sdata=fKFYLDvBR2xtV5IlKj%2FLdk%2FRyit5T5y%2BqG%2FNqa
>> pJxk4%3D&reserved=0
>> etf.org%2Fmailman%2Flistinfo%2Fmedia-types&data=05%7C02%7C%7C37943bd4
>> 6
>> 64d44bcaee208dc543cdc0e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C
>> 6
>> 38477867572436078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
>> i
>> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=o5%2Fa46bYK
>> %
>> 2FJOMigYEiT0tdNdyZXmycB4h%2BAgCZDNEuU%3D&reserved=0
>> ᐧ
>>
>> 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.
>> _______________________________________________
>> media-types mailing list
>> [e-mail]
>> https://www/.
>> i%2F&data=05%7C02%7C%7Cc5eb654f5eaa41eb95b208dc545f6b83%7C84df9e7fe9f
>> 640afb435aaaaaaaaaaaa%7C1%7C0%7C638478016017715075%7CUnknown%7CTWFpbG
>> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>> %3D%7C0%7C%7C%7C&sdata=o5GSUjzZVAP%2FPN1ZzmEp7KaA%2BBrQGzUrOu8BblpzzQ
>> Q%3D&reserved=0
>> etf.org%2Fmailman%2Flistinfo%2Fmedia-types&data=05%7C02%7C%7C37943bd4
>> 6
>> 64d44bcaee208dc543cdc0e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C
>> 6
>> 38477867572440485%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
>> i
>> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CmWz15MPLfi
>> J
>> 6sa%2FoXg9g1UjGb9x2noXBK66avS0axI%3D&reserved=0
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>

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