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

[Mark Nottingham <[e-mail]>]

The issue that I've heard about is that parameters are dropped in some contexts, meaning they can't always be relied upon.


> On 17 Apr 2024, at 13:35, Orie Steele <[e-mail]> wrote:
> 
> (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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types

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