Re: [Anima] [media-types] Fwd: Thoughts on suffixes, single and multiple
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 On Behalf Of Michael Richardson
Sent: Thursday, April 4, 2024 1:22 PM
To: media-ty...@ietf.org
Cc: anima@ietf.org
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
Re: [Anima] Fwd: [media-types] 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
