One document matched: draft-saintandre-2141bis-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-saintandre-2141bis-00" ipr="trust200902" obsoletes="2141">
<front>
<title abbrev="URN Syntax">Uniform Resource Name (URN) Syntax</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre" role="editor">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="R." surname="Moats" fullname="Ryan Moats">
<organization/>
</author>
<date year="2012" month="October" day="13"/>
<area>Applications</area>
<workgroup>URNBIS</workgroup>
<keyword>Uniform Resource Name</keyword>
<keyword>Uniform Resource Identifier</keyword>
<abstract>
<t>A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is intended to serve as a persistent, location-independent resource identifier. The general class of URNs is differentiated from all other URIs through the use of the 'urn' URI scheme. This document defines the canonical syntax for URNs, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence. This document obsoletes RFC 2141.</t>
</abstract>
</front>
<middle>
<section title='Introduction' anchor='intro'>
<t>A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) <xref target='RFC3986'/> that is intended to serve as a persistent, location-independent resource identifier. The general class of URNs is differentiated from all other URIs through the use of the 'urn' URI scheme. This document defines the canonical syntax for URNs, guidelines for URN namespaces, requirements for URN presentation and transmission, and methods for determining URN equivalence.</t>
<t>URNs were originally defined in <xref target='RFC2141'/>. 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 <xref target='RFC3986'/>. If approved, this document will obsolete RFC 2141.</t>
<t>The discussion venue for this specification is the mailing list of the URNBIS Working Group; further information can be found at <eref target='https://www.ietf.org/mailman/listinfo/urn'/>.</t>
</section>
<section title="Terminology" anchor="terms">
<t>Many important terms used in this document are defined in the URI specification <xref target='RFC3986'/>.</t>
<t>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 <xref target='RFC2119'/>.</t>
</section>
<section title="Requirements" anchor="reqs">
<t>The requirements for URNs are specified in <xref target='RFC1737'/>. This document does not modify or update those requirements.</t>
</section>
<section title='URN Syntax' anchor='syntax'>
<t>The syntax for a URN is defined as follows using the Augmented Backus-Naur Form (ABNF) as specified in <xref target='RFC5234'/>.</t>
<figure>
<artwork><![CDATA[
URN = "urn" ":" NID ":" NSS
;
; the URI scheme ("urn") is case-insensitive
;
NID = (alphanum) 0*30(ldh) (alphanum)
;
; alphanum is defined in RFC 3986
;
ldh = alphanum / "-"
NSS = 1*(pchar)
;
; pchar is defined in RFC 3986
;
]]></artwork>
</figure>
<t>The following sections describe provide additional information about these rules.</t>
<section title='Namespace Identifier Syntax' anchor='syntax-nid'>
<t>The syntax here is slightly more restrictive than what was defined in <xref target='RFC2141'/>, since it forbids the hyphen character "-" at the end of a NID.</t>
<t>NIDs are case insensitive (e.g., "ISBN" and "isbn" identify the same namespace).</t>
</section>
<section title='Namespace Specific String Syntax' anchor='syntax-nss'>
<t>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 urnchar 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 <xref target='RFC3986'/>.</t>
<t>The "%" character is allowed only for the purpose of percent-encoding.</t>
<t>If a namespace designates one or more characters conforming to the urnchar 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 <xref target='RFC3406'/>.</t>
</section>
</section>
<section title='URN Presentation and Transport' anchor='transport'>
<t>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).</t>
</section>
<section title='Lexical Equivalence in URNs' anchor='equivalence'>
<section title='Procedure' anchor='equivalence-procedure'>
<t>For various purposes such as caching, often it is desirable to determine if two URNs are "the same". This is done by testing for "lexical equivalence".</t>
<t>Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing rules:</t>
<t>
<list style='numbers'>
<t>normalize the case of the URI scheme "urn"</t>
<t>normalize the case of the NID</t>
<t>normalize the case of any percent-encoding</t>
</list>
</t>
<t>Note: Percent-encoded characters MUST NOT be decoded.</t>
<t>URN namespaces MAY define additional rules for lexical 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 <xref target='RFC3406'/>.</t>
</section>
<section title='Examples' anchor='equivalence-examples'>
<t>The following URN comparisons highlight the lexical equivalence rules:</t>
<t>
<list style='numbers'>
<t>URN:foo:a123,456</t>
<t>urn:foo:a123,456</t>
<t>urn:FOO:a123,456</t>
<t>urn:foo:A123,456</t>
<t>urn:foo:a123%2C456</t>
<t>URN:FOO:a123%2c456</t>
</list>
</t>
<t>URNs 1, 2, and 3 are lexically equivalent. URN 4 is not lexically equivalent to any of the other URNs in the above set. URNs 5 and 6 are lexically equivalent only to each other.</t>
</section>
</section>
<section title='Functional Equivalence in URNs' anchor='functional'>
<t>Functional equivalence is determined within a given namespace and managed by resolvers for that namespace, and thus is beyond the scope of this document. For related considerations with regard to NID registration, see <xref target='RFC3406'/>.</t>
</section>
<section title='Handling of URNs by URI Processors' anchor='uri'>
<t>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 <xref target='RFC3986'/> will extract a scheme of "urn" rather than a scheme value of "urn:<nid>".</t>
<t>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.</t>
<t>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.</t>
</section>
<section title='Security Considerations' anchor='security'>
<t>This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. For related considerations with regard to NID registration, see <xref target='RFC3406'/>.</t>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>This section formally registers a URI scheme of 'urn'.</t>
<t>[Note to RFC Editor: please change "XXXX" to the number assigned to this document upon publication.]</t>
<t>
<list style='hanging'>
<t hangText='URI Scheme Name:'>urn</t>
<t hangText='Status:'>permanent</t>
<t hangText='URI Scheme Syntax:'>See Section 4 of RFC&rfc.number;.</t>
<t hangText='URI Scheme Semantics:'>The 'urn' scheme identifies Uniform Resource Names, which are persistent, location-independent resource identifiers.</t>
<t hangText='Encoding Considerations:'>See Section 4.2 of RFC&rfc.number;.</t>
<t hangText='Applications/Protocols That Use This URI Scheme Name:'>Uniform Resource Names are used in a wide variety of applications, including bibliographical reference systems and as names for Extensible Markup Language (XML) namespaces.</t>
<t hangText='Interoperability Considerations:'>There are no known interoperability concerns related to use of the 'urn' URI scheme.</t>
<t hangText='Security Considerations:'>See Section 9 of RFC&rfc.number;.</t>
<t hangText='Contact:'>URNBIS WG [mailto:urn@ietf.org]</t>
<t hangText='Author/Change Controller:'>This scheme is registered under the IETF tree. As such, the IETF maintains change control.</t>
<t hangText='References'>None.</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
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:
<list>
<t>
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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
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.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC1737'>
<front>
<title abbrev='Requirements for Uniform Resource Names'>Functional Requirements for Uniform Resource Names</title>
<author initials='K.' surname='Sollins' fullname='Karen Sollins'>
<organization>MIT Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country></postal>
<phone>+1 617 253 2673</phone>
<email>sollins@lcs.mit.edu</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization>Xerox Palo Alto Research Center</organization>
<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94304</code>
<country>US</country></postal>
<phone>+1 415 812 4365</phone>
<facsimile>+1 415 812 4333</facsimile>
<email>masinter@parc.xerox.com</email></address></author>
<date year='1994' month='December' /></front>
<seriesInfo name='RFC' value='1737' />
<format type='TXT' octets='16337' target='http://www.rfc-editor.org/rfc/rfc1737.txt' />
</reference>
<reference anchor='RFC2141'>
<front>
<title>URN Syntax</title>
<author initials='R.' surname='Moats' fullname='Ryan Moats'>
<organization>AT&T</organization>
<address>
<postal>
<street>15621 Drexel Circle</street>
<street>Omaha</street>
<street>NE 68135-2358</street>
<country>USA</country></postal>
<phone>+1 402 894-9456</phone>
<email>jayhawk@ds.internic.net</email></address></author>
<date year='1997' month='May' />
<area>Applications</area>
<keyword>URN</keyword>
<keyword>uniform resource</keyword>
<abstract>
<t>
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.
</t></abstract></front>
<seriesInfo name='RFC' value='2141' />
<format type='TXT' octets='14077' target='http://www.rfc-editor.org/rfc/rfc2141.txt' />
<format type='HTML' octets='30670' target='http://xml.resource.org/public/rfc/html/rfc2141.html' />
<format type='XML' octets='17687' target='http://xml.resource.org/public/rfc/xml/rfc2141.xml' />
</reference>
<reference anchor='RFC3406'>
<front>
<title>Uniform Resource Names (URN) Namespace Definition Mechanisms</title>
<author initials='L.' surname='Daigle' fullname='L. Daigle'>
<organization /></author>
<author initials='D.' surname='van Gulik' fullname='D. van Gulik'>
<organization /></author>
<author initials='R.' surname='Iannella' fullname='R. Iannella'>
<organization /></author>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2002' month='October' />
<abstract>
<t>This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='66' />
<seriesInfo name='RFC' value='3406' />
<format type='TXT' octets='43707' target='http://www.rfc-editor.org/rfc/rfc3406.txt' />
</reference>
</references>
<section title='Changes from RFC 2141' anchor='changes'>
<t>This document makes the following substantive changes from <xref target='RFC2141'/>:</t>
<t>
<list style='symbols'>
<t>Disallowed "-" at the end of a NID.</t>
<t>Allowed the "~" and "&" characters in an NSS.</t>
<t>Formally registered 'urn' as a URI scheme.</t>
</list>
</t>
</section>
<section title='Acknowledgements' anchor='acks'>
<t>RFC 2141, which provided the basis for this document, was authored by Ryan Moats.</t>
<t>Thanks to Julian Reschke for his corrections to the ABNF.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:20 |