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

[Mark Nottingham <[e-mail]>]

Ted,

> On 5 Apr 2024, at 07:26, Ted Thibodeau Jr <tthibodeau=[e-mail]> wrote:
> 
> I wanted to put some *usage* statistics here, drawing on Google or other search engine for data about the media types they've encountered, but I cannot find a way to search on `Content-type` headers. The nearest I found was Google's `filetype:<type>` search term which is focused on filename extension, which is minimally helpful.
> 
> I think some analysis of what's out there on the (public) web, in actual *use*, would be far more informative than counting what is in the IANA registry, at present. (It would be great to also get some analysis of what's out there in various LANs, VPNs, and other non-public web, but this seems beyond hope.)

I gave registry information to inform a decision about suffixes' use _with relation to the registry_ -- anything we do has to consider current registry entries.

I suspect the data you seek will not be as useful as you might think; a media type being sent on a message only means that someone followed the specification of the format that minted it -- whether or not the suffix was actually used by software to do something useful is entirely separable, and as we've seen the most common suffixes are ignored by the most obvious software to use them (browsers).

> I would be strongly against this idea.
[...]
> I would be similarly strongly against this idea.

Statements like this aren't helpful in the IETF process. You need to explain why you're against them to convince others.

> I am disturbed by your suspiciousness, which doesn't seem to be based on anything more than goosebumps. Do your suspicions have any technical basis?

As I've explained a few times now, they don't appear to have any plausible use by generic software that doesn't recognise the full media type. If there are, it'd be great to hear about them. Absent that motivation, the obvious question is why it's necessary to surface this information.

> Structured suffixes are useful, and even necessary. When properly specified, they tell the consumer how to parse the document for internal fragment identifiers, vital for processing of Linked Data (including but not *only* JSON-LD), among other things.

When there are multiple structured suffixes, which determines what the fragment identifier is? The obvious answer here is 'the last one', but that begs the question about what the other suffixes are for, still.

> In clearer English, we could suppose —
> 
>    shape/quadrilateral
> 
>    shape/rectangle+quadrilateral
> 
>    shape/square+rectangle+quadrilateral

How does this square with 

   application/svg+xml+gzip

or even

   application/ld+json

... once there's another serialisation format for Linked Data?

> There have been some (to my mind) regrettable media type registrations, such as `image/svg+xml`, which degrades to `image/xml`, but which I think really ought to degrade to `application/xml`, meaning that its primary registration should be `application/svg+xml` *even though its desirably rendered content is an image*.
> 
> More regrettable, is the pattern of appending a compression or archive structured suffix on another media type. Consumption of these documents requires handling of the compression/archive structure — but requires no handling of the contents of the compression/archive document!
[...]
> (Further, it appears to me that the archive media types should probably all be converted from, e.g., `application/zip`, to `multipart/zip`, as they are indeed multipart!)

I'll be interested to see people's reactions to these proposals.

Cheers,


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