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

[Mark Nottingham <[e-mail]>]

Thanks, Manu - this is a good summary.

My leaning so far has been towards minimal (and somewhat drastic, albeit mostly backwards-compatible) solutions, but I'm not in-principle against a broader framework that would allow these different uses while avoiding security and interoperability issues. The biggest problem we seem to have is confusion around how to use suffixes, and the now many examples we have that show the impact of that confusion. 

Establishing that framework is going to take some legwork, careful consideration, and even more careful writing. It may mean, for example, that specific suffixes might have additional rules about how they're combined with other suffixes. We'll need guidelines for defining new suffixes and what they should document. And so on.

My concern at this point is that doing all of that is going to be a significant amount of work, and as we've seen many uses of suffixes only provide marginal value. 

Who's going to do the work?

The whole point of standard protocols is to have agreement on syntax and semantics, and there seems to be precious little of it here, as you point out.

Cheers,


> On 6 Apr 2024, at 00:54, Manu Sporny <[e-mail]> wrote:
> 
> 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.

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