Subject: [media-types] Feedback on draft-ietf-mediaman-suffixes-01

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Mar 2022 10:08:58 +1100

Hi all,

Taking a look at this draft, I have a few observations.

In section 2.1, the draft defines a processing module for suffixes, saying that they 'MAY be utilized in a processing pipeline where each segment of the pipeline handles a particular structured syntax suffix by applying decoding rules associated with the structured syntax suffix.'

What's missing here is text that describes the expectations placed upon a suffix definition so that it can be used in such a pipeline -- namely, a defined input and output format, with the implication that a media type can't be registered if there's a mismatch in the processing of the specified suffixes.

For some (indeed, many) suffixes, such a pipeline model doesn't make much sense. For example, while '+gzip' has a defined input format that leads to a deterministic output format, '+ld' and even '+json' are much less clear in this regard. Perhaps this could be addressed by indicating that such suffixes are merely indicative -- they don't have a place in such pipelines, so content effectively 'passes through' them.

We should also discuss and perhaps provide guidance about when to define a suffix, as opposed to a top-level media type. So far, registered suffixes have been format conventions and encodings, but with the proposal of '+ld' we seem to be drifting into indicators of a class of use, which seems very top-level-type-y to me.

Also, will this draft be actually registering any structured suffix combinations? If I read correctly, that's a requirement before a media type using one is registered (and if that reading is correct, it should probably be stated more clearly).

Cheers,

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