Add structured suffix

[OR13]

---

Preview | Diff

[OR13]

I have joined the group and signed the IPR agreement, but this change is indeed substantive.

[gkellogg]

We tried to do this in JSON-LD 1.0, but IANA wasn't prepared to allow such structured suffix registrations at the time. @msporny was the primary person driving this, IIRC.

[msporny]

We tried to do this in JSON-LD 1.0, but IANA wasn't prepared to allow such structured suffix registrations at the time. @msporny was the primary person driving this, IIRC.

Yes, and that led to this draft that allows this sort of structured suffix registration:

https://www.ietf.org/archive/id/draft-ietf-mediaman-suffixes-04.html

The specification above is reaching IETF Last Call, and so we need to test to see if the new spec will allow what we tried to register many years ago.

"+ld+json" is the first dry run of this new ability to register media types and structured suffixes with multiple plus signs. This PR places the structured suffix registration request into the JSON-LD Syntax specification such that we can trigger the IANA registration (as long as the JSON-LD WG is still ok w/ this registration).

[peacekeeper]

Yes this is useful.

[gkellogg]

@pchampin can we clear the IPR exception?

[gkellogg]

@OR13, you may need to set up your W3C account to know about your GitHub ID for the IPR validation to work automatically. I see you're listed as a participant, so I'm going ahead and marking it as complete.

[gkellogg]

(Never mind, it re-evaluated on it's own).

[OR13]

I don't intend to accept the change suggestions that add extra text to h2/h3 and make the sidebar look bad.

[TallTed]

I don't intend to accept the change suggestions that add extra text to h2/h3 and make the sidebar look bad.

I guess I will have to wait until PR#415 is merged (assuming it's accepted), and submit my own subsequent PR for the heading changes, to see what the WG prefers and the Editors will therefore apply.

[gkellogg]

The PR is on the agenda for the CH call this Wednesday. When considering @TallTed’s suggestion, I’d consider other similar registrations and look for some form of conformity.

[gkellogg]

The format of the YAML Media Type seems to match @TallTed’s suggested change.

[OR13]

The format of the existing registration matches mine.

[OR13]

The yaml spec isn't using respec, so it in general looks a lot nicer...

[gkellogg]

From the June 28th meeting:

I had a look at #415, but I'm a bit uncomfortable with the duplication with the application/ld+json registration.

This should probably be re-worked for less duplication, and needs an addition to Changes since the Recommendation of 16 July 2020.

[OR13]

@gkellogg are you able to suggest changes on the PR?

[gkellogg]

I can probably push commits to your branch, or do a PR into your branch.

[OR13]

The GitHub UI also has a suggest changes feature, which would allow me to commit your suggestion directly to the branch

[gkellogg]

The GitHub UI also has a suggest changes feature, which would allow me to commit your suggestion directly to the branch

Yes, IIUC, it only allows changes to lines that were already in the branch; this could be used for some changes, but not to add anything to the "Changes since ..." section.

[gkellogg]

The preferred practice is to have a "Security Considerations" section and reference this from the media type registration. We do have such a section, but it references this. We should basically move this content to the existing "Security Considerations" section and replace this with a reference back using "See ".

[gkellogg]

@OR13 I made some inline suggestions, and comments about further changes that should probably be made directly to your branch. If you agree, I'll do that. It would still leave some duplication, which could be managed by further extracting into common sections, but improves it quite a bit, otherwise.

Note that I expect we'll follow this PR up with some more editorial changes.

[OR13]

@gkellogg thanks for your suggestions, I merged the ones I could, and I authorize you to push whatever you like to the branch, and or reword any amount of this in subsequent PRs, I am mostly hoping to have a stable reference ahead of IETF 117 in case this comes up, so if its possible to merge (even with notes , issue markers or warnings before then, I appreciate it).

In the case it is not merged by 117 I will update IETF, that this is still in progress and might need to be updated depending on how WGLC goes for multiple suffixes draft.

[gkellogg]

This should just need @pchampin's approval, and decision on the suggestions for updating the contact in the registrations.

[OR13]

Awesome!

[iherman]

The issue was discussed in a meeting on 2023-11-28

• no resolutions were taken

View the transcript

1.4. Request profile parameter from application/vc (issue vc-data-model#1363)

See github issue vc-data-model#1363.

Brent Zundel: The current path we are on relies on media types with multiple suffixes.
… The spec for multiple suffixes in IETF has been more contentious than anticipated.
… And possibly a whole lot more work than anticipated.
… This issue is another path to sidestep this.

Orie Steele: This issue can be used with or without multiple suffixes.
… Our current registrations require multiple suffixes, even though this isn't possible at present.
… Even for application/vc the subtype can contain media type parameters.
… Those parameters can express characteristics of the media type.
… Specifying the text type is a common usage.
… This tracks the intended use of the profile parameter.
… We should provide guidance on the use of profile.
… We could say not to use it.
… We could say to use it in the same way as ld+json.

Brent Zundel: Thank you for clarifying the relationship between the parameters.
… We can register media types with multiple suffixes.
… The current interpretation of a+b+c is that a is the prefix and b+c is the suffix.

Orie Steele: we can request registrations that rely on multiple suffixes, but they cannot be registered, until their interpretation is clear... it is a mistake to request registrations that we know cannot be approved.

Ted Thibodeau Jr.: The first thing after the slash isn't what matters.
… The subtype is what's after the last + sign.
… There are multiple layers of subtyping.
… I don't know why the IETF did this.

Orie Steele: if you have questions regarding media types, you can ask the media type list. see https://datatracker.ietf.org/doc/draft-ietf-mediaman-suffixes/.

Ted Thibodeau Jr.: You process as many of the subtypes that you understand.
… This is complex and esoteric.

Orie Steele: +1 TallTed, its complicated : (.

Ted Thibodeau Jr.: The problem with multiple + signs is that the interpretation is undefined.
… There may be many more drafts.
… We can specify what our media types mean but those will only apply to people who understand our spec.
… It's to let people who don't understand what's to the left of the +s to still work with what's to the right of the +s.

Orie Steele: here is the repo: https://github.com/ietf-wg-mediaman/suffixes ... TallTed, eager to see your PR : ).

Manu Sporny: I am the editor of that spec.
… There is only one remaining issue.
… It's about whether to register all the things in between.

Dave Longley: for "application/vc+ld+json" processing is: "application", then "json", then "ld+json", then "vc+ld+json" ... another way to understand this subclass processing is: "application/square+rectangle+shape" ... you can understand any "application" content, then, if you want, more specifically any "shape", ... then any "rectangle" ... "square".

Manu Sporny: The chair of the WG wants to take it to last call.
… I don't think the multiple structured suffixes draft is in a place that it's not going to be ratified soon.
… Ted is right that we can just specify what our media types mean.
… We don't need to change anything about the media types used in the spec.
… The profile problem is problemantic.
… Many people don't prrocess it.

Orie Steele: My recommendation would be to not depend on multiple suffixes, we raised a PR to remove the dependency from vc-jose-cose ... w3c/vc-jose-cose#186.

Orie Steele: related registration for https://www.iana.org/assignments/media-types/application/ld+json.

Orie Steele: related specification Manu mentioned: https://www.w3.org/TR/activitystreams-core/#media-type.

Manu Sporny: You can have multiple different IETF registrations stomp over it.
… I realize we used it in JSON-LD. I wish we hadn't.
… We can tell people not to use it.
… What we've learned is that people don't implement it correctly.
… It's often destroyed or mangled as it goes through HTTP servers.
… We can only pick one filename suffix.
… We can't use profile to do that.

Orie Steele: feels like implementing profile correctly, is easier than using multiple suffixes consistently.

Dmitri Zagidulin: @orie - agree.

Ted Thibodeau Jr.: sighs people who don't conform to specs (e.g., by misconfiguring servers or otherwise breaking the profile option) should not be justification for not conforming to specs!

Manu Sporny: It's not easier to implement profile correctly, Orie. :) -- We have multiple decades of experience now that people don't implement it correctly.

Dave Longley: as long as multiple suffixes follows the rule that each subtype fits within the same wider syntax, things are kept clean (and correct) ... i think trouble has come from people thinking it's for enveloping, when it isn't.

Manu Sporny: ^ yes, that.

Manu Sporny: (to what dlongley said).

Dmitri Zagidulin: I want to agree with Orie that hierarchical multiple suffixes is way more trouble than it's worth.
… I don't think there's any need for hierarchical multiple suffixes.

Orie Steele: +1 ivan.

Dmitri Zagidulin: +1 to at risk.

Ivan Herman: If we want to keep multiple suffixes, we should put the whole concept as being at risk in the document.
… Put it as at risk.
… We can see what happens at the IETF.
… If it goes through at IETF, we can remove the at risk.
… Otherwise we can reconsider.
… We have to defend ourselves.

Brent Zundel: We're relying on multiple suffixes but not normatively pointing to them.

Manu Sporny: Note that JSON-LD has gone through multiple RECs w/ this in there: https://w3c.github.io/json-ld-syntax/#structured-extension-ld-json.

Ivan Herman: On the other hand, we are supposed to register media types we use during CR and we can't do it now.
… We can't ignore this.
… That's why we have to mark it as at-risk.

Orie Steele: I spoke to our W3C liaison at the IETF - Martin.
… It might be fine to go into CR that way.
… To become a recommendation, we have to finish the IETF work.
… It's OK to go into CR with the references are they are.
… If we have to correct this, it would be good to be able to do this without going through CR.
… If marking it as at-risk helps, let's do that.
… I don't know how the DID spec got to Rec with multiple suffixes.
… If this isn't resolved before REC, I will formally object.

Orie Steele: thats not true manu.

Orie Steele: I added the +ld+json structured suffix.

Manu Sporny: The DID and JSON-LD specs have gone through REC with multiple structured suffixes.
… You can treat it as an opaque thing.
… We can change it to application/vc if we need to.
… But that's doing the wrong thing.
… We should fix the IETF's broken suffixes.
… We should stop routing around this damage at the IETF.

See github pull request json-ld-syntax#415.

Brent Zundel: https://www.w3.org/TR/did-core/#application-did-ld-json.

Orie Steele: seems like the W3C is responsible for the broken behavior, and I agree that it needs to be fixed.

Orie Steele: I am trying to fix it FWIW.

Brent Zundel: The DID spec said that it will be registered as soon as the IETF spec is done.

Ivan Herman: The only thing I don't want is to go there and not even mention the problem.
… If we include a note like we did in the DID spec, that may be enough.

Brent Zundel: What are the steps forward for the profile parameter issue?
… We could prohibit their use or say how to use them.

Manu Sporny: We tell people how to use profile parameters correctly.
… Expect people to break this and it not to work correctly across the ecosystem.
… We should warn them that it has never worked out well when people rely on the profile parameter.

Ivan Herman: +1 to manu's direction.

Brent Zundel: We don't need to include doomsaying.
… We would need someone willing to be assigned to the issue.
… If you feel strongly that doing nothing is the right approach, then please volunteer to be assigned.
… If noone is assigned, then by default, we will be doing nothing about this.

Orie Steele: the media types impact the "verification algorithm".

Ivan Herman: All these options we are talking about are editorial?

Orie Steele: are they still editorial?

Brent Zundel: The media types affect the verification algorithm.
… We don't have anyone willing to be assigned.

Orie Steele: the reason I am not volunteering is that we are removing the dependency from vc-jose-cose.