Remove mentions to media type parameters

[msporny]

This PR addresses issue #1363 by ensuring that the use of media type parameters will result in a verification failure.

---

Preview | Diff

[OR13]

What about protocols that need to signal profiles of this specification?

What guidance do we provide for profiling?

Will it be ok to add profile in VCDM v3?

[msporny]

You requested that parameters are banned in this comment. I was implementing what you requested.

Data model "profiles" are currently signaled via @context.

We could add profile back in v3 by changing the algorithm and switching off of the @context version.

Exactly what sort of profiles do you foresee?

[OR13]

I think it would be preferable to serve profiled data, without the need to sniff the context.

a profile parameter should be registered for application/vc+ld+json and when present, the verification algorithm should reject verification calls for media types it does not understand.

[msporny]

So, when you said: "I prefer the validation / verification algorithm to explicitly prohibit parameters", you meant the opposite of that?

Please provide concrete examples of whatever you want to do, because it's not clear if you are trying to profile encoding mechanisms, securing mechanisms, data models, transport models, operational models, or something else. Media type parameters can affect all of those things, which is why it's often a bad idea to use them (it leads to a proliferation of non-interoperable profiles).

[iherman]

Are we discussing V3 issues? Isn't this a bit premature when V2 is not in CR yet?

I must admit I am also lost what we want and what we do not want.

I also note that if we are talking about a new feature that has not been discussed before, that should automatically be considered as a V3 issue. We have been in feature freeze for V2 for quite a while now...

[msporny]

I also note that if we are talking about a new feature that has not been discussed before, that should automatically be considered as a V3 issue. We have been in feature freeze for V2 for quite a while now...

Agreed. The only reason I raised this PR is because @OR13 explicitly asked for it in a before-CR issue about the verification algorithm (which is only in scope due to the potential for an FO). It now sounds like the request has turned into a new feature request to use the profile parameter.

[OR13]

To be clear, my original request was in relation to the media type registration request.

When requesting new media types, you need to consider if parameters are allowed.

Given that +ld+json implies profile, my request was to acknowledge this explicit.

If we are saying profile is forbidden for vc+ld+json, in the registration, the text in this PR is good to be merged as is.

[OR13]

hopefully the fediverse stops using profile

[TallTed]

I hesitate rather a lot to ban use of a technology feature (here, media type parameters, specifically profile) which must have had good things to be said about them or they would not have passed IETF RFC muster, just because we (who presumably were not part of that earlier standard development project) cannot think of any reason why we might want them ... and especially because I believe I have already offered a couple of points (which I cannot bring to mind just now, hard as I try) where I thought they could be quite useful in VC arenas.

As in many spaces, it seems the adage "if you can't think of anything good to say, say nothing" applies. In other words, don't require that anyone/everyone use the thing you won't or can't use, but don't forbid others from using that same thing.

At the moment, I'm a strong -0.99 and could easily be tipped over to a -1 and/or a formal objection on this proposed forbiddance without a much stronger argument than the conjecture that "allowing media type parameters might decrease VC interop" and that some folks don't like their taste.

[jandrieu]

Why are we forbidding things here?

[iherman]

The issue was discussed in a meeting on 2023-12-12

• no resolutions were taken

View the transcript

2.3. Forbid use of media type parameters (pr vc-data-model#1382)

See github pull request vc-data-model#1382.

Manu Sporny: I thought Ted was a -0.99 and I agree.
… I don't like this PR. I raised it because Orie asked.
… I think the group just shouldn't say anything about it.
… Why are we telling people not to do something that people might find useful.

Dave Longley: +1 to Ted's rationale and Manu's support of it ... i think we're trying to say more than we need to here.

Manu Sporny: This feels like a time sink.
… Orie has said this would let us subprofile.
… But, please, let's not do that. Feels like a bad direction.
… Also, "+JSON+LD" would let you sub-profile, so we should.
… But I don't think we have a good use for it in this group.
… if someone wants to profile the VCDM, they should do that and get implementation experience.
… suggestion is to close this PR.

Dmitri Zagidulin: +1 to closing the PR, do nothing.

Dave Longley: +1 to Manu's suggestion to close the PR.

Dmitri Zagidulin: it was done in response to a mis-interpretation of Orie's comment.

Ted Thibodeau Jr.: Yes, please lets close this.

Brent Zundel: dmitriz also noted he was +1 to close.
… I'm adding a pending close label to this PR.
… next up 1383.

[msporny]

This PR needs to be updated to remove mentions to media type parameters.

[iherman]

The issue was discussed in a meeting on 2023-12-13

• no resolutions were taken

View the transcript

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

See github issue vc-data-model#1363.

Brent Zundel: request profile parameter for application/vc+ld+json.

See github pull request vc-data-model#1382.

Orie Steele: see this recent cg draft using profile: https://www.w3.org/community/reports/json-ld/CG-FINAL-yaml-ld-20231206/.

Brent Zundel: not sure about the course this is taking.

Orie Steele: I think that PR is on a good track, Manu's attempting to address ambiguity, forbid profile parameter. From a design perspective, bad to say extensibility for profile is internal to media type. For awareness of the group, JSON-LD CG just published for YAML-LD that also registers profile parameter. I think it's a best practice to inherit the profile parameter the way all the other media types tend to support it and then say, when it's present, it has to be interpreted in some way and if you don't have a need for it, don't use it. That would be my recommendation. This will impact registration of media types, since we're first through the door on multiple suffixes, it would be wise of us to be explicit about profile parameter.

Ted Thibodeau Jr.: I am very confused by orie's comments.
… the PR is titled forbid use of media type parameters.
… I take issue with forbidding parameters, media type parameters should not be forbidden'.
… some content still needs to be changed.

Manu Sporny: seems you are missing context from the special topic, there was pushback forbidding media type parameters.
… you seem to want to address profile, not forbid media type parameters.
… we had too many objections to forbidding the profile parameter.
… we tried to resolve to say nothing.
… i believe orie wanted us to provide guidance on the profile parameter.
… in case the media type parameter is inherited from the suffix.

Dave Longley: IMO, it still seems clear that we don't know what we want to say and so we should say nothing at all.

Ivan Herman: +1 to dlongley.

Dave Longley: to me, it seems like we don't as a group know what to say here, so we should say nothing.

Orie Steele: I am fine closing all these.

Brent Zundel: if nobody is opposed, lets do that.

Manu Sporny: we have to remember to account for media type parameters.
… in the verification algorithm'.
… not clear how to verify if parameters are present.
… good to close it, but we will need to update the verification algorithm.

Brent Zundel: we have a path forward.

[msporny]

@jandrieu wrote:

Why are we forbidding things here?

Based on WG consensus during the last call, this PR no longer forbids (nor encourages) the use of media type parameters.

[msporny]

Normative, multiple reviews, changes requested and made, no objections, merging.