On Thu, Jul 20, 2023 at 12:07 PM Brent Zundel <[email protected]> wrote: > So you don't need to register weird and useless stuff like +ld+jwt, or > +json+jwt if you don't have a need to use them by themselves... If that > changes in the future and someone really needs +ld+jwt... They can claim it, > by writing a specification and getting it to RFC. > > If the draft says this explicitly the problem with suffixes seems solved. > > Is it possible to get this language in?
Yes, as long as the various WGs agree with the change. I'll note that "application/vc+ld+jwt" would set a bad precedent as both "application/vc" and "application/vc+ld" don't exist -- and shouldn't exist as both are abstract data models (not serializations)... they are only realized when serialized to "application/vc+ld+json". Anyone attempting to register them needs to involve all of the communities that that particular discussion impacts. Suggestions to register "application/vc+ld+jwt" are problematic because they seem to presume that a downstream processor might know that when processing "application/vc+ld+jwt" as "+jwt", that handing off "application/vc+ld" further down the processing chain doesn't make sense and that they'd have to "fix up" the media type to "application/vc+ld+json" before sending it on for further processing... which they'd need special knowledge to do (and anything just processing as a +jwt wouldn't have that specialized knowledge, in many cases). That said, we should leave that discussion up to the WG that's registering the media type as long as it doesn't have a negative impact on the rest of the media type ecosystem (as long as it isn't setting a bad/dangerous precedent). We should probably ask them to explain why it's safe to do what they're doing and how systems just looking at the media type would be able to determine how to do structured suffix processing by just looking at the media type. In the end, it might just end up negatively impacting the community that chose the media type (that presumes a particular encoding associated with another registered media) in the first place. I suggest that the right thing to do here is probably require "+json+jwt"... but understand that is probably not going to be acceptable to the JWT community given that they've already registered a number of media types that don't fit that pattern. They might need to include language on "equivalent processing" when it comes to the end product of "+jwt" structured suffix processing... which could be "treat it as application/json even though +json doesn't exist anywhere in the media type" or "you can safely assume a +json at the end of the decoded media type and process accordingly if you want to process using the structured suffix rules". -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. https://www.digitalbazaar.com/ _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
