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

[Manu Sporny <[e-mail]>]

On Fri, Apr 5, 2024 at 3:16 AM Mark Nottingham
<mnot=[e-mail]> wrote:
> I'll be interested to see people's reactions to these proposals.

There is merit to a number of Ted's proposals, and there are multiple
consistent ways to interpret suffixes and multiple suffixes.

The biggest problem right now is that we have so many legacy
registrations that "break" some of these "clean" proposals that it is
highly unlikely that we're going to get to a "clean" solution.

Every proposal that argues for a "bad suffix rule" will affect a
contingent of people that put them in the "bad suffix" camp for
reasons that they do not accept... and rightly so, as Mr. Dude put it
in The Big Lebowski: "Yeah? Well, you know, that's just like uh, your
opinion, man."

We are now re-hashing discussions that we've had before, with no
strong arguments for a single guiding philosophy. To review some of
the directions we could go:

* State that suffixes were a mistake or say they're just a notation
with no defined meaning

This won't fly because we have LOTS of registered media types with
suffixes and a non-trivial subset of people that registered them, or
were instructed to register them by the Designated Experts, seem to
think that they DO mean something. I would be surprised if we were
able to get anywhere near consensus on this approach.

* State that single suffixes are ok and that they identify the syntax
and nothing more

This doesn't solve for subtypes, such as JSON Schema, JSON-LD,
CBOR-LD, gzip'd data formats that already have plus signs in them, and
other legitimate use cases that do have well-reasoned thinking behind
what each level of the multiple suffixes means.

IOW, it draws this arbitrary line between single suffixes being ok,
but multiple suffixes being bad -- and the reasoning for why that is
bad (or good) has not been detailed yet (though Ted's response comes
close to what constitutes a good usage of suffixes and what
constitutes a bad usage of suffixes). I also expect Ted's well
reasoned approach to be rejected because it would put some already
registered suffixes into the "don't do this" bucket.

* State that single suffixes, and multiple suffixes, are ok and that
they mean something

We have people objecting to what multiple suffixes mean because they
would cause something bad to happen. I've yet to understand what bad
thing might happen based on the concrete text written in the multiple
suffixes draft. I do agree that we'd need to write more to establish
"good suffixes" from "bad suffixes", but that would take a reasoned
approach that would be rejected outright based on pre-existing
registrations falling into the "bad" bucket.

Which brings us to what's probably driving the strong reactions:

* Explain what constitutes a good suffix usage and bad suffix usage

I can't imagine that WGs that have produced specifications, that use
suffixes, that have followed the rules to this point, as vague as they
have been, would accept being labeled as a "bad suffix usage".

AFAICT, most of these structured suffix media types ARE deployed and
ARE used and no one has really complained about them until the
multiple suffixes started hitting the scene, and even then, the push
for/back on them has largely been academic. None of these approaches
seems like it would "Break the Internet(tm)" -- people might not agree
with the line of reasoning, but the code based on the suffixes draft
(as it exists today) is deterministic. The rules of what to do are
clear. The rules of what's allowable for registration are still not
clear.

Perhaps the path forward is to accept that we have different ways that
people think about this stuff and document that. There are some
subclasses of use cases that we have right now, some of them include:

* Suffixes used to express the base syntax of the data (no semantics):
+json, +xml, +jwt, +gzip, +zip
* Suffixes used to hint at the contents in an outer "container"
syntax: application/epub+zip
* The above, but the inner contents include a suffix (and a processing
model): image/svg+xml+gzip
* Suffixes used to express increasing levels of processing semantics:
application/vc+ld+json

The only thing that we seem to be able to agree on is that each of us
doesn't like at least ONE, possibly more, of those usages of suffixes.
Picking any one of them won't get consensus, picking and choosing a
subset of them won't get consensus, so perhaps what we're left with is
just documenting that each one of them has happened and how you, as an
implementer, can interpret the myriad of meanings of the plus signs in
a media type.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/