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

(as an individual / media type complexity enthusiast)

Parameters were discussed in the W3C VCWG and I think on this list
previously as potential alternatives, including some syntax proposed by Ted
and Joe from W3C that looks very similar to what you suggest.

The main argument against parameters is that you then have more complicated
parsing instead of simple string matching, and more error cases to
consider... In other words, worse interoperability, because of too many
alternative expressions of the same media type.

For an example that uses both suffixes and parameters, see:

https://www.w3.org/TR/activitystreams-core/#media-type

application/ld+json; profile="https://www.w3.org/ns/activitystreams"

This could have just been:

application/activity-streams

If that had been the choice and then later a CBOR encoding and a new
profile were needed, a suffix and a parameter could be added, when they are
needed, instead of anticipated in the initial registration.

Starting with a fully suffixed and parameterized media type, seems to
anticipate the success of the base and a need for alternative expressions
of it.

As a general rule, I would avoid parameters and suffixes, unless you have a
lot of evidence that they are necessary... Since once they are present you
have lost the opportunity for a simple and easy to match against media type.

Perhaps the convention of signaling suffixes has escaped for long enough to
memorialize it as a trend with advantages and disadvantages, but I don't
think we've seen near that amount of success for heavily parameterized
media types, except perhaps in AV codecs.

For example:
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/codecs_parameter

Regards,

OS

On Tue, Apr 16, 2024, 10:02 PM Darrel Miller <darrel@tavis.ca> wrote:

> As a follow up to the tests that I did to see if any of the major browsers
> respect +json, which they didn't, I tried the same experiment with +xml and
> got the same results.  None of the browsers I tried, used the +xml suffix
> to cause XML rendering.
>
> This leads me to feel like that we are debating over what is theoretically
> possible, but in the 23 years since suffixes were formalized, that
> theoretical value has not been widely realized. We do not have a clear
> guidance on what the suffix means.  For example,  +json and +gzip are
> achieving quite distinct goals. We have seen that introducing multiple
> suffixes has raised a range of new concerns that we do not have clear
> answers for.
>
> Most of the proposed uses of single and multiple suffixes that I have seen
> are either trying provide an encoding format that overlaps with
> Content-Encoding, or they are being used as a indicator to client or server
> of the specific format of some content where multiple contents are
> supported.
>
> An example of the latter scenario is what we have been trying to do with
> the registration of the media type for OpenAPI descriptions
> https://www.ietf.org/archive/id/draft-ietf-httpapi-rest-api-mediatypes-05.html#section-2.1
>
> The proposal is to register application/openapi+yaml and
> application/openapi+json.  This allows clients to conneg the format they
> desire and servers to advertise the format they are returning.
>
> However, upon reflection of all this conversation around suffixes, my
> question is why not do this?
>
> application/openapi;format=yaml
> application/openapi;format=json
>
> By defining an optional format parameter for the media type, we only have
> to have one registration, we get the same value and a client has the option
> to omit the format if either is supported.
>
> John Klensin made the comment in one of the recent IETF mediaman meetings
> that parameters for media types were created to prevent there being an
> explosion of media type registrations.
>
> Is there a reason why media type parameters cannot be used in many of
> these other use cases that are currently struggle to shoehorn information
> into suffixes?
>
> e.g.
> application/vc;format=jsonld
> application/did;format=jsonld
> application/voucher;format=json;sig=jose
> application/voucher;format=cbor;sig=cose
>
>
> I think suffixes were an experiment into encoding some meaning into part
> of a media type name that did not produce the desired results. I don't
> believe that if we decided to remove that meaning that anything on the
> internet will break.  Existing suffixes can remain, but I think moving
> forward we should be looking towards leveraging parameters, not suffixes
> for capturing meta information about media types.
>
> Darrel
> _______________________________________________
> media-types mailing list
> media-types@ietf.org
> https://www.ietf.org/mailman/listinfo/media-types
>