- 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