Cisco Systems, Inc.

1899 Wynkoop Street, Suite 600 Denver CO 80202 USA +1-303-308-3282 psaintan@cisco.com

Applications URNBIS Uniform Resource Name URN Uniform Resource Identifier URI A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141.

A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. This document defines the canonical syntax for URIs under the "urn" scheme, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. URNs were originally defined in . The goal of this document is to specify URNs with the smallest reasonable set of changes from the original definition while ensuring consistency with the updated specification of URIs in . This document obsoletes RFC 2141.

Several important terms used in this document are defined in the URI specification . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The requirements for URNs are specified in . This document does not modify or update those requirements.

The syntax for a URN is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in .

The following sections describe provide additional information about these rules.

The syntax here is slightly more restrictive than what was defined in , since it forbids the character "-" at the end of a NID. NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent).

Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed in URNs according to the "pchar" rule (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "/", "?", and "#"). Such a string MUST be translated into a conformant NSS before using it as a protocol element or otherwise passing it on to other applications. Translation is done by percent-encoding each disallowed character using the method defined in Section 2.1 of . Note that the "%" character is allowed only for the purpose of percent-encoding. If a namespace designates one or more characters conforming to the "pchar" rule as having special meaning for that namespace (e.g., "@") and the namespace also uses that character in a literal sense, when used in a literal sense the character MUST be percent-encoded (e.g., "%40"). For related considerations with regard to NID registration, see .

The URI specification allows a query component, a fragment identifier component, or both after the path component of a URI, where the character '?' is used as a separator to denote the beginning of the query component and the character '#' is used as a separator to denote the beginning of the fragment identifier component. The original URN syntax specification reserved the '?' and '#' characters for future developments. This specification aligns URN syntax with URI syntax by allowing the query component and fragment identifier component after (not within) the Namespace Specific String (NSS). This specification does not define the applicability and semantics of the query component or the fragment identifier component in URNs. Additional specifications might establish these matters for URN-related services (such as resolution) or for individual URN namespaces. For example, it is possible that the query component might be used in requests to URN resolution services, or that the fragment identifier component might be used to distinguish the integral parts of resources named by URNs. However, defining such usage is left to specifications for URN resolution services, namespace registration requests and specifications for individual namespaces (which might use some namespace-specific syntax instead of the URI fragment identifier component), and other appropriate documentation (such as policy documents governing the management of a given URN namespace). Although URN assignment is often a managed process (see ), the query component or fragment identifier component can be appended after the NSS once a URN has been assigned in accordance with the rules for a given namespace.

The URN syntax defines the canonical format for URNs. All URN transport and interchanges MUST take place in this format. Further, all URN-aware applications MUST offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by cut and paste techniques). Such applications might support display of URNs in a more human-friendly form and might use a character set that includes characters that are not permitted in URN syntax as defined in this RFC (i.e., when displaying URNs to humans, such applications might replace percent-encoded strings with characters in an extended character set such as Unicode).

For various purposes such as caching, often it is desirable to determine if two URNs are "the same". This is done by testing for "equivalence" (see Section 6.1 of ). Two URNs are equivalent if they are octet-by-octet equal after applying case normalization (as specified in Section 6.2.2.1 of ) to the following constructs: the URI scheme "urn" the NID any percent-encoded characters (see Section 2.1 of ) Percent-encoded characters MUST NOT be decoded, i.e., percent-encoding normalization (as specified in Section 6.2.2.2 of ) MUST NOT be applied. If a query component, fragment identifier component, or both have been appended to the assigned URI, they MUST be ignored for purposes of determining equivalence. URN namespaces MAY define additional rules for equivalence, such as case-insensitivity of the NSS (or parts thereof). Such rules MUST always have the effect of eliminating some of the false negatives obtained by the procedure above and MUST NOT result in treating two URNs as not equivalent if the procedure here says they are equivalent. For related considerations with regard to NID registration, see .

The following URN comparisons (which use the "example" NID defined in ) highlight the equivalence rules: URN:example:a123,456 urn:example:a123,456 urn:EXAMPLE:a123,456 urn:example:A123,456 urn:example:a123%2C456 URN:EXAMPLE:a123%2c456 URNs 1, 2, and 3 are equivalent. URN 4 is not equivalent to any of the other URNs in the above set. URNs 5 and 6 are equivalent only to each other.

The URN syntax has been defined so that URNs can be used in places where URIs are expected. A resolver that conforms to the URI specification will extract a scheme of "urn" rather than a scheme value of "urn:<nid>". A URN MUST be considered an opaque URI by URI resolvers and passed (with the "urn" scheme) to a URN resolver for resolution. The URN resolver can either be an external resolver that the URI resolver knows of, or it can be functionality built-in to the URI resolver. To minimize user confusion, a URI browser SHOULD display the complete URN (including the "urn" scheme) to ensure that there is no confusion between URN namespace identifiers and URL scheme identifiers.

This document specifies the syntax for URNs. While some namespaces resolvers might assign special meaning to certain of the characters of the Namespace Specific String, any security considerations resulting from such assignment are outside the scope of this document. For related considerations with regard to NID registration, see .

This section formally registers a URI scheme of 'urn'. [Note to RFC Editor: please replace "XXXX" with the number assigned to this document upon publication.] urn permanent See Section 4 of RFC&rfc.number;. The 'urn' scheme identifies Uniform Resource Names, which are persistent, location-independent resource identifiers. See Section 4.2 of RFC&rfc.number;. Uniform Resource Names are used in a wide variety of applications, including bibliographic reference systems and as names for Extensible Markup Language (XML) namespaces. There are no known interoperability concerns related to use of the 'urn' URI scheme. See Section 9 of RFC&rfc.number;. URNBIS WG [mailto:urn@ietf.org] This scheme is registered under the IETF tree. As such, the IETF maintains change control. None.

This document supplements the Uniform Resource Name (URN) syntax specification by defining the concept of a URN namespace, as well as mechanisms for defining and registering such namespaces. This document obsoletes RFC 3406. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. World Wide Web Consortium

Massachusetts Institute of Technology 77 Massachusetts Avenue Cambridge MA 02139 USA +1-617-253-5702 +1-617-258-5999 timbl@w3.org http://www.w3.org/People/Berners-Lee/

Day Software

5251 California Ave., Suite 110 Irvine CA 92617 USA +1-949-679-2960 +1-949-679-2972 fielding@gbiv.com http://roy.gbiv.com/

Adobe Systems Incorporated

345 Park Ave San Jose CA 95110 USA +1-408-536-3024 LMM@acm.org http://larry.masinter.net/

Applications uniform resource identifier URI URL URN WWW resource A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] MIT Laboratory for Computer Science

545 Technology Square Cambridge MA 02139 US +1 617 253 2673 sollins@lcs.mit.edu

Xerox Palo Alto Research Center

3333 Coyote Hill Road Palo Alto CA 94304 US +1 415 812 4365 +1 415 812 4333 masinter@parc.xerox.com

AT&T

15621 Drexel Circle Omaha NE 68135-2358 USA +1 402 894-9456 jayhawk@ds.internic.net

Applications URN uniform resource Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document defines a Uniform Resource Name (URN) namespace identifier enabling the generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation.

This document makes the following substantive changes from : Allowed the URI query component after the URN as assigned. Allowed the URI fragment identifier component after the URN as assigned. Disallowed "-" at the end of a NID. Allowed the "~" and "&" characters in an NSS. Formally registered 'urn' as a URI scheme.

Ryan Moats authored RFC 2141, which provided the basis for this document.

Many thanks to Leslie Daigle, Martin Duerst, Juha Hakala, Ted Hardie, Alfred Hoenes, John Klensin, Keith Moore, Julian Reschke, Lars Svensson, and other participants in the URNBIS WG for their input.