vc-data-model
vc-data-model copied to clipboard
w3c
[Tracking Issue - Proposed Corrections Feedback] URL to URI
@jyasskin I've raised this issue to track the WG response to the feedback you provided above and to provide a place where we might engage in a conversation as we explore possible responses.
From feedback on VC Data Model v1.1
* Correction 2, changing "URL" to "URI", moves from a value that can be
fetched to a value that can't necessarily be fetched. The meaning of these
`id` values is undefined both before and after the change, but it moves
from the possibility of defining a general meaning for the fetched
resource, to a need to define the meaning of particular URIs in a table.
That seems like the wrong direction. The WG could cite
https://url.spec.whatwg.org/ if their goal is simply to provide a normative
definition of the "URL" term.
The WG also experienced some frustration in attempting to package the proposed corrections in such a way as to make them more accessible for reviewers. We would have definitely benefited from some additional tooling. The following contain records of the issue and the WG's conversation which led to the corrections related to the above concerns:
- The issue that drove this correction is #748
- The PR that proposed the changes is #819
Thanks! @dlongley's comment in https://github.com/w3c/vc-data-model/pull/819#issuecomment-920144413 seems to match my concern here, and provide a plausible fix by adding
there's an expectation that machine readable information needs to be retrievable [] from the URI
I think "via some other field value" would re-introduce a similar concern around how implementations could figure out what other field value to retrieve.
Added the errata label to track this in the errata document. I think it could just as well be removed based on the tracking of the additional linked issues and PRs as well. @brentzundel feel free to remove it if you think it's not needed.
The issue was discussed in a meeting on 2022-01-26
- no resolutions were taken
View the transcript
4.2. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)
See github issue vc-data-model#862.
Brent Zundel: One of our proposed corrections changed a URL to a URI..
… I believe that there is language within the conversations we've already had around this issue that would address the concerns..
… [reading from thread].
… Questions or comments?.
… Sounds like this one needs a PR. Is there someone who can be assigned to this issue to raise a PR to address it?.
… It is an editorial change at this point..
Kyle Den Hartog: You can assign it to me and I'll take care of it today..
… Just what was proposed in that comment?.
Brent Zundel: Yes, the quoted line.
… Putting a v1.1 label on it.
Kyle Den Hartog: Will do.
Juan Caballero: i can do it.
I don't want this comment forgotten when the PR it was made on is merged: https://github.com/w3c/vc-data-model/pull/866#pullrequestreview-865405471
I think this may also mean that merging the PR shouldn't necessarily close this issue, wdyt @kdenhartog ?
I'm good with that. I'll update the PR to make it clearer the purpose of what we're trying to do and then we can mark that one as v1.1 and errata so it gets tracked in the errata log. That way we can make this issue a V2 issue and leave it open.
The issue was discussed in a meeting on 2022-02-02
- no resolutions were taken
View the transcript
3.2. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)
See github issue vc-data-model#862.
See github pull request vc-data-model#866.
Brent Zundel: This is another tracking change from URL to URI -- general concern around using URIs vs. URLs. There is a PR to address this..
… This was raised by kdenhartog.
Kyle Den Hartog: Status is that it should be ready to go, pending approval, the Google representative has approved it..
… It looks like we're going to leave this issue open as well, just to track during the v2.0 work..
… We should address this in detail when new WG is formed..
Brent Zundel: We're looking for more review..
… Any questions on response to feedback before we move on to our next topic?.
Re opening this issue since PR #866 addressed part of the concern, and the goal was to have follow on work done in V2 and we'd use this issue to track that follow on work.
The issue was discussed in a meeting on 2022-02-16
- no resolutions were taken
View the transcript
1.1. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)
See github issue vc-data-model#862.
See github pull request vc-data-model#866.
Kyle Den Hartog: +1 to merging now.
Brent Zundel: proposal to merge now.
Manu Sporny: this needs to be squashed and merged.
For instance, in OAuth [RFC 6749], it's a redirect_uri, even though it's obviously dereferenceable.
I'll raise a PR and point to the WHATWG URL specification when we reference "URLs" (which are meant to be dereferenceable). I'll try to summarize the discussion around IETF URIs, and WHATWG URIs/URLs in some specification text.
The issue was discussed in a meeting on 2022-08-24
- no resolutions were taken
View the transcript
3.1. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)
See github issue vc-data-model#862.
Kristina Yasuda: The top one we have is issue #862.
… This is a request to fix the mixed use of URLs and URIs -- and I believe this has been done. The issue was closed once and then re-opened because there was going to be follow-on work in V2.
Brent Zundel: As I recall, we made some editorial changes in V1.1 where there is a distinction between URI and URL. I believe there are still some outstanding changes that could be made in V2 to just change everything from URL to URI. I think that was the consensus of the group at the time, whether that's the consensus now is up to this group.
… There's some identifiers that are still identified as URLs and others as URIs and this issue says it should be unified.
Michael Jones: For context, in IETF specs, URI is preferred over URL.
Manu Sporny: I'm just speaking to the concept that we would unify these. I think we carefully picked which of these IDs are URIs and which are URLs. The ones that are expected to be derefenced are URLs and the URIs do not have that requirement.
… I think we were very careful about making the distinction between the two. I think I'm a -1 to just making all of them a URI or a URL because we put considerable thought into which is which.
Ivan Herman: I am fine with what you say, but I'm looking at the references in the data model spec, there is a reference to the URI which is the RFC, there is no reference to URL. In practice, almost all the new specs in W3C refer to the WHATWG spec as the reference for URL.
Michael Jones: For instance, in OAuth [RFC 6749], it's a
redirect_uri, even though it's obviously dereferencable.
Ivan Herman: The WHATWG spec is hard to read but it encompasses lots of things and also handles URIs in some sense. We do need a proper reference to see what URL we are talking about.
Manu Sporny: +1 for updating the reference, that's something we meant to do and we did mean to use the new WHATWG spec.
Kristina Yasuda: Do you want to do that within this issue?
… We could try to get a concrete proposal.
Michael Prorock: +1 reference and use that spec as the baseline.
Manu Sporny: How about the group says we should change the reference to WHATWG URL -- is that what the group wants?
Kristina Yasuda: Is there agreement in the group to do that and to reference the WHATWG URL spec? Is there anything else that needs to be done?
Dmitri Zagidulin: I'd like to offer an alternative proposal to go into the issue / PRs. We change it uniformly to URI but note the places where we expect dereferencing. So we don't rely on an obscure definition and we just say it explicitly.
Kristina Yasuda: I think you're suggesting something similar to what Mike Jones has put in the chat.
Manu Sporny: hrm, -1 to that... the difference between URI and URL is dereferenceability.
Michael Jones: I agree with Dmitrii's proposal.
Kristina Yasuda: I don't think we have consensus. I'd like to propose for people to continue conversation in the issue.
Ivan Herman: If we have dereferencable things that we use all over the place we will get comments from the TAG and other places that we should use the WHATWG URL spec. The overall point of that spec was to unify around dereferencable things.
… If that's the goal it would have to be URL.
Kerri Lemoie: Link to URL spec?
Ivan Herman: See WhatWG URL spec.
Kerri Lemoie: Thanks.
Michael Prorock: I just put a PR that's up on data integrity where manu and I and others dug in deep and put URL where it's dereferencable and it became apparent that we kinda have to go with the WHATWG URL spec. As much of a mess that spec is, it covers all of the various issues we want to cover.
… I'm pretty firmly on "let's point to WHATWG URL spec and call it a day".
Michael Jones: In IETF all the protocol identifiers use URI. In the text description, if something is a URL, it's reasonable to say ...
… ... where URIs are dereferencable they can and do say URL.
Manu Sporny: See WhatWG's view on URLs vs URIs.
Michael Prorock: +1 manu.
Ivan Herman: +1 to manu.
Manu Sporny: To make this even more complicated, the WHATWG URL spec, firmly asserts that they are supplanting the term URI. The browser manufacturers and a variety of software developers agree and this is sort of a lost battle. They want to use the term URL for everything.
… Folks in this group might not be aware of the long history here.
… Another argument here -- and I'm not arguing for this -- there are a number of alternatives: Mike Jones says call them all URI and some can be dereferenced, we use URI in some places and URL in others, or we use WHATWG and "URL" everywhere.
… All of these options have pros and cons.
Michael Jones: What a mess!.
Michael Prorock: +1 selfissued - super mess.
Kerri Lemoie: If browsers are adopting URL everywhere, that may be the easiest & most understandable approach in the longterm.
Phil Archer: I've been aware of this for a while now -- and I say you can call it whatever you want and I call it a URI -- maybe not helpful. At GS1 we use deliberately use URI because the identifier is independent of the domain name. Maybe a good or bad choice, but we say things are a URI that can also be a URL and you can do things online with it. I'm afraid that once I retire the phrase URI is going to disappear.
Kristina Yasuda: Could you in your PR make it really clear that we're using WHATWG URL but ... the thing is a URI? Is there a good middle-ground?
… Are there any objections for Manu doing this PR?
… I think, Manu, if you could try to reflect people's concern in the PR and if there are no objections we can come back to the issues conversation.
… Does that sound good?
Manu Sporny: +1.
in IETF specs, URI is preferred over URL
It would be good to have an actual citation for this IETF preference (which I've tried and failed to find through web searches), especially given that W3 (partly via a link to the WHATWG URL spec) currently has guidance preferring URL over URI, IRI, URN, etc.
The issue was discussed in a meeting on 2022-10-19
- no resolutions were taken
View the transcript
3.4. [Tracking Issue - Proposed Corrections Feedback] URL to URI (issue vc-data-model#862)
See github issue vc-data-model#862.
David Chadwick: url vs uri.
Manu Sporny: this is an old discussion about url vs iri vs uri.
… so maybe we should move to using url as this is used by browsers and is ubiquitous.
Ivan Herman: tendency in W3C is to move towards url spec; not only browsers but various libraries, e.g., for JS or TypeScipt, rely on that nowadays.
Dave Longley: +1 to ivan, implementations use the WHATWG spec.
PR #994 has been raised to address this issue. This issue will be closed once that PR has been merged.