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

[Mark Nottingham <[e-mail]>]

> On 9 Apr 2024, at 00:53, Manu Sporny <[e-mail]> wrote:
> 
> On Sun, Apr 7, 2024 at 10:15 PM Mark Nottingham <[e-mail]> wrote:
>> No - what I'm saying is that whatever we put into the multiple suffixes draft, it should be extremely generic, so that it can accommodate all of these different uses.
> 
> Got it, some thoughts on that concept below...
> 
>> - No requirement to register combinations of suffixes; only each individual suffix is required to be registered
> 
> We had floated a variation of that proposal two IETFs ago and it did
> not achieve consensus from the Designated Experts. That is what led to
> the "MUST register all suffixes to the right" language in the multiple
> suffixes specification today.

Just to be super clear -- the experts don't have consensus about the content of the specification -- they don't have any special role beyond following its instructions. The consensus that matters is of the WG (and eventually the IETF). 

> While it does answer the question for "+xml+gzip", it doesn't quite
> cover the question regarding "+ld+json", does it (there is no such
> thing as a +ld suffix)?

In this straw-man approach, +ld would have to be defined. Of course, there are variations, e.g., we only require that each sequence of suffixes be registered (e.g., +json and +ld+json, but not +ld). I suspect it's going to come down to a) what approach gives us the properties we want, and b) what's easiest to understand/implement.

>> - No default constraints on how suffixes are composed / how they relate to each other / what the semantics of their ordering or position means
> 
> Yes, that seems workable as long as we say that the specification that
> registers the suffix must specify what the semantics of the ordering
> and position means. Maybe we add this as a field that's required in
> the registration request to ensure that multiple suffix usage has
> clear guidelines for how they are interpreted.

Yes, we'll need a list of what they need to consider. Don't know that's in the template -- I suspect it needs to be in the spec and reviewed upon suffix registration.

>> Does that make sense? I could see an argument for still requiring combinations of suffixes to be registered, but am hoping that if we do a good job on describing the individual suffix constraints, that won't be necessary.
> 
> Yes, it makes sense. As I mentioned earlier, there are multiple valid
> interpretations that make logical sense, we just need to find a path
> (or paths) that everyone can agree to. Whether or not combinations
> (such as +ld+json) need to be registered will be important to decide,
> but can be somewhat orthogonal to some of the other "simpler" multiple
> suffix usages such as "+xml+gzip".

+1.

Cheers,


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