New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do VCs still need Media Types with Multiple Suffixes? #1364
Comments
Nothing needs multiple suffixes, they are hints for specific processors (such as browsers) to provide a better experience than downloading a file... that makes them a nice to have imo. https://www.w3.org/TR/activitystreams-core/#media-type
|
As I wrote at https://mailarchive.ietf.org/arch/msg/oauth/vDitVdgDfL4ZXzPdvquoCj_fYbY/, I believe it would be better to update our registrations to prohibit the use of media type parameters, to increase the likelihood of interoperability. |
I agree with @selfissued. Implementers ignore media type parameters a non-trivial amount of the time. They are mauled by middle-boxes in unexpected ways (usually removed). We used them for JSON-LD, which was (IMHO) a mistake that optimized on the belief that implementers would get it right most of the time (they didn't). Use of media type parameters is always well intentioned by specification authors, and then botched by a non-trivial number of implementers. I might be ok with saying that people can use them (but cringe at the possibility), and suggesting how to use them, but we shouldn't specify algorithms and write software that counts on their proper usage. |
@jyasskin wrote:
I'm the (reluctant) Editor of that specification. It's taking longer than any of us would like, but we're down to one issue: whether or not all suffixes in a chain of structured suffixes need to be registered (via concrete specs), needs to be registered (but some can be a no-op), or not be registered (which received objections during IETF 118). The IETF MEDIAMAN Chair would like to take it to IETF WGLC before/during IETF 119.
We don't have to wait for MEDIAMAN to figure out multiple suffixes. DID Core went to REC w/ this note: https://www.w3.org/TR/did-core/#application-did-ld-json ... we can do the same here. BUT, I expect we won't have to this time based on all of the effort that's gone into suffixes since DID Core v1.1.
It's doing important work, namely:
All that said, I do acknowledge that we have a problem w/ Do you find any of the arguments above compelling @jyasskin? |
I don't mean to take a strong stance here; just wanted to make sure the WG still wants them. On |
I maintain my position that ZIPs don't get subtyped based on their content; neither should SD-JWTs. |
Note that ( |
My understanding is that media type [multiple-]suffixes are for signalling subclasses (more restricted expressions of a flexible syntax) that do not have to be used or understood by more general consumers of the flexible syntax. By way of example: For the media type:
This is fundamentally different from a media type such as this (which I consider erroneous usage):
Whereby "Note consumers" and "Envelope consumers" would be unable to consume this payload -- and only "Mailtruck consumers" could. In my view, using media type [multiple-]suffixes is not for use cases that involve wrapping a data format in another wrapper that changes its syntax / general structure, etc. (aka "an envelope"). |
The issue was discussed in a meeting on 2023-12-06
View the transcript2.7. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)See github issue vc-data-model#1364. Orie Steele: I would suggest keeping this issue open. We need to know if our registration will be accepted or not. Brent Zundel: I'm interpreting that as before CR. Ted Thibodeau Jr.: There's nothing prohibiting making registrations with multiple suffixes. The question is about how those are going to be interpreted. |
The issue was discussed in a meeting on 2023-12-13
View the transcript2.5. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)See github issue vc-data-model#1364. Brent Zundel: do VCs still need media types with multiple suffixes. Manu Sporny: I think we still need media types with multiple suffixes.
Manu Sporny: this group will need to decide what media types to request.
Ted Thibodeau Jr.: doing my best to get it done this week. Brent Zundel: any other IETF PRs we want to discuss? |
closing per discussion during last call |
Right now, the VC media types are
application/vc+ld+json
andapplication/vc+ld+json+sd-jwt
. This relies on https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-06.html to define what it means to have multiple+
s in a media type, and it sounds like that draft is having trouble getting to consensus over in the IETF.The
+ld+json
bit of those media types isn't doing much work. It could tell a generic JSON or JSON-LD processor that they could give better debugging output by rendering in those formats, but they won't be able to parse the VC. Back in VC 1.1, they might have been useful to distinguishapplication/vc+json
fromapplication/vc+ld+json
, but that's no longer relevant for VC 2.Might it speed things up to use the
application/vc
andapplication/vc+sd-jwt
media types instead, and avoid waiting for the MEDIAMAN WG to figure out multiple suffixes?The text was updated successfully, but these errors were encountered: