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

[Manu Sporny <[e-mail]>]

On Fri, Apr 5, 2024 at 10:02 PM Mark Nottingham <[e-mail]> wrote:
> 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.

Yes, and the timeline for getting that right is undetermined. It's
boring plumbing work that needs to be done (or, at least, we should
make a concerted effort).

What we might end up doing is writing a bunch of text, as we have done
for multiple suffixes, and then after we feel we've documented the
meaningful variations (there seem to be about three-ish of them?),
decide that the whole thing has too much nuance, and is too
complicated to get right and/or police the registration of, and just
throw it all out, preferring simpler rules. A failure here would at
least establish that we did the work to explore the space.

Unless I'm mistaken, this hasn't been done before for suffixes (fully
documenting the classes of variations and the "goodness" or "badness"
of each variation, which is what I gather you were asking for during
the last IETF meeting, Mark)... so, we might as well give it a shot
and see where it goes (understanding that it'll be a rocky journey
that might result in failure).

> 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.

There is a trapdoor that we might be able to use... What if we propose
this for multiple suffixes:

If you choose to use/define a multiple suffix for a media type, your
registering specification MUST have a section in it that clearly
states how to interpret the multiple suffixes. That way, we push the
interpretation to each specification. The downside is that some specs
might do something super weird, so we can give them some established
design patterns to go off of (as I mentioned, there seem to be
three-ish of them).

If we don't use the trapdoor, yes, it'll be a lot of work.

> Who's going to do the work?

I'm happy to continue to volunteer to write stuff into the multiple
suffixes spec as a collection point for updated suffixes guidance. The
more important thing, however, is engagement from the media types
community to make sure we're doing something that is going to work for
all the suffixes use cases.

> 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.

I agree that there isn't consensus on ONE path forward, or ONE set of rules.

I'm hopeful that there might be consensus on a set of design patterns
for suffixes that don't undo several decades of suffix registrations.
It'll require some to hold their nose, but NOT doing something at this
point (there's clearly a problem here) feels like an abdication of
this group's responsibility to the Internet community.

Is it worth, as a next step, documenting the current design patterns
without determining whether they are "good" or "bad" yet? We could
start with:

* Syntax suffix pattern (+json, +xml)
* Container suffix pattern (+zip, +jwt)
* Multiple suffix pattern (vc+ld+json, did+ld+json)

I can take an action to do that if folks are supportive.

-- manu

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