Network Working Group M. Mealling
Internet-Draft VeriSign
Expires: February 18, 2002 L. Masinter
AT&T Labs
T. Hardie
Equinix
G. Klyne
Content Technologies Ltd.
August 20, 2001
An IETF URN Sub-namespace for Registered Protocol Parameters
draft-mealling-iana-urn-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 18, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes a new sub-delegation for the 'ietf' URN
namespace defined in RFC 2648 for registered protocol items.
1. Introduction
From time to time IETF standards require the registration of various
Mealling, et. al. Expires February 18, 2002 [Page 1]
Internet-Draft IANA URN Namespace August 2001
protocol elements in some well known central repository. The
Internet Assigned Numbers Authority maintains this central authority
and takes direction from the IETF on what, how and when to add items
to that registry. The IANA maintains lists of items such as all
assigned port numbers, MIME media types, enterprise numbers, etc.
Over time there has developed a need to be able to reference these
elements in various schema. In the past this was done in a very
adhoc way that easily led to interoperability problems. This
document creates a new sub-delegation below the "ietf" [2]URN
namespace [1] called 'params' which acts as a standardized mechanism
for naming the items registered for IETF standards.
2. Lessons Learned
In the process of writing this document, the authors attempted to
pre-assign as many names as possible. This involved a complete
review of every item currently in the IANA repository. There were
several organizational issues that had direct impact on how well a
URN could be assigned to particular existing entries in the registry.
As a result, the authors have included a set of recommendations that
could be made to document authors seeking to setup new registries.
2.1 Multiple Registries Per File
The authors found that the practice of putting multiple registries in
a single file on the IANA ftp archive caused large amounts of
confusion. A good example is the Mobile IP Numbers registry. Due to
having several very different concepts in the same file it is very
difficult to understand where one set of parameters ends and another
begins.
The authors recommend that, in the future, the IANA create
subdirectories in which each separate registry is maintained in a
separate file. Also, document authors are encouraged to suggest a
document/directory structure to the IANA in their IANA considerations
section.
2.2 Unclear Index Values
In many cases the registry had no clearly unique value that could be
used in the URN. An example here is the Public Data Network Numbers
registry which is a mapping between IP addresses and X.121 addresses.
It is not clear which value to use in the name. In recent history
the IANA has begun assigning a simple index value to assignments and
often this can be used in the URN. Document authors are encouraged
to include some type of indexing value in their IANA considerations
section so that some other entity can uniquely talk about a
particular entry.
Mealling, et. al. Expires February 18, 2002 [Page 2]
Internet-Draft IANA URN Namespace August 2001
2.3 General Disorganization
Due to historical neglect there are several registries that are in a
general state of 'disrepair'. The Mobile IP Numbers registry above
is a good example. Experts in this area are encouraged to produce
new documents providing guidance to the IANA for how these registries
should be organized for clarity.
2.4 Obsolete Registries
While there have been a few registries that have been marked as
obsolete (SGMP Vendor Specific Codes), there is a general lack of a
way of moving an IANA registry to historical status. The authors
recommend that the IESG create a method by which a document can
request that an IANA registry be obsoleted.
3. Changes to RFC 2434
The authors realize that assigning URNs to new items in the registry
with no guidance from those asking for the registry is an additional
burden the IANA does not need. Thus the authors suggest that the
following updates be made to RFC 2434:
In the event that an RFC requests that the IANA maintain a registry,
the IANA Considerations section of that document MUST include the
following:
o The top level registry name -- This is the unique string that goes
between the third and fourth colons in the URN and is also used as
the directory name in any network accessible repositories. For
example, the registry name for the Socks Methods is found in the
sub-directory called "socks-methods" on the IANA FTP site. This
value is also used to assign the URN as "urn:ietf:params:socks-
methods:". The requesting document MUST provide this value but
the IANA SHOULD follow that recommendation. In the case where
there is a conflict the IANA can assign another value.
The intent here is that if the registry is simple then this value
will be both the filename in which the IANA puts this information
and the URN sub-namespace that is created. If the registry is
complex and thus has sub-registries, then this value will be the
directory name in the FTP archive.
o sub-registry names -- In the case where a particular registry has
sub-sections then the requesting document MUST provide names for
these sub-registries. The intent is that these sub-registry names
will be the filenames/sub-directories that exist under the
registry directory as well as being the section name in the URN
Mealling, et. al. Expires February 18, 2002 [Page 3]
Internet-Draft IANA URN Namespace August 2001
that is assigned. The document author should ensure that for each
sub-registry there is one and only one set of values and that an
index value exists that is unique within that sub-registry.
4. Namespace Specifics
Using the template in RFC 2611 as a guide, this is the specification
for the 'params' sub-namespace:
Sub-namespace name:
"params"
Declared registrant of the namespace:
The Internet Engineering Task Force
Declaration of structure:
The namespace is primarily opaque. The IANA, as operator of the
registry, may take suggestions for names to assign but they
reserve the right to assign whatever name they desire, within
guidelines set by the IESG. The colon character (":") is used to
denote a very limited concept of hierarchy. If a colon is present
then the items on both sides of it are valid names. In general,
if a name has a colon then the item on the left hand side
represents a class of those items that would contain other items
of that class. For example, a name can be assigned to the entire
list of DNS resource record type codes as well as for each
individual code. The URN for the list might look like this:
urn:ietf:params:dns:rr-type-codes
while the URN for the SOA records type code might look like this:
urn:ietf:params:dns:rr-type-codes:soa
Mealling, et. al. Expires February 18, 2002 [Page 4]
Internet-Draft IANA URN Namespace August 2001
Relevant ancillary documentation:
None.
Identifier uniqueness considerations:
The IANA has sole discretion for assigning names and thus can
guarantee uniqueness by comparing the name to be assigned with the
list of previously assigned names.
Identifier persistence considerations:
The IANA has sole discretion for assigning names and thus can
guarantee persistence by comparing the name to be assigned with
the list of previously assigned names.
Process of identifier assignment:
Identifiers are assigned only after a particular protocol element
or number has been registered with the IANA using standard
policies and procedures. Once that element is assigned and in the
repository, the IANA will take requests for that element to have a
name assigned. The assignment request can suggest a name to use
but the IANA may ignore that request.
Process of identifier resolution:
At this time no resolution mechanism is defined though one is
expected.
Rules for Lexical Equivalence:
Lexical equivalence is achieved by exact string match.
Conformance with URN Syntax:
There are no additional characters reserved.
Mealling, et. al. Expires February 18, 2002 [Page 5]
Internet-Draft IANA URN Namespace August 2001
Validation mechanism:
None.
Scope:
Global
5. Assigning Names
The authors originally attempted to pre-assign names for every item
currently in the repository but found this a) difficult and b) of
little current value. The solution is a template and process for
requesting that a name by assigned to a particular registry entry.
The creation of a new registry name will be simple for most flat
registries. The only required elements will be the registry name
(see recommended changes to RFC 2434 above), a reference to relevant
documents, a statement about which current/proposed document
repositories contains the authoritative data for the registry, and a
statement specifying which element in the registry is the value to be
used in the URN. In most cases this last element will be the index
value assigned by the IANA.
More complex registries (DNS Parameters for example) will need to
repeat that information for any sub-namespaces. It should also be
clear as to whether or not a name is assigned to the sub-namespace
itself (i.e. is 'urn:ietf:params:dns:rr-types' valid by itself and
if so, what does it name?).
The template:
Registry name: -- The name of the sub-namespace. In many cases this
should be the same name as what the registry itself.
Specification: -- Relevant IETF published documents that define the
registry and the items in it.
Repository: -- A pointer to the 'current' location of the registry in
the protocol parameters repository. This value will change over
time as the entity that maintains the repository moves files and
or fileservers. It is not meant as a permanent binding to the
filename but as a hint to the IANA for what the initial mapping
would be.
Mealling, et. al. Expires February 18, 2002 [Page 6]
Internet-Draft IANA URN Namespace August 2001
Index value: -- A statement specifying which value in the registry is
the index to each entry in that registry. This index value will
be used in the URN to name each entry. In some cases it can
actually be the thing being named, in others, where those values
can change, it should be an index to the record instead of
something in the record itself.
The process for requesting that a URN be assigned is currently to put
the above template in the IANA considerations section of the
specifying document. Other more automated processes may be proposed
at a latter time if demand requires it.
6. Security Considerations
None not already inherent to using URNs.
7. IANA Considerations
This document puts a new and significant burden on the IANA since it
may require a additional assignment process to happen for each new
IANA registry. It is the hope of the authors that the required
strictness that the URN assignment puts on the registering document
authors will actually make the IANA's job easier by taking the guess
work out of creating a new registry.
References
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
Authors' Addresses
Michael Mealling
VeriSign
505 Huntmar Park Drive
Herndon, VA 22070
US
Phone: +1 770 921 2251
EMail: michaelm@netsol.com
URI: http://www.verisign.com
Mealling, et. al. Expires February 18, 2002 [Page 7]
Internet-Draft IANA URN Namespace August 2001
Larry Masinter
AT&T Labs
75 Willow Road
Menlo Park, CA 94025
US
Phone: +1 650 463 7059
EMail: LMM@acm.org
URI: http://larry.masinter.net
Ted Hardie
Equinix
901 Marshall Street
Redwood City, CA 94063
US
EMail: hardie@equinix.com
Graham Klyne
Content Technologies Ltd.
1220 Parkview, Arlington Business Park
Theale, Reading RG7 4SA
UK
Phone: +44 118 930 1300
EMail: GK@ACM.ORG
Mealling, et. al. Expires February 18, 2002 [Page 8]
Internet-Draft IANA URN Namespace August 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.
Mealling, et. al. Expires February 18, 2002 [Page 9]