One document matched: draft-saintandre-iana-urn-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="info" ipr="trust200902" docName="draft-saintandre-iana-urn-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="URN Namespace for IANA Registries">A Uniform Resource Name (URN) Namespace for IANA Registries</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<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="M." surname="Cotton" fullname="Michelle Cotton">
<organization>IANA</organization>
<address>
<postal>
<street>4676 Admiralty Way Suite 330</street>
<city>Marina Del Rey</city>
<region>CA</region>
<code>90292-6601</code>
<country>USA</country>
</postal>
<phone>+1-310-823-9358</phone>
<email>michelle.cotton@icann.org</email>
</address>
</author>
<date day="7" month="November" year="2012"/>
<keyword>IANA</keyword>
<keyword>Internet Assigned Numbers Authority</keyword>
<keyword>Uniform Resource Name</keyword>
<keyword>URN</keyword>
<abstract>
<t>This document defines a Uniform Resource Name (URN) namespace for uniquely identifying information contained in registries maintained by the Internet Assigned Numbers Authority (IANA).</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The Internet Assigned Numbers Authority (IANA) allocates and maintains unique codes and numbering systems that are used in the context of Internet protocols. Most of the constants and other well-known values maintained by the IANA are contained in registries that are accessible over the Internet, where each registry is hosted at iana.org and identified by a Uniform Resource Identifier (URI) <xref target='RFC3986'/> whose resources are retrieved using the Hypertext Transfer Protocol (HTTP) <xref target='RFC2616'/>.</t>
<t>Some Internet protocols need persistent identifiers for the entries contained in IANA registries. However, currently such identifiers do not exist, for several reasons:</t>
<t>
<list style='numbers'>
<t>Each IANA registry is located at an HTTP URI (e.g., "http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml"), but there are no "pointers" to specific entries in each registry (e.g., the "AES_256_CM_HMAC_SHA1_80" entry in the SRTP Crypto Suite registry located at that URI).<vspace blankLines='1'/></t>
<t>From time to time, the IANA might change the URIs for its registries (as was done not long ago when the IANA changed all of its registries to use Extensible Markup Language <xref target='XML'/> files instead of plain text files).</t>
</list>
</t>
<t>It is desirable that names for the entries in IANA registries can be persistent and location-independent, which is not necessarily the case with names that are also HTTP URIs. However, Uniform Resource Names (URNs) <xref target='RFC2141'/> are designed to be both persistent and location-independent. For example, a URN for the foregoing registry entry might be:</t>
<figure>
<artwork><![CDATA[
urn:iana:sdp-security-descriptions:AES_256_CM_HMAC_SHA1_80
]]></artwork>
</figure>
<t>Therefore, in accordance with the process defined in <xref target='RFC3406'/>, this document defines a formal namespace identifier (NID) that could be used to assign URNs representing the information contained in IANA registries.</t>
</section>
<section title="Specification Template" anchor="template">
<figure>
<artwork><![CDATA[
Namespace ID:
The Namespace ID "iana" is requested.
Registration Information:
Version 1
Date: [[to be assigned by the RFC Editor]]
Declared Registrant of the Namespace:
Registering organization
Organization: Internet Assigned Numbers Authority (IANA)
Address: 4676 Admiralty Way, Suite 330
Marina del Rey, CA
90292-6601
USA
Designated contact
Role: IANA team
Email: iana@iana.org
Declaration of Syntactic Structure:
The Namespace Specific String (NSS) of all URNs that use the
"iana" NID shall have the following structure:
urn:iana:{RegistryName}:{EntryName}
The keywords have the following meaning:
(1) the "RegistryName" is a required ASCII string that
conforms to the URN syntax (RFC 2141) and defines a
particular registry maintained by the IANA.
(2) the "EntryName" is a required ASCII string that
conforms to the URN syntax (RFC 2141) and defines a
particular entry in the relevant registry.
The IANA is responsible for managing the assignment of both
"RegistryName" and "EntryName" strings.
Relevant Ancillary Documentation:
Information about IANA registration procedures can be found
on the IANA website and in RFC 5226.
Identifier Uniqueness Considerations:
The IANA ensures the uniqueness of all IANA URNs by checking
RegistryNames and EntryNames against existing names for both
registries and entries. The IANA directly ensures the
uniqueness of the assigned strings and does not assign
secondary responsibility for management of any sub-trees.
In no case will the resulting URNs be re-assigned.
Identifier Persistence Considerations:
Through its existing registration procedures, the IANA
ensures that registrants provide clear documentation of
the entries in IANA registries.
Process of Identifier Assignment:
The processes and procedures for identifier assignment are
documented on the IANA website and in RFC 5226.
Process for Identifier Resolution:
The namespace is not currently listed with a Resolution
Discovery System (RDS). However, nothing about the namespace
prohibits the future definition of appropriate resolution
methods or listing with an RDS.
Rules for Lexical Equivalence:
No special considerations; the rules for lexical
equivalence specified in RFC 2141 apply.
Conformance with URN Syntax:
No special considerations.
Validation Mechanism:
None specified.
Scope:
Global.
]]></artwork>
</figure>
</section>
<section title="Namespace Considerations" anchor="namespace">
<t>The IANA is one of the Internet's oldest institutions, with its activities dating back to the 1970s. The use of Uniform Resource Names with an appropriate Namespace ID will enable the IANA to assign cleaner, more general, more permanent, more reliable, and more controllable names for the parameters used by Internet protocols and applications.</t>
</section>
<section title="Community Considerations" anchor="community">
<t>The Internet community will benefit from this namespace by having more permanent and reliable names for parameters used in the context of Internet protocols and applications.</t>
<t>The registries maintained by the IANA are open to contributions from any interested individual or organization. See the IANA website and documentation of its registration procedures <xref target='RFC5226'/> for detailed descriptions of the registration procedures.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>This document introduces no additional security considerations beyond those associated with the use and resolution of URNs in general.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document defines a URN NID registration of "iana" and thus opens the possibility that the IANA can use that namespace if desired. However, this document does not stipulate that the IANA is to create names for every entry in every registry that it maintains. The IANA's use of the namespace is a matter for IANA policy, which is outside the scope of this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<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><p>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. </p></t></abstract></front>
<seriesInfo name='BCP' value='66' />
<seriesInfo name='RFC' value='3406' />
<format type='TXT' octets='43707' target='ftp://ftp.isi.edu/in-notes/rfc3406.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='ftp://ftp.isi.edu/in-notes/rfc2141.txt' />
<format type='HTML' octets='30670' target='http://xml.resource.org/public/rfc/html/rfc2141.html' />
<format type='XML' octets='17551' target='http://xml.resource.org/public/rfc/xml/rfc2141.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. 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='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>
<reference anchor='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.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='XML' target='http://www.w3.org/TR/2008/REC-xml-20081126'>
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials='E.' surname='Maler' fullname='Eve Maler'>
<organization />
</author>
<author initials='F.' surname='Yergeau' fullname='Francois Yergeau'>
<organization />
</author>
<author initials='C.' surname='Sperberg-McQueen' fullname='C. M. Sperberg-McQueen'>
<organization />
</author>
<author initials='J.' surname='Paoli' fullname='Jean Paoli'>
<organization />
</author>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<date month='November' day='26' year='2008' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xml-20081126' />
<format type='HTML' target='http://www.w3.org/TR/2008/REC-xml-20081126' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:21 |