WDIFF

draft-mealling-iana-urn-01.txt --> draft-mealling-iana-urn-02.txt

Network Working Group M. Mealling
Internet-Draft VeriSign
Expires: February 18, April 29, 2002 L. Masinter
AT&T Labs
Adobe Systems Incorporated
T. Hardie
Equinix
G. Klyne
Content Technologies Ltd.
August 20,
MIMEsweeper Group
October 29, 2001

An IETF URN Sub-namespace for Registered Protocol Parameters
draft-mealling-iana-urn-01.txt
draft-mealling-iana-urn-02.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, April 29, 2002.

Abstract

This document describes a new sub-delegation for the 'ietf' URN
namespace for registered protocol items. The 'ietf' URN namespace is
defined in RFC 2648 as a root for registered protocol items.

1. Introduction

From time persistent URIs that refer to time IETF standards require the registration of various IETF-
defined resources.

Mealling, et. al. Expires February 18, April 29, 2002 [Page 1]

Internet-Draft IANA URN Namespace August October 2001

1. Introduction

From time to time IETF standards require the registration of various
protocol elements in some well known central repository. The Internet
Assigned Numbers Authority maintains this central authority repository and
takes direction from the IETF on what, how and when to add items to that registry.
it. 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 as URIs in various schema. In the past this was done in a
very
adhoc ad hoc 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 Any assignments
below that are specified in the IANA repository. There were
several organizational issues that had direct impact on how well a
URN could be assigned an RFC according to particular existing entries in the registry.
As a result, IETF concensus
process and which include 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 template found that the practice of putting multiple registries in
a single file on Section 3.

2. IETF Sub-namespace Specifics

Sub-namespace name:

"params"

Declared registrant of the IANA ftp archive caused large amounts namespace:

The Internet Engineering Task Force

Declaration of
confusion. A good example structure:

The namespace is primarily opaque. The IANA, as operator of the Mobile IP Numbers registry. Due
registry, may take suggestions for names to
having several very different concepts in assign but they
reserve the same file it is very
difficult right to understand where one assign whatever name they desire, within
guidelines set of parameters ends and another
begins.

The authors recommend that, in the future, by the IANA create
subdirectories in which each separate registry IESG. The colon character (":") is maintained in a
separate file. Also, document authors are encouraged used to suggest
denote 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 very limited concept of hierarchy. If a mapping between IP addresses and X.121 addresses.
It colon is not clear which value to use in present
then the name. items on both sides of it are valid names. 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 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 the list might look like this:

urn:ietf:params:dns:rr-type-codes:soa

Mealling, et. al. Expires February 18, April 29, 2002 [Page 4] 2]

Internet-Draft IANA URN Namespace August October 2001

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

Relevant ancillary documentation:

None.

[3], [2], [1]

Identifier uniqueness considerations:

The IESG uses the IETF concensus process to ensure that sub-
namespaces generate unique names within that sub-namespace. The
IESG delegates to the IANA has sole discretion for assigning the task of ensuring that the sub-
namespace names themselves are unique. Until and thus can
guarantee unless the IESG
specifies differently, the IANA is directed to ensure uniqueness
by comparing the name to be assigned with the list of previously
assigned names. In the case of a conflict the IANA is to request
a new string from the registrant until the conflict is resolved.

Identifier persistence considerations:

The IANA

Once a name has sole discretion been allocated it MUST NOT be re-allocated for assigning names and thus can
guarantee persistence by comparing a
different purpose. The rules provided for assignments of values
within a sub-namespace MUST be constructed so that the meaning of
values cannot change. This registration mechanism is not
appropriate for naming values whose meaning may change over time.
If a value that changes over time the assignment MUST name the
container or concept that contains the value, not the value
itself. For example, if a parameter called 'foo' has a value that
changes over time, it is valid to be assigned with create the list of previously assigned names. name
'urn:ietf:params:foo-params:foo' that identifies that 'slot'. It
is not valid to actually create a name that contains that value
unless it is a persistent and unique value such as a version
number.

Process of identifier assignment:

Mealling, et. al. Expires April 29, 2002 [Page 3]

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 procedures, or documented in an RFC describing a
standards track protocol. This means that the
repository, the IANA will take requests 'gating' function
for that element to have a
name assigned. The assignment request can suggest a name to use
but is the IANA may ignore that request. "IETF Concensus" process documented in RFC
2434 [4].

Process of identifier resolution:

At this time no resolution mechanism is defined though one is
expected. defined.

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 Syntax:

There are no additional characters reserved.

Validation mechanism:

None.

Scope:

Global

3. 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?).

Mealling, et. al. Expires April 29, 2002 [Page 4]

Internet-Draft IANA URN Namespace October 2001

The template:

Registry name: -- The name of the sub-namespace. In many cases this
should be the same name as what that the IANA calls 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. repository or the relevant RFCs that
document the items being named. 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 Description of how a registered value in the registry is
the index to each entry in that registry. This index value will be used
embedded in the URN to name each entry. In some cases it can
actually URI form. This MUST include details of any
transformations that may be needed for the thing being named, in others, where those values
can change, it should be an index resulting string to
conform to URN syntax rules and and any canonicalization needed so
that the record instead of
something in case-sensitive string comparison yields the record itself. expected
equivalences.

The process for requesting that a URN be assigned is currently to put
the above template or a reference to it in the IANA considerations
section of the specifying document. Other more automated processes
may be proposed at a latter time if demand requires it.

4. Security Considerations

None not already inherent to using URNs.

5. 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 To minimize the hope of administrative burden on IANA, any
parameter namespace registration is very clear about the authors criteria for
inclusion in that the required
strictness namespace.

Defining a registry that fits the constraints of a URN assignment puts on the registering document
authors namespace will actually make the IANA's job easier by taking the guess
work out
impose extra discipline that should take some of the guess-work about
creating a new and maintaining that registry.

References

[1] Moats, R., "URN Syntax", RFC 2141, May 1997.

Mealling, et. al. Expires April 29, 2002 [Page 5]

Internet-Draft IANA URN Namespace October 2001

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

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

[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

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,
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 94025 95110
US

Phone: +1 650 463 7059 408 536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net

Ted Hardie
Equinix
901 Marshall Street
Redwood City, CA 94063
US

EMail: hardie@equinix.com

Mealling, et. al. Expires April 29, 2002 [Page 6]

Internet-Draft IANA URN Namespace October 2001

Graham Klyne
Content Technologies Ltd.
1220 Parkview,
MIMEsweeper Group
1310 Waterside, Arlington Business Park
Theale, Reading RG7 4SA
UK

Phone: +44 118 930 1300
EMail: GK@ACM.ORG

Mealling, et. al. Expires February 18, April 29, 2002 [Page 8] 7]

Internet-Draft IANA URN Namespace August October 2001

Full Copyright Statement

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, April 29, 2002 [Page 9] 8]

----