RFC 3305

Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations

📅 published August 2002, from ietf

RFC 3305: Report from the Joint W3C/IETF URI Planning Interest Group 🎀

okay bestie, let's start with the basics 💅 RFC 3305 is titled Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations. It's from the Network Working Group, edited by M. Mealling, Ed. and R. Denenberg, Ed., and it was written by the W3C URI Interest Group. It's Informational (so it's giving info, not an official Internet standard 🫶), dated August 2002, and the title block doesn't list any RFCs it obsoletes or updates ✨ (part 1 of 2 🧚)

Status of This Memo ✨

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 💌

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🌸

This doc comes from the W3C Uniform Resource Identifier (URI) Interest Group, and it tries to clear up confusion about URIs 🫠 It covers how the URI space is split up, how URIs, URLs, and URNs relate to each other, how URI schemes and URN namespace IDs get registered, and it gives recommendations for future work on the topic 💖

Table of Contents 🦋

   1.      The W3C URI Interest Group . . . . . . . . . . . . . . . .  2
   2.      URI Partitioning . . . . . . . . . . . . . . . . . . . . .  2
   2.1     Classical View . . . . . . . . . . . . . . . . . . . . . .  3
   2.2     Contemporary View  . . . . . . . . . . . . . . . . . . . .  3
   2.3     Confusion  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.      Registration . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1     URI Schemes  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.1.1   Registered URI schemes . . . . . . . . . . . . . . . . . .  4
   3.1.2   Unregistered URI Schemes . . . . . . . . . . . . . . . . .  4
   3.1.2.1 Public Unregistered Schemes  . . . . . . . . . . . . . . .  4
   3.1.2.2 Private Schemes  . . . . . . . . . . . . . . . . . . . . .  5
   3.1.3   Registration of URI Schemes  . . . . . . . . . . . . . . .  5
   3.1.3.1 IETF Tree  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.1.3.2 Other Trees  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2     URN Namespaces . . . . . . . . . . . . . . . . . . . . . .  5
   3.2.1   Registered URN NIDs  . . . . . . . . . . . . . . . . . . .  5
   3.2.2   Pending URN NIDs . . . . . . . . . . . . . . . . . . . . .  6
   3.2.3   Unregistered NIDs  . . . . . . . . . . . . . . . . . . . .  7
   3.2.4   Registration Procedures for URN NIDs . . . . . . . . . . .  7
   4.      Additional URI Issues  . . . . . . . . . . . . . . . . . .  7
   5.      Recommendations  . . . . . . . . . . . . . . . . . . . . .  8
   6.      Security Considerations  . . . . . . . . . . . . . . . . .  8
   7.      Acknowledgements . . . . . . . . . . . . . . . . . . . . .  8
           References . . . . . . . . . . . . . . . . . . . . . . . .  9
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 10
           Full Copyright Statement . . . . . . . . . . . . . . . . . 11

1. The W3C URI Interest Group 🧠

In October, 2000, the W3C set up a planning group to check out what W3C could do around URIs and to come up with a plan for future work 🗺️ The group had W3C members, and it also invited experts from the IETF to join in 🫶 This document is the group's set of recommendations to the W3C and the IETF for work that can and should keep going in this area ✨

2. URI Partitioning 🍓

okay so there's a lot of confusion in the web community about how URI space is split up, mainly about how URL, URN, and URI relate to each other 😵‍💫 The mix-up comes from two different ways of looking at URI partitioning, which we call the "classical" and "contemporary" views 💅

2.1 Classical View 🕰️

Back in the early-to-mid 90s, people assumed an identifier would fall into one of two (or maybe more) classes 🎀 An identifier could tell you where a resource is (a URL) or what its name is, no matter where it lives (a URN). So a URI was either a URL or a URN. People talked about adding a few more classes, like a URI that points to metadata instead of the resource itself, which would make it a URC (citation) 🤔 That meant URI space was seen as split into subspaces: URL, URN, and any extra ones that got defined. The only extra one anyone ever proposed was Uniform Resource Characteristics (URC), and it never got any buy-in 💀 So, without loss of generality, it's fair to say URI space was thought to be split into two classes: URL and URN. For example, "http:" was a URL scheme, and "isbn:" would (someday) be a URN scheme. Any new scheme would be sorted into one of these two classes 🧚

2.2 Contemporary View 🌈

Over time, people stopped caring as much about this extra level of hierarchy 🙃 The new view was that an individual scheme doesn't have to be sorted into a fixed set of URI types, like "URL", "URN", "URC", and so on 💖 Web-identifier schemes are generally URI schemes, since a URI scheme can define its own subspaces. So "http:" is a URI scheme. "urn:" is also a URI scheme, and it defines subspaces called "namespaces". For example, the set of URNs in the form urn:isbn:n-nn-nnnnnn-n is a URN namespace. ("isbn" is a URN namespace identifier. It isn't a "URN scheme", and it isn't a "URI scheme" either.) 📚

Also, in the contemporary view, "URL" isn't a formal partition of URI space. It's a useful but informal idea 🫶 A URL is a type of URI that identifies a resource by showing its main access mechanism (like its network "location"), instead of by some other attributes it might have. So, as we said, "http:" is a URI scheme, and an http URI is a URL 💅 The phrase "URL scheme" is used rarely now, and when people use it, it usually means a subclass of URI schemes that leaves out URNs ✨

2.3 Confusion 😭

The body of documents (RFCs, etc.) about URI architecture, syntax, registration, and so on spans both the classical and contemporary periods 📖 People who know URI stuff well tend to use "URL" and "URI" like they mean the same thing. Among those experts, that's not a problem. But for the Internet community at large, it is a problem 🙈 People aren't convinced that URI and URL mean the same thing, even in documents where they seemingly do. One RFC talks about URI schemes (for example, "URI Syntax" (RFC 2396) [12]), another talks about URL schemes (for example, "Registration Procedures for URL Schemes" (RFC 2717) [1]), and yet another talks about URN schemes ("Architectural Principles of URN Resolution" (RFC 2276) [13]). So it's totally natural to wonder how they differ and how they connect 🤷‍♀️ RFC 2396, section 1.2, tries to explain the difference between URIs, URLs, and URNs, but it hasn't really cleared up the confusion 🥲

3. Registration 📝

This section looks at where registration of URI schemes and URN namespaces stands, and how that registration currently happens ✨

3.1 URI Schemes 🦋

3.1.1 Registered URI schemes 💌

The official register of URI scheme names is kept by IANA, at http://www.iana.org/assignments/uri-schemes. For each scheme, it lists the RFC that defines it. For example, "http:" is defined by RFC2616 [14]. At the time this RFC was published, the table lists 34 schemes 🙌 There are also a few "reserved" scheme names. At one point these were meant to become registered schemes, but they've since been dropped 🫠

3.1.2 Unregistered URI Schemes 🫧

We split schemes into public (unregistered) and private ones 💅 A public scheme, whether or not it's registered, is one that has some public document describing it ✨

3.1.2.1 Public Unregistered Schemes 🌷

Dan Conolly's paper, at http://www.w3.org/Addressing/schemes, lists known public URI schemes, both registered and unregistered. At the time this RFC was published, that's 85 schemes total 🤯 About 50 of them are unregistered (they're not on the IANA list). Some of these schemes are obsolete. For example, "phone" is obsolete and was superseded by "tel". Others have an RFC but still aren't on the IANA list 📎

3.1.2.2 Private Schemes 🔒

It's probably impossible to figure out all of them, and it's not clear it's worth trying, except maybe to get a sense of how many there are 🫣 In the minutes of the August 1997 IETF meeting, someone noted that Microsoft might have 20-40 in use, with 2-3 being added a day, and that WebTV has 24, with 6 added per year 😳

3.1.3 Registration of URI Schemes 📋

"Registration Procedures for URL Scheme Names" (RFC 2717) [1] lays out how to register scheme names, and it points to "Guidelines for new URL Schemes" (RFC 2718) [2], which gives guidelines 💅 RFC 2717 describes organizing schemes into "trees". It's important to notice that these two documents use the old term 'URL' even though they're really talking about URIs in general 👀 In fact, one of the recommended tasks in Section 5 is to update these documents to use the term 'URI' instead of 'URL' ✨

3.1.3.1 IETF Tree 🌳

The IETF tree is for schemes of general interest to the Internet community, and for schemes that need a substantial review and approval process 🧐 To register in the IETF tree, you have to publish the scheme's syntax and semantics in an RFC 📜

3.1.3.2 Other Trees 🌿

RFC 2717 describes "alternative trees", but no alternative trees have been registered so far 🥺 There is a vendor-supplied tree ("vnd") that's pending, though. URI schemes in alternative trees will be told apart because they'll have a . in the scheme name 🏷️

3.2 URN Namespaces 💜

A URN namespace is identified by a "Namespace ID" (NID), which is registered with IANA (see Section 3.2.4) 🫶

3.2.1 Registered URN NIDs 🎀

There are two categories of registered URN NIDs:

  • Informal: These look like urn-<number>, where <number> is assigned by IANA. At the time this RFC was published, four were registered in this category (urn-1, urn-2, urn-3, and urn-4) 🍬
  • Formal: The official list of registered NIDs is kept by IANA at http://www.iana.org/assignments/urn-namespaces. At the time this RFC was published, it listed ten registered NIDs 👑
    • 'ietf', defined by "URN Namespace for IETF Documents" (RFC 2648) [3]
    • 'pin', defined by "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations" (RFC 3043) [4]
    • 'issn', defined by "Using The ISSN as URN within an ISSN-URN Namespace" (RFC 3043) [4]
    • 'oid', defined by "A URN Namespace of Object Identifiers" (RFC 3061) [6]
    • 'newsml', defined by "URN Namespace for NewsML Resources" (RFC 3085) [7]
    • 'oasis', defined by "A URN Namespace for OASIS" (RFC 3121) [8]
    • 'xmlorg', defined by "A URN Namespace for XML.org" (RFC 3120) [9]
    • 'publicid', defined by "A URN Namespace for Public Identifiers" (RFC 3151) [10]
    • 'isbn', defined by "Using International Standard Book Numbers as Uniform Resource Names" (RFC 3187) [15]
    • 'nbn', defined by "Using National Bibliography Numbers as Uniform Resource Names" (RFC 3188) [16] 🌈

3.2.2 Pending URN NIDs ⏳

okay so there are a bunch of pending URN NID registration requests just floating around 🫠, but there's no reliable way to find them or check where they're at. it would be so helpful if there were some formal way to track the status of NID requests like 'isbn' 📚.

3.2.3 Unregistered NIDs 👻

in the "unregistered" category (besides the experimental case, which this paper doesn't cover) there are entities running namespaces that are totally valid as URNs, they just never bothered to go through NID registration 💅. the most famous one is 'hdl' 🍓. it's been speculated that 'hdl' never got registered because the owners weren't sure whether it should be a URI scheme or a URN namespace 🤷‍♀️. bestie, same energy as deciding between two outfits for literally three weeks 😭.

3.2.4 Registration Procedures for URN NIDs 📝

"URN Namespace Definition Mechanisms" (RFC 2611) [11] explains how to get an NID for a URN namespace, and that NID gets registered with IANA 🎀.

a request for an NID should describe features including: structural characteristic of identifiers (for example, features relevant to caching/shortcuts approaches); specific character encoding rules (e.g., which character should be used for single-quotes); RFCs, standards, etc, that explain the namespace structure; identifier uniqueness considerations; delegation of assignment authority, including how to become an assigner of identifiers; identifier persistence considerations; quality of service considerations; process for identifier resolution; rules for lexical equivalence; any special considerations required for conforming with the URN syntax (particularly applicable in the case of legacy naming systems); validation mechanisms (determining whether a given string is currently a validly-assigned URN); and scope (for example,"United States social security numbers"). it's a LOT, but it's giving thorough and that's iconic 👑✨.

4. Additional URI Issues 🌈

there are more unresolved URI issues that this paper doesn't tackle 🫶. we hope a follow-on effort picks them up. we haven't tried to list every single one, but they include (but are not limited to) the following:

  • The use of URIs as identifiers that don't actually identify network resources (for example, they identify an abstract object, such as an XML namespace, or a physical object such as a book or even a person) 📖🧍‍♀️.
  • IRIs (International Resource Identifiers): the extension of URI syntax to non-ASCII 🌏.

5. Recommendations 💖

we recommend the following 💅:

  1. The W3C and IETF should jointly develop and endorse a model for URIs, URLs, and URNs consistent with the "Contemporary View" described in section 1, and which considers the additional URI issues listed or alluded to in section 3.
  2. RFCs such as 2717 ("Registration Procedures for URL Scheme Names") and 2718 ("Guidelines for new URL Schemes") should both be generalized to refer to "URI schemes", rather than "URL schemes" and, after refinement, moved forward as Best Current Practices in the IETF 🔥.
  3. The registration procedures for alternative trees should be clarified in RFC 2717 🌸.
  4. Public, but unregistered schemes, should become registered, where possible. Obsolete schemes should be purged or clearly marked as obsolete 🧹.
  5. IANA registration information should be updated:
    • Add 'urn' to the list of registered URI schemes with a pointer to the URN namespace registry.
    • Maintain status information about pending registrations (URI schemes and URN NID requests ).
    • Insure that it is clear that the page is the official registry, e.g., by adding a heading to the effect "This is the Official IANA Registry of URI Schemes" 🦋.

6. Security Considerations 🔐

okay bestie, this memo does not raise any known security threats 😌. no known threats, but please don't take that as a green light to get sloppy 🙈.

7. Acknowledgements 🫶

the participants in the URI Planning Interest Group are 💜:

  • Tony Coates
  • Dan Connolly
  • Diana Dack
  • Leslie Daigle
  • Ray Denenberg
  • Martin Duerst
  • Paul Grosso
  • Sandro Hawke
  • Renato Iannella
  • Graham Klyne
  • Larry Masinter
  • Michael Mealling
  • Mark Needleman
  • Norman Walsh

References 📚

[1] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.

[2] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.

[3] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.

[4] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001.

[5] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001.

[6] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.

[7] Coates, A., Allen, D. and D. Rivers-Moore, "URN Namespace for NewsML Resources", RFC 3085, March 2001.

[8] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121, June 2001.

[9] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, June 2001.

[10] Walsh, N., Cowan, J. and P. Grosso, "A URN Namespace for Public Identifiers", RFC 3151, August 2001.

[11] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999.

[12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[13] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.

[14] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[15] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001.

[16] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, October 2001.

Authors' Addresses 🏡

Michael Mealling VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 US

EMail: michael@verisignlabs.com

Ray Denenberg Library of Congress Washington, DC 20540 US

EMail: rden@loc.gov

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society ✨.

📦 where this page comes from