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

[Michael Jones <[e-mail]>]

Michael R., you wrote:
> 1) application/voucher-cms+json  aka voucher+json+cms?

I don't think these make sense since CMS is X.509 - not JSON.  You could reasonably use application/voucher-cms or application/voucher+cms.

> 2) application/voucher+cose      or? voucher+cbor+cose?

application/voucher+cose would make sense.  I don't think the +cbor adds anything useful here.

> 3) application/voucher-jwt+json  aka voucher+json+jwt?

Neither of the above make sense.  JWTs are sequences of base64url-encoded characters separated by periods.  They are not JSON.  application/voucher+jwt would make sense.

                                -- Mike

P.S.  Note that my response is about the specific possible media type names and doesn't really touch on the general questions being discussed in the thread.

-----Original Message-----
From: media-types <[e-mail]> On Behalf Of Michael Richardson
Sent: Thursday, April 4, 2024 1:22 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [media-types] Fwd: Thoughts on suffixes, single and multiple


original, entire thread, for ANIMA people:
https://mailarchive.ietf.org/arch/msg/media-types/iWc8TLcWOyO0jyqeiuF9VCZClIs/

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

uhm. okay.
We in ANIMA have been struggling because we have an artifact, a voucher (YANG defined in RFC8366, being revised/extended in 8366bis), which can be in two major formats: JSON and CBOR (in theory, XML too), but can be signed by three formats (CMS, JWS, COSE).

That gives us three major variations today:
1) application/voucher-cms+json  aka voucher+json+cms?
2) application/voucher+cose      or? voucher+cbor+cose?
3) application/voucher-jwt+json  aka voucher+json+jwt?

(because CMS signing CBOR seems dumb, as does mixing {JSON,CBOR} X {JWS,COSE})

We didn't know if we should resort to multiple suffixes or not, and the lack of apparent progress on this has been a pain.  So, thank you for the decision as it takes the options off the table, I guess, even if I'm bit surprised by it.

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

Also, +gzip makes it pretty clear you can maybe do something with it, if you just know how to decompress.

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

I suggest keeping +gzip and +xml.

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

It doesn't seem any different than foo-bar+xml to me.

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

Not that useful, but I could live with it.

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

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

Well, it also helps forensics and dissectors; but I accept that in essence, those are just specialized kinds of "editors"

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

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

!

    mnot> ### Cleaning Up Existing Suffixes

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

So, +jwt and +cose says, "this is a signed object, and if you look in the payload slot, you might find something you might know how to decode" (or not)

But, for many formats they only appear in a signed form in the wild, so maybe this just doesn't matter.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide