Re: [media-types] WG: More questions for multiple suffixes (Re: WG: IETF 112 agenda)

[Ned Freed <[e-mail]>]

> I can imagine some more questions that can be raised about multiple
> suffixes:

> - Is the namespace of suffixes itself a namespace (ie is there an unique
> definition of "+json" as a suffix)?

> RFC 6838 sction 6 says "yes".

And so does the current draft, albeit in a different way: It draws an
equivalence between all of the possible sufixes and a correspnding media type.
So a trailing +json is necessarily associated with application/json,
+ld+json with both application/ld+json and application/json, and so on.

I wish we're considered using this approach when we first specified suffixes.
It might have made things clearer.

> - Is the order of suffixes significant or meaningless (ie is vc+ld+json
> the same as vc+json+ld)?

> Draft seems to say that the anwer is "significant", +ld+json must be
> registered, and this attaches no meaning to +json+ld.

It's an unavoidable consequence of the way the mechanism is defined, but it
should be stated explicitly.

> - was suffixes a bad idea that we should abandon, attaching no special
> meaning to the + character?

> The number of registrations in
> https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml
> seems to indicate that even if it was true, it's too late to take this path.

And the fact that we (intentionally) haven't registered any media types with
multiple +'s in the name means it's possible to redefine the meaning of
multiple +'s as long as it doesn't break existing single +suffix usage. (And
I see no reason why it should.)

Of course it's possible there are unregistered media types with multiple +s
in the name in use. But if there are, it only really matters if the suffix
components are things that should be registered *and* the usage differs
from what we specify. I think that's unlikely.

				Ned