draft-ietf-urn-net-procedures-00.txt   draft-ietf-urn-net-procedures-01.txt 
URN Working Group M.Mealling URN Working Group M.Mealling
INTERNET-DRAFT Network Solutions, Inc. INTERNET-DRAFT Network Solutions, Inc.
Expires six months from November 1998
Intended category: Experimental Intended category: Experimental
draft-ietf-urn-net-procedures-00.txt draft-ietf-urn-net-procedures-01.txt
Assignment Procedures for the URI Resolution using DNS (RFC2168) Assignment Procedures for the URI Resolution using DNS (RFC2168)
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its
and its working groups. Note that other groups may also distribute areas, and its working groups. Note that other groups may also
working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at months and may be updated, replaced, or obsoleted by other
any time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as work in progress. Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
Abstract Abstract
RFC2168 defines a DNS resource record and an algorithm for using DNS RFC2168 defines a DNS resource record and an algorithm for using DNS
as a registry for retrieving URN authority delegation rules (sometimes as a registry for retrieving URI delegation rules (sometimes
called resolution hints). That document specifies that the first step called resolution hints). That document specifies that the first step
in that algorithm is to lookup the first NAPTR record for the namespace- in that algorithm is to append 'uri.net' to the URI scheme and retrieve
id in the "urn.net" zone; i.e., the first step in resolving the NAPTR record for that domain-name. I.e., the first step in
"urn:ietf:rfc:2168" would be to lookup a NAPTR record for the domain resolving "http://foo.com/" would be to look up a NAPTR record for
"ietf.urn.net". This document describes the procedures for inserting the domain "http.uri.net". URN resolution also follows a similar
a new rule into this DNS-based URI resolution registry. procedure but uses the 'urn.net' zone as its root. This document
describes the procedures for inserting a new rule into the 'uri.net'
and 'urn.net' zones.
1. Introduction 1. Introduction
In the course of defining a resolution mechanism [RFC2168] according This document defines the policies and procedures for inserting
to the rules in RFC2276 [RFC2276] for Uniform Resource Names [RFC2141], NAPTR records into the 'uri.net' and 'urn.net' zones for the purpose
it became apparent that the same system could be used to resolve of resolving URIs according to "Resolution of Uniform Resource
URIs [RFC1738] in the general case. Thus, RFC2168 was specified in Identifiers using the Domain Name System", RFCXXXX [1], which is
such a way as to be generic in its discussions of URNs vs URLs. The an application of the NAPTR DNS Resource Record defined in RFCXXXX [2].
end result of this is that RFC2168 defines two things: a Resolver
Discovery System registry for URNs and a resolver discovery system
for URLs. While this may not seem an important distinction to the
casual reader there are some important distinctions in terms of
creating new URN namespaces and new URI schemes. Thus, its
assignment procedures for the RFC2168 defines registry must adhere
to the procedures defined in the assignment documents of both systems.
At the same time this document must also define its own procedures, 2. URI Resolution vs URN Resolution
which will ensure its stability and impact on the Domain Name System.
These include optimizations such as an extremely long time to live
on the values in the urn.net zone and efficient uses of delegations
to minimize delegation loops.
2. URL Resolution RFCXXXX [1] defines how both URI resolution and URN [4] resolution work.
Specifically it says that all URIs rules are registered in 'uri.net'.
Since a URN is a URI it follows the same rules. Thus one of the
rules in the 'uri.net' zone is the one for a URN. This rule states that
the namespace id [4] is extracted, 'urn.net' is appended to the end
of the namespace id, and the next NAPTR record [2] is retrieved.
At this time there is no set procedure for registering new URL schemes Mealling [Page 1]
3. URI Registration Procedure
At this time there is no set procedure for registering new URI schemes
other than a published RFC. Due to this lack and the existence of other than a published RFC. Due to this lack and the existence of
non-published schemes such as "about" and "res", there is an IETF non-published schemes such as "about" and "res", there is an IETF
working group discussing how to deal with this problem. Thus, at working group discussing how to deal with this problem. Thus, at
this time the only requirements for requesting an entry in the urn.net this time the only requirements for requesting an entry in the uri.net
zone is that the URL scheme be published or in use somewhere and that zone is that the URI scheme be published or in use somewhere and that
it not conflict with an existing URL scheme. it not conflict with an existing URI scheme.
When the IETF does standardize a set of procedures for vetting and When the IETF does standardize a set of procedures for vetting and
registering new URL schemes, the urn.net registration procedures MUST registering new URI schemes, the 'uri.net' registration procedures MUST
adhere to those procedures for determining if the URL scheme in question adhere to those procedures for determining if the URI scheme in question
is valid. is valid.
3. URN Resolution 3. URN Registration Procedure
RFCXXXX defines the procedures for assignment of new URN namespace-ids. RFCXXXX [7] defines the procedures for assignment of new URN
Since the urn.net registration procedures only deal with the namespace-ids. Since the 'urn.net' registration procedures only deal
namespace-id portion of the URN space, that document is the sole with the namespace-id portion of the URN space, that document is the
determining document for what can be entered into the urn.net zone sole determining document for what can be entered into the urn.net zone
for a URN. for a URN.
4. Delegation Requirements 4. Requirements on rules
Delegation of a namespace can happen in two ways. In the case of Delegation of a namespace can happen in two ways. In the case of most
a URL where the entity being delegated to is hard-coded into the URIs where the entity being delegated to is hard-coded into the
identifier itself, the syntax of where this is located is set. identifier itself, the syntax of where this is located is set.
In the case where the entity being delegated to is set in the rule, In the case where the entity being delegated to is set in the rule,
that entity can change as the rule changes. that entity can change as the rule changes.
One of the optimizations that the urn.net registry attempts to make One of the optimizations that the both the URI and URN registries
is that any entry in that zone should have an extremely long attempts to make is that any entry in that zone should have an
time to live. 'Extremely long' should be measured in years if possible. extremely long time to live. 'Extremely long' should be measured in
Thus, any rule that can change must be delegated out of the urn.net years if possible. Thus, any rule that can change must be delegated
zone by a replacement rule in the NAPTR record. For example, the 'foo' out of the urn.net zone by a replacement rule in the NAPTR record.
URN namespace has flexible rules for how delegation takes place. Instead For example, the 'foo' URN namespace has flexible rules for how
of putting those rules in the urn.net zone, the entry instead punts delegation takes place. Instead of putting those rules in the
those rules off to a nameserver that has a shorter time to live. The urn.net zone, the entry instead punts those rules off to a nameserver
record in urn.net would look like this: that has a shorter time to live. The record in urn.net would look
like this:
foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com. foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com.
Thus, when the client starts out in the resolution process, the second Thus, when the client starts out in the resolution process, the second
step is to begin asking 'urn-resolver.foo.com' for the NAPTR records step is to begin asking 'urn-resolver.foo.com' for the NAPTR records
that contain the resolution rules. that contain the resolution rules. The TTL at the root is very long.
The TTL at the 'urn-resolver.foo.com' is much shorter.
Conversely, the 'http' URL scheme adheres to a particular syntax that Conversely, the 'http' URL scheme adheres to a particular syntax that
specifies that the host to ask is specified in the URL in question. specifies that the host to ask is specified in the URL in question.
Since this syntax does not change, that rule can be specified in the Since this syntax does not change, that rule can be specified in the
urn.net zone. The record would look like this: uri.net zone. The record would look like this:
http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" . http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" .
Mealling [Page 2]
Thus, the second step of resolution is to attempt to contact the Thus, the second step of resolution is to attempt to contact the
host contained in the URL itself. host contained in the URL itself.
5. Submission Procedure 5. Submission Procedure
Using the MIME Content-Type registration mechanism [RFC2048] as a Using the MIME Content-Type registration mechanism [6] as a
model for a successful registration mechanism, the urn.net procedure model for a successful registration mechanism, the 'uri.net' and
consists of a request template submitted to a open mailing list 'urn.net' procedures consist of a request template submitted to an
made up of interested parties. If no objections are made within open mailing list made up of interested parties. If no objections
a two week period, a representative of the urn.net registration are made within a two week period, a representative of the registration
authority considers the submission to be accepted and enters authority considers the submission to be accepted and enters
that submission into the nameserver. that submission into the nameserver.
Registrations for the 'uri.net' zone are sent to 'register@uri.net'.
Registrations for the 'urn.net' zone are sent to 'register@urn.net'.
At this time the registration authority is expected to be the IANA. At this time the registration authority is expected to be the IANA.
Objections are restricted to those that point out impacts on Objections are restricted to those that point out impacts on
the urn.net zone itself or to DNS in general. Objections to the URL the zone itself or to DNS in general. Objections to the URL
scheme or to the URN namespace-id are not allowed, as these should scheme or to the URN namespace-id are not allowed, as these should
be raised in their respective forums. The logical conclusion of be raised in their respective forums. The logical conclusion of
this is that ANY sanctioned URL scheme or URN namespace MUST this is that ANY sanctioned URL scheme or URN namespace MUST
be allowed to be registered if it meets the requirements specified be allowed to be registered if it meets the requirements specified
in this document as regards times to live and general impact in this document as regards times to live and general impact
to the DNS. to the DNS.
Updating a record in the urn.net zone also requires that the same
process to be followed. Since urn.net is designed with a long time to
live, changes to records in that zone are discouraged. Thus updates
must follow the same procedures as a new request. Changes will
be given a higher level of scrutiny, as they may represent
potential problems with a specific delegation.
6. Registration Template 6. Registration Template
The template to be sent to the list MUST contain the following The template to be sent to the appropriate list MUST contain the
values: following values:
6.1 Type
Either SCHEME or NID. SCHEME specifies that the record being registered
represents a URL scheme. NID specifies that it is a URN namespace-id.
6.2 Key 6.2 Key
This is the domain portion. It must be valid according to the This is the domain portion. It must be valid according to the
procedures specified in the URN namespace-id assignment document procedures specified in the URN namespace-id assignment document
and any future standards for registering new URL schemes. and any future standards for registering new URL schemes.
6.3 Authority 6.3 Authority
This is the authority doing the registration of the record. It must This is the authority doing the registration of the record. It must
be an authority recognized as either the IESG or an authority be an authority recognized as either the IESG or an authority
specified in the documents submitted for approval by any URN or URL specified in the documents submitted for approval by any URN or URL
registration mechanism. registration mechanism.
6.4 Records 6.4 Records
One or more records representing the rule set for the key. The required One or more records representing the rule set for the key. The required
values are Preference, Order, Flags, Services, Regex, and Replacement values are Preference, Order, Flags, Services, Regex, and Replacement
as defined by RFC2168. as defined by RFC2168.
Mealling [Page 3]
7. Example Template 7. Example Template
To: register@urn.net To: register@urn.net
From: joe@foo.com From: joe@foo.com
Type: NID
Key: foo Key: foo
Authority: Foo Technology, Inc as specified in RFCFOO Authority: Foo Technology, Inc as specified in RFCFOO
Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com. Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com.
8. The URN Registration in the uri.net zone
Since this document discusses the uri.net and urn.net zones and the
URN rule that exists in the uri.net zone, it makes sense for the
regisration template for the URN URI rule to be specified here:
To: register@uri.net
From: The IETF URN Working Group
Key: urn
Authority: RFC2141
Record: urn IN NAPTR 0 0 "" "" "/urn:([^:]+)/\\2/i" .
8. IANA Considerations 8. IANA Considerations
This document describes a mechanism for registering representations of This document describes a mechanism for registering representations of
protocol items that have already been registered with some IETF protocol items that have already been registered with some IETF
sanctioned agency (probably the IANA as well). This means that the IANA sanctioned agency (probably the IANA as well). This means that the IANA
need not determine appropriateness of the underlying namespaces, need not determine appropriateness of the underlying namespaces,
since that is determined by another process. since that is determined by another process.
The only real impact on the IANA will be: The only real impact on the IANA will be
to maintain (or designate some other entity to maintain) a primary to maintain (or designate some other entity to maintain) a primary
nameserver for the urn.net zone; nameserver for the uri.net and urn.net zones;
to maintain the mailing list "register@urn.net" as the forum for to maintain the mailing lists "register@uri.net" and
discussions of submissions; and "register@uri.net" as the forum for discussions of submissions; and
to act as the party that determines if all objections have been to act as the party that determines if all objections have been
noted and accommodated. noted and accommodated.
Mealling [Page 4]
7. References 7. References
[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform [1] M. Mealling, R. Daniel, "Resolution of Uniform
Resource Identifiers using the Domain Name System", RFC 2168, Resource Identifiers using the Domain Name System",
June 1997. <draft-ietf-urn-dns-rds-00.txt>. November 1998.
[RFC2276] K. Sollins, "Architectural Principles of Uniform Resource [2] M. Mealling, R. Daniel, "The Naming Authority Pointer (NAPTR)
DNS Resource Record". <draft-ietf-urn-naptr-rr-00.txt>.
November 1998.
[3] K. Sollins, "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998. Name Resolution", RFC 2276, January 1998.
[RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. [4] Ryan Moats, "URN Syntax", RFC 2141, May 1997.
[RFC1738] T. Berners-Lee, L. Masinter and M. McCahill, [5] T. Berners-Lee, R. Fielding, L. Masinter. "Uniform
"Uniform Resource Locators (URL)" RFC 1738, December 1994. Resource Identifiers (URI): Generic Syntax", RFC 2396,
<URL:ftp://ftp.internic.net/rfc/rfc1738.txt> August 1998.
[RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet [6] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", Mail Extensions (MIME) Part Four: Registration Procedures",
RFC 2048, November 1996. RFC 2048, November 1996.
[7] P. Faltstrom, R. Iannella, L. Daigle, D. van Gulik, "URN
Namespace Definition Mechanisms", 10/26/1998,
<draft-ietf-urn-nid-req-07.txt>
8. Author Contact Information 8. Author Contact Information
Michael Mealling Michael Mealling
Network Solutions Network Solutions
505 Huntmar Park Drive 505 Huntmar Park Drive
Herndon, VA 22070 Herndon, VA 22070
voice: (703) 742-0400 voice: (703) 742-0400
fax: (703) 742-9552 fax: (703) 742-9552
email: michaelm@rwhois.net email: michaelm@rwhois.net
This document expires 6 months from June, 1997 Mealling [Page 5]
 End of changes. 40 change blocks. 
93 lines changed or deleted 113 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/