Closed brentzundel closed 3 months ago
Summary of the meeting at IETF 119 for those that were not in attendance:
This all started about a decade ago with JSON-LD. We wanted to register "application/json-ld" for the media type. IETF's Media Types group feedback was effectively: "Well, what you have is a media type encoded in JSON, so you should choose something with a "+json" at the end of it. The JSON-LD WG at the time said: "Ok, that's weird, but we'll do that, and selected application/ld+json
".
Later, when the W3C DID WG was under way, the group went: "Ok, based on IETF's guidance on suffixes, one serialization of this application/did
thing is a JSON-LD document, so, obviously, the media type is application/did+ld+json
, and when we went to register that, the IETF Designated Experts went... "Hmm, that's syntactically valid, but we don't have any guidance on how to interpret multiple plus signs in a media type, so we can't approve the registration."
At that point, the DID WG was asked to justify the usage of multiple structured suffixes, which were allowed, but not thought through cleanly when media type suffixes were introduced at IETF -- that was 5 years ago, it's taken 3 of those years to write up the rules on how to interpret multiple suffixes such that no one would object to what was written up.
We have now done this, reducing the open issue count on the spec down to zero, but new ones keep being raised (at the last minute during the IETF meetings) because a few people continue to feel "uneasy" about suffixes... and it seems like this is because there is a contingent of people at IETF that feel that suffixes were a bad idea to begin with, except that there are now multiple media types that use suffixes at IETF.
The latest set of suggestions are to:
+gzip
, and +zip
as "bad".At this point, the time it will take IETF to come to a conclusion on this has an unbounded time horizon. It might take one more meeting, or it might take many more years for IETF to figure out if they want to keep suffixes or not, and the VCWG cannot be coupled to a timeline like that.
Gory details (video recording of the meeting): https://youtu.be/xEGSm6oN7gw?si=DBpVIhmbVXK78j6j&t=600
There are a few paths forward that we could take:
IETF Media Types registration process would treat us as an "exceptional case" and grandfather application/vc+ld+json
and all the other media types for DIDs and VCs in while they sort out whether or not to deprecate suffixes, or multiple suffixes.
Pros:
Cons:
We could just register application/vc
, assert the same thing that we do in the specification today (that it's a JSON-LD document), and move on.
Pros:
Cons:
We could take a strong position in favor of multiple structured suffixes at IETF, use this as a use case for the need for multiple structured suffixes, help them figure out the language around suffixes and multiple structured suffixes, and stay the course.
Pros:
Cons:
I'd be in favor of Option A + Option C. 😃 As in, we need to be able to move forward and because multiple structured suffixes are a perennial request from many communities across the Web, we need to make sure this work at the IETF heads in an enabling direction and reaches the finish line.
Chair hat firmly off, I am a strong proponent of option B.
Chair hat back on, I would like the conversation to develop here and then in a couple of weeks we can have a discussion during a WG call.
On Mon, Mar 25, 2024 at 11:27 AM BigBlueHat @.***> wrote:
I'd be in favor of Option A + Option C. 😃 As in, we need to be able to move forward and because multiple structured suffixes are a perennial request from many communities across the Web, we need to make sure this work at the IETF heads in an enabling direction and reaches the finish line.
— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2018528604, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPFKP7EU4RM7IQ2CZ3K4TLY2BNBZAVCNFSM6AAAAABFCXNGN2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJYGUZDQNRQGQ . You are receiving this because you authored the thread.Message ID: @.***>
For vc-jose-cose, even if we register applicaiton/vc for use as the "cty" value, I believe we'd still want to use application/vc+jwt, application/vc+sd-jwt, and application/vc+cose for the "typ" values.
It's clear to me that suffixes make sense to express sub-syntaxes (of increasing specificity) of a super syntax. I tend to offer this sub-class analogy for how I think of it:
application/square+rectangle+shape
In this case, a square is a more specific type of rectangle and a rectangle is a more specific type of shape. In this same way, you could define the expression of an Animal in XML -- and add more specific characteristics for a specific Animal, say, a Dog:
application/dog+animal+xml
I think this is the useful way to use suffixes -- and that "The Right Thing To Do" is to say that this is the main use case for multiple suffixes and a good use of the feature. I'd say that we should either not speak to other use cases or discourage them (at least for now). I personally would have probably expressed the sub-classes in reverse order, but that's water under the bridge.
However, it does not seem to me that there's consensus on this understanding of multiple suffixes and I don't know if we can get there with little effort.
There are other people looking to use (or are already using) suffixes as a mechanism to express ("smuggle" in?) media type information about the content of envelopes or compression-style archive formats into a single media type (i.e., application/my-content+gzip
). I don't think we should do this because, in that situation, there are essentially two different documents/files/things: one is a container of some sort that contains the other one, the content of some sort. It's usually the case that these containers are designed to carry arbitrary content; there's a strong decoupling. I think it is better for container types, if desired, to include a field where the media type for the content is expressed -- rather than inventing a new media type for every possible combination of these things. This does not seem to be a scalable approach to me and I think it would ideally be discouraged for these reasons.
This problem does not exist when one is just expressing a sub-syntax of another syntax as a single, more specific media type that can then be consumed by broader applications (e.g., editors of Shapes/XML) and increasingly more specific ones (Rectangle/XML Animal consumers) or (Square/XML Dog consumers).
I think there is significant utility in being able to express sub-syntaxes in this way with few drawbacks. However, if we're not able to get to consensus on doing it, it's not the end of the world, it's just a shame that will probably generate more work and might slow innovation in various directions. That's an acceptable outcome, but not ideal. If there is significant push back on this approach, I think choosing Option A or B is the way to go with B being an unfortunate, but acceptable compromise to move things along.
The issue was discussed in a meeting on 2024-03-27
The issue was discussed in a meeting on 2024-03-27
@mnot @martinthomson please take a look at https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2023199001 , which goes some way towards providing what could become text regarding "What makes a good suffix? What makes a bad suffix?" in the multiple suffixes draft at IETF. Would text along those lines address some/all of your concerns? Or is there additional guidance we'd need to provide?
Can we pick not use this venue for the discussion? We also have https://github.com/ietf-wg-mediaman/suffixes and mediaman@ietf.org. I think that @dlongley's comment is constructive, but I don't want to fracture the discussion between venues.
(This opinion is mine, with my W3C staff contact's hat put down.)
I agree with @martinthomson: this issue is not the right place to have a discussion on the merits (or not) of multiple suffixes. The problem we have to decide on is: what should the WG do with the VC spec. As (most of) the rec-track specifications are in CR right now, it seems that we should not have a dependency on the IETF discussions; this would delay the timely completion of the WG's work.
Looking at the alternatives in https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2016612976, outlined by @msporny, option "B" is the most optimal as far as I am concerned. Version 1.1 of VC could be deployed without the introduction of multiple suffixes; we can do the same with Version 2.0. Also, as I said on the call, we can come back to this issue in future releases in case the IETF discussion eventually conclude in favour of multiple suffixes; we may want to add a note on that into the new, proposed charter of the WG to make it clear.
Also... I know it is not popular, it is not handy, etc., but we could register some profiles for the .../vc
media type if we feel it would really help implementations. That can be done at any time.
I prefer options A and C since as @dlongley said, there are sensible reasons for having multiple suffixes.
I prefer options A and C since as @dlongley said, there are sensible reasons for having multiple suffixes.
... except that their meaning is not specified by any existing standard (yet?). I do not think we can publish a Rec with it, unless we put our document on hold, hoping that IETF gives a green light to it.
I support option B.
Possibly with a redundant entry for:
application/ld+json with a profile, as is supported in activity pub today.
I prefer A+C mixed (not B).
@dlongley -- I'm still digging through the suffixes threads on the IETF media-types
mailing list and the suffixes
GitHub issues... If you haven't voiced some version of https://github.com/w3c/vc-data-model/issues/1462#issuecomment-2023199001 in one or more of those, please do.
The issue was discussed in a meeting on 2024-04-10
PR #1478 has been raised to address this issue. This issue will be closed once PR #1478 has been merged.
IANA registrations requested, per Wednesday's working group decision: https://mailarchive.ietf.org/arch/msg/media-types/_pmQrj8nkW25FOqIXmPa1wyzizU/
In this case, a square is a more specific type of rectangle and a rectangle is a more specific type of shape. In this same way, you could define the expression of an Animal in XML -- and add more specific characteristics for a specific Animal, say, a Dog:
application/dog+animal+xml
Looks like we're building an ontology of media types. That's a fair use case for this description with a long history. I like it!
The issue was discussed in a meeting on 2024-06-12
PR #1478 has been merged, closing.
After the mediaman meeting we need to revisit our media types and likely change them