Re: [media-types] I-D Action: draft-ietf-mediaman-suffixes-00.txt

[Manu Sporny <[e-mail]>]

On 2/16/22 5:52 PM, Murray S. Kucherawy wrote:
> The prose in the Abstract and elsewhere says this updates RFC 6838, but
> it's not shown that way in the front page header.  Please add that.

Fixed in
https://github.com/rhiaro/draft-w3cdidwg-media-types-with-multiple-suffixes/commit/711f5391915265e4d7d81423c7df46ed55832a4c

> I think Section 2 is fine, but I'm confused by Section 2.1.  Let's ignore
> the multi-leveled thing for the moment.  I've always read "foo/bar+baz" as
> "a foo/bar, encoded or expressed using baz".  Or put another way: Take
> this payload and apply the inverse of "baz", and I should get a "foo/bar".
> This section seems to suggest the idea that if I don't know what a
> "foo/bar" is, maybe I know what a "foo/baz" is, and I should try that.  Why
> is that the right thing to do here?

Hrm, yes, I understand the issue you're raising. Section 2.1 attempts to
provide a mental model for people to think through how subtypes might be
applied. It sounds like the mental model doesn't gel with your one, which also
makes sense to me.

What we were going for was basically saying:

If you don't know what a foo/bar is, but you do know what a foo/baz is, then
you can process it as foo/baz (because there are known processing rules for
foo/baz).

Let's take Russ' recent example w/ application/svg+xml+gzip:

If a client gets a file off of the Internet, and it it sends it to some
processing back end, the back end can respond with two basic responses:

* I know how to process that media type, or
* I don't know how to process that media type.

So, let's say that the back end process doesn't need to understand all
application/* out there... it just needs to understand the basic encoding to
know what to do with it. So, let's say all your archival program wants to do
is store gzip files off of the Internet.

The way the current rules are written seem to indicate that an application
needs to understand the ENTIRE media type in order to process it. What the
current spec is trying to say is: That's not necessarily true, you can
understand part of the media type and process it.

So, instead of the archival system that stores gzip files going, "I don't know
what an 'application/svg+xml+gzip' bytestream is"... it can instead say "I
don't know what an 'application/svg+xml+gzip' bytestream is, and I don't know
what an 'application/xml+gzip' bytestream is, but I do know how to process an
'application/gzip' byte stream, so I'll do that.

Now, that all falls apart if someone can provide an example of where it is not
acceptable to do that sort of processing... or, clearly, if many people on
this mailing list revolt and suggest an alternative mental model for thinking
about all of this.

Does that make sense, Murray, or did I not do an adequate job of explaining
the mental model (or 'no' to both)?

> For Appendix A, it's a little curious for an author to be thanking
> himself.

Snoop Dogg takes issue with your position, MSK:

https://www.youtube.com/watch?v=NfF3bThOW0Q

:P ... but seriously, it came from a time where Amy did the first draft of the
spec and I was trying to help convey what the spec should say. I've removed it
in the latest commit, because yeah, while it made sense a few years ago, it
doesn't make sense today:

https://github.com/rhiaro/draft-w3cdidwg-media-types-with-multiple-suffixes/commit/4d68c56d390192a88f5a21331af53512dc0d39f0

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/