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

[Manu Sporny <[e-mail]>]

On 2/18/22 12:55 AM, Martin J. Dürst wrote:
> So we would say that if you see image/svg+xml+gzip, then you first gunzip
> it, then you apply XML parsing, and then you apply SVG processing. Any
> combination of these steps is okay if the result is the same.

Ok, great, that's good direction.

> I would definitely want to avoid any kind of general operation on media
> type strings except the removal of suffixes from the right. What you do
> for something ending in +gzip may be the same or close to what you do for 
> application/gzip, but there's no guarantee that this works in general.

I understand the general concern you have and I share it.

Do we have any concrete examples of some "+foo" being applied in different
ways across media types?

> Again, please don't do that, because it doesn't work in the general case.
> So it doesn't work as a mental model.

Ok, good, that approach to explaining the mental model is dead, then.

I'll rewrite the section using what you're suggesting, Martin, and see if it
resonates with people better.

> I very much agree with registering things.

Ok, so the concept of sort of structured suffix registry isn't off of the
table. I'll integrate that into the next iteration of the spec.

> I think the registry should map the +xyz suffix (as an example) to xyz 
> processing, which may be xyz parsing or un-xyz-ing or something else.

Ok, I'll play around with some language to get that effect by going through
all the "+foo"s in the current registry and see if I can map all of them to
"processing" of some kind or another.

The only thing I'm worried about there is what you alluded to above, in that
"+foo" is not applied consistently across all media types. It's something
that's going to "quietly" fail unless we have a media type registrant step
forward and point out why the general rule doesn't work for their media type.

For example, "Oh, well, when we said +xml, what we really meant was XML with
the XLink extension)".

> The definition of this processing may be done by pointing to another media 
> type, but that shouldn't be required.

Ok, yes, that makes sense.

> So we would e.g. have a registry entry similar to the following. +gzip ->
> Revert gzip compression (usually the command gunzip, similar to processing
> application/gzip)

Right... I have enough to do a revision.

Anyone else on here think this is the wrong direction? It feels sane to me.
Russ? Murray?

-- 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/