- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Tue, 15 Aug 2017 00:20:03 +0000
- To: Romain <rdeltour@gmail.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
We agreed to use the definition in the HTML 5 spec, which is an acceptable normative reference for URL.
However, there are times where we may want/need a URI or IRI, such as when we need something that isn’t actually a “link” on the web (eg. a namespace).
I don’t recall anyone suggesting a specific use case for URN.
Leonard
On 8/14/17, 6:51 PM, "Romain" <rdeltour@gmail.com> wrote:
Hi all,
Just a quick clarification on the terms URL, URI, IRI, URN, etc.
Yesterday's call contains the resolution:
> Use URL-s and use IRI/URI when it becomes strictly important
And in previous calls there were statements like:
> a URN is not a URL, but it is a URI
I disagree:
If –as we agreed on yesterday's call– we refer to the URL Standard (published by the WhatWG), then we no longer need to ever use "URI" or "IRI" (*), since this standard obsoletes both terms (defined respectively in RFC3986 and RFC3987) in favor of "URL".
(*) except perhaps in the one non-normative note that would accompany the reference to the URL standard
As for the term "URN", it is rather loosely defined in RFC3986 as:
> The term "Uniform Resource Name" (URN) has been used historically to refer to both URIs under the "urn" scheme [RFC2141], which are required to remain globally unique and persistent even when the resource ceases to exist or becomes unavailable, and to any other URI with the properties of a name.
In any case, a URN like "urn:isbn:9781449329297") **is** a URL.
Finally, note that URL is defined as a "universal identifier". A URL doesn't necessarily represents a fetchable resource.
My 2 standards-nerd cents :-)
Romain.
[URL] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl.spec.whatwg.org&data=02%7C01%7C%7C90b425d90dc3488689bb08d4e366fe3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383478875275228&sdata=yLWc0epXhnMKKxW1dC%2B2TnIzgsn4fTt%2FQXUYNc%2Bdq9A%3D&reserved=0
[RFC3986] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3986&data=02%7C01%7C%7C90b425d90dc3488689bb08d4e366fe3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383478875275228&sdata=xORdb12JcftN7BccVVpqmw0L72boOOwUsRA%2BP1BFBoQ%3D&reserved=0
[RFC3987] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3987&data=02%7C01%7C%7C90b425d90dc3488689bb08d4e366fe3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383478875275228&sdata=a6huohWq%2BoNCS6QoHWXCQAPR7FHz%2BjPt3XwcNgHN7JY%3D&reserved=0
[RFC2141] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc2141&data=02%7C01%7C%7C90b425d90dc3488689bb08d4e366fe3f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636383478875275228&sdata=nBmK%2FrLkISi%2Bmx%2BwohG8fHrMiHb07Rw1Xns0JQV5XhI%3D&reserved=0
Received on Tuesday, 15 August 2017 00:20:32 UTC