draft-ietf-urn-net-procedures-09.txt   draft-ietf-urn-net-procedures-10.txt 
Network Working Group M. Mealling Network Working Group M. Mealling
Internet-Draft Verisign Internet-Draft VeriSign
Expires: April 28, 2002 October 28, 2001 Expires: August 20, 2002 February 19, 2002
Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA
Assignment Procedures Assignment Procedures
draft-ietf-urn-net-procedures-09.txt draft-ietf-urn-net-procedures-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2002. This Internet-Draft will expire on August 20, 2002.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract Abstract
RFCYYYY defines a how DNS is used as a DDDS database that contains RFCYYYY defines a how DNS is used as a DDDS database that contains
URI delegation rules (sometimes called resolution hints). That URI delegation rules (sometimes called resolution hints). That
document specifies that the first step in that algorithm is to append document specifies that the first step in that algorithm is to append
'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that
domain-name. I.e., the first step in resolving "http://foo.com/" domain-name. I.e., the first step in resolving "http://foo.com/"
would be to look up a NAPTR record for the domain "http.URI.ARPA". would be to look up a NAPTR record for the domain "http.URI.ARPA".
URN resolution also follows a similar procedure but uses the URN resolution also follows a similar procedure but uses the
skipping to change at page 5, line 17 skipping to change at page 5, line 17
IESG or its designated experts. IESG or its designated experts.
Note that this applies to all NAPTR records for a particular NID, Note that this applies to all NAPTR records for a particular NID,
even though a NAPTR record might affect only part of the URN space even though a NAPTR record might affect only part of the URN space
assigned to an NID assigned to an NID
4. Requirements on hints 4. Requirements on hints
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 URIs, the key being delegated to is hard-coded into the most URIs, the key being delegated to is hard-coded into the
identifier itself (e.g. a hostname in an HTTP URL). The syntax of identifier itself (e.g. a hostname in an HTTP URI). The syntax of
where this new key is located is predetermined by the syntax of the where this new key is located is predetermined by the syntax of the
scheme. In other cases, the new key can be part of the hint itself. scheme. In other cases, the new key can be part of the hint itself.
This is the functional equivalent of saying, "if this rule matches This is the functional equivalent of saying, "if this rule matches
then this is always the key." then this is always the key."
In order to minimize the query load on the URI.ARPA and URN.ARPA In order to minimize the query load on the URI.ARPA and URN.ARPA
zones, it is anticipated that the resource records in those zones zones, it is anticipated that the resource records in those zones
will have extremely long "times to live" (TTLs), perhaps measured in will have extremely long "times to live" (TTLs), perhaps measured in
years. years.
skipping to change at page 5, line 48 skipping to change at page 5, line 48
would look like this: 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 first Thus, when the client starts out in the resolution process, the first
step will be to query foo.URN.ARPA to find the above record, the step will be to query foo.URN.ARPA to find the above record, the
second step is to begin asking 'urn-resolver.foo.com' for the NAPTR second step is to begin asking 'urn-resolver.foo.com' for the NAPTR
records that contain the resolution rules. The TTL at the root is records that contain the resolution rules. The TTL at the root is
very long. The TTL at the 'urn-resolver.foo.com' is much shorter. 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' URI 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 URI 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
URI.ARPA zone. The record would look like this: URI.ARPA zone. The record would look like this:
http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" . http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" .
Thus, the second step of resolution is to use the domain-name found Thus, the second step of resolution is to use the domain-name found
in the URL as the next key in the cycle. If, for example, that NAPTR in the URI as the next key in the cycle. If, for example, that NAPTR
was terminal and contains some hostname in the replacement field, was terminal and contains some hostname in the replacement field,
then the client could contact that host in order to ask questions then the client could contact that host in order to ask questions
about this particular URI. about this particular URI.
5. Submission Procedure 5. Submission Procedure
Using the MIME Content-Type registration mechanism [8] as a model Using the MIME Content-Type registration mechanism [8] as a model
for a successful registration mechanism, the 'URI.ARPA' and for a successful registration mechanism, the 'URI.ARPA' and
'URN.ARPA' procedures consist of a request template submitted to an 'URN.ARPA' procedures consist of a request template submitted to an
open mailing list made up of interested parties. If no objections open mailing list made up of interested parties. If no objections
skipping to change at page 6, line 33 skipping to change at page 6, line 33
o Registrations for the 'URI.ARPA' zone are sent to o Registrations for the 'URI.ARPA' zone are sent to
'register@URI.ARPA'. 'register@URI.ARPA'.
o Registrations for the 'URN.ARPA' zone are sent to o Registrations for the 'URN.ARPA' zone are sent to
'register@URN.ARPA'. 'register@URN.ARPA'.
The registration authority is the Internet Assigned Numbers Authority The registration authority is the Internet Assigned Numbers Authority
(IANA). (IANA).
Objections are restricted to those that point out impacts on the zone Objections are restricted to those that point out impacts on the zone
itself or to DNS in general. Objections to the URL scheme or to the itself or to DNS in general. Objections to the URI scheme or to the
URN namespace-id are not allowed, as these should be raised in their URN namespace-id are not allowed, as these should be raised in their
respective forums. The logical conclusion of this is that ANY respective forums. The logical conclusion of this is that ANY
sanctioned URL scheme or URN namespace MUST be allowed to be sanctioned URI scheme or URN namespace MUST be allowed to be
registered if it meets the requirements specified in this document as registered if it meets the requirements specified in this document as
regards times to live and general impact to the DNS. regards times to live and general impact to the DNS.
6. Registration Template 6. Registration Template
The template to be sent to the appropriate list MUST contain the The template to be sent to the appropriate list MUST contain the
following values: following values:
6.1 Key 6.1 Key
This is the URN NID or URL scheme, which is used as the domain This is the URN NID or URI scheme, which is used as the domain
portion of the DNS entry. It must be valid according to the portion of the DNS entry. It must be valid according to the
procedures specified in the URN namespace-id assignment document and procedures specified in the URN namespace-id assignment document and
any future standards for registering new URL schemes. any future standards for registering new URI schemes.
6.2 Authority 6.2 Authority
This is the individual or organization (entity) which has authority This is the individual or organization (entity) which has authority
for registering the record. It must be an authority recognized as for registering the record. It must be an authority recognized as
either the IESG or any authority defined in the URN NID [9] or URL either the IESG or any authority defined in the URN NID [9] or URI
scheme registration [10] documents. scheme registration [10] documents.
6.3 Records 6.3 Records
The actual DNS records representing the rule set for the key. The The actual DNS records representing the rule set for the key. The
required values are Preference, Order, Flags, Services, Regex, and required values are Preference, Order, Flags, Services, Regex, and
Replacement as defined by RFCYYYY [4]. Replacement as defined by RFCYYYY [4].
7. Example Template 7. Example Template
skipping to change at page 8, line 31 skipping to change at page 8, line 31
The author would like to thank Ron Daniel who was originally co- The author would like to thank Ron Daniel who was originally co-
author of these documents. Ron's original insite into the intricate author of these documents. Ron's original insite into the intricate
nature of delegation rules made these procedures and the DDDS itself nature of delegation rules made these procedures and the DDDS itself
possible. possible.
References References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf-
urn-ddds-toc-00.txt (work in progress), October 2001. urn-ddds-toc-02.txt (work in progress), February 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-06.txt (work
in progress), May 2000. in progress), February 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds-
database-07.txt (work in progress), May 2000. database-08.txt (work in progress), February 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC YYYY, draft-ietf- Four: The URI Resolution Application", RFC YYYY, draft-ietf-
urn-uri-res-ddds-05.txt (work in progress), October 2000. urn-uri-res-ddds-06.txt (work in progress), February 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf-
urn-net-procedures-09.txt (work in progress), October 2001. urn-net-procedures-10.txt (work in progress), February 2002.
[6] Moats, R., "URN Syntax", RFC 2141, November 1998. [6] Moats, R., "URN Syntax", RFC 2141, November 1998.
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998. 1998.
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet [8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", RFC Mail Extensions (MIME) Part Four: Registration Procedures", RFC
2048, November 1996. 2048, November 1996.
[9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN [9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN
Namespace Definition Mechanisms", RFC 2611, October 1998. Namespace Definition Mechanisms", RFC 2611, October 1998.
[10] Petke, R. and I. King, "Registration Procedures for URL Scheme [10] Petke, R. and I. King, "Registration Procedures for URL Scheme
Names", RFC 2717, January 1999. Names", RFC 2717, January 1999.
Author's Address Author's Address
Michael Mealling Michael Mealling
Verisign VeriSign
505 Huntmar Park Drive 21345 Ridgetop Circle
Herndon, VA 22070 Sterling, VA 20166
US US
Phone: (770) 721-2251 EMail: michael@neonym.net
EMail: michael@research.netsol.com URI: http://www.verisignlabs.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 20 change blocks. 
26 lines changed or deleted 26 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/