draft-ietf-urn-net-procedures-01.txt		draft-ietf-urn-net-procedures-02.txt
	URN Working Group M.Mealling		Network Working Group M. Mealling
	INTERNET-DRAFT Network Solutions, Inc.		Internet-Draft Network Solutions, Inc.
	Expires six months from November 1998		Category: Informational February 1999
	Intended category: Experimental		Expires: August 02, 1999
	draft-ietf-urn-net-procedures-01.txt
	Assignment Procedures for the URI Resolution using DNS (RFC2168)		Assignment Procedures for URI Resolution using DNS
			draft-ietf-urn-net-procedures-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its		all provisions of Section 10 of RFC2026.
	areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		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		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other documents
	documents at any time. It is inappropriate to use Internet-		at any time. It is inappropriate to use Internet-Drafts as reference
	Drafts as reference material or to cite them other than as		material or to cite them other than as "work in progress."
	"work in progress."
	To view the entire list of current Internet-Drafts, please check		To view the entire list of Internet-Draft Shadow Directories, see
	the "1id-abstracts.txt" listing contained in the Internet-Drafts		http://www.ietf.org/shadow.html.
	Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
	(Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au		This Internet-Draft will expire on August 02, 1999.
	(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
	(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 URI delegation rules (sometimes		as a registry for retrieving URI delegation rules (sometimes called
	called resolution hints). That document specifies that the first step		resolution hints). That document specifies that the first step in
	in that algorithm is to append 'uri.net' to the URI scheme and retrieve		that algorithm is to append 'uri.net' to the URI scheme and retrieve
	the NAPTR record for that domain-name. I.e., the first step in		the NAPTR record for that domain-name. I.e., the first step in
	resolving "http://foo.com/" would be to look up a NAPTR record for		resolving "http://foo.com/" would be to look up a NAPTR record for
	the domain "http.uri.net". URN resolution also follows a similar		the domain "http.uri.net". URN resolution also follows a similar
	procedure but uses the 'urn.net' zone as its root. This document		procedure but uses the 'urn.net' zone as its root. This document
	describes the procedures for inserting a new rule into the 'uri.net'		describes the procedures for inserting a new rule into the 'uri.net'
	and 'urn.net' zones.		and 'urn.net' zones.
			Copyright Notice
			Copyright (C) The Internet Society (1999). All Rights Reserved.
			Table of Contents
			1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			2. URI Resolution vs URN Resolution . . . . . . . . . . . . . . . 3
			3. URI Registration Procedure . . . . . . . . . . . . . . . . . . 3
			4. URN Registration Procedure . . . . . . . . . . . . . . . . . . 3
			5. Requirements on rules . . . . . . . . . . . . . . . . . . . . 3
			6. Submission Procedure . . . . . . . . . . . . . . . . . . . . . 4
			7. Registration Template . . . . . . . . . . . . . . . . . . . . 5
			7.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
			7.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . . 5
			7.3 Records . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
			8. Example Template . . . . . . . . . . . . . . . . . . . . . . . 5
			9. The URN Registration in the uri.net zone . . . . . . . . . . . 5
			10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
			References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	This document defines the policies and procedures for inserting		This document defines the policies and procedures for inserting
	NAPTR records into the 'uri.net' and 'urn.net' zones for the purpose		NAPTR records into the 'uri.net' and 'urn.net' zones for the purpose
	of resolving URIs according to "Resolution of Uniform Resource		of resolving URIs according to "Resolution of Uniform Resource
	Identifiers using the Domain Name System", RFCXXXX [1], which is		Identifiers using the Domain Name System", RFCXXXX[1], which is an
	an application of the NAPTR DNS Resource Record defined in RFCXXXX [2].		application of the NAPTR DNS Resource Record defined in RFCXXXX[2].
	2. URI Resolution vs URN Resolution		2. URI Resolution vs URN Resolution
	RFCXXXX [1] defines how both URI resolution and URN [4] resolution work.		RFCXXXX[1] defines how both URI resolution and URN[3] resolution
	Specifically it says that all URIs rules are registered in 'uri.net'.		work. Specifically it says that all URIs rules are registered in
	Since a URN is a URI it follows the same rules. Thus one of the		'uri.net'. Since a URN is a URI it follows the same rules. Thus one
	rules in the 'uri.net' zone is the one for a URN. This rule states that		of the rules in the 'uri.net' zone is the one for a URN. This rule
	the namespace id [4] is extracted, 'urn.net' is appended to the end		states that the namespace id [4] is extracted, 'urn.net' is appended
	of the namespace id, and the next NAPTR record [2] is retrieved.		to the end of the namespace id, and the next NAPTR record[2] is
			retrieved.
	Mealling [Page 1]
	3. URI Registration Procedure		3. URI Registration Procedure
	At this time there is no set procedure for registering new URI schemes		At this time there is no set procedure for registering new URI
	other than a published RFC. Due to this lack and the existence of		schemes other than a published RFC. Due to this lack and the
	non-published schemes such as "about" and "res", there is an IETF		existence of non-published schemes such as "about" and "res", there
	working group discussing how to deal with this problem. Thus, at		is an IETF working group discussing how to deal with this problem.
	this time the only requirements for requesting an entry in the uri.net		Thus, at this time the only requirements for requesting an entry in
	zone is that the URI scheme be published or in use somewhere and that		the uri.net zone is that the URI scheme be published or in use
	it not conflict with an existing URI scheme.		somewhere and that 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 URI schemes, the 'uri.net' registration procedures MUST		registering new URI schemes, the 'uri.net' registration procedures
	adhere to those procedures for determining if the URI scheme in question		MUST adhere to those procedures for determining if the URI scheme in
	is valid.		question is valid.
	3. URN Registration Procedure		4. URN Registration Procedure
	RFCXXXX [7] defines the procedures for assignment of new URN		RFCXXXX[6] defines the procedures for assignment of new URN
	namespace-ids. Since the 'urn.net' registration procedures only deal		namespace-ids. Since the 'urn.net' registration procedures only
	with the namespace-id portion of the URN space, that document is the		deal with the namespace-id portion of the URN space, that document
	sole determining document for what can be entered into the urn.net zone		is the sole determining document for what can be entered into the
	for a URN.		urn.net zone for a URN.
	4. Requirements on rules		5. Requirements on rules
	Delegation of a namespace can happen in two ways. In the case of most		Delegation of a namespace can happen in two ways. In the case of
	URIs where the entity being delegated to is hard-coded into the		most 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
	In the case where the entity being delegated to is set in the rule,		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 both the URI and URN registries		One of the optimizations that the both the URI and URN registries
	attempts to make is that any entry in that zone should have an		attempts to make is that any entry in that zone should have an
	extremely long time to live. 'Extremely long' should be measured in		extremely long time to live. 'Extremely long' should be measured in
	years if possible. Thus, any rule that can change must be delegated		years if possible. Thus, any rule that can change must be delegated
	out of the urn.net zone by a replacement rule in the NAPTR record.		out of the urn.net zone by a replacement rule in the NAPTR record.
	For example, the 'foo' URN namespace has flexible rules for how		For example, the 'foo' URN namespace has flexible rules for how
	delegation takes place. Instead of putting those rules in the		delegation takes place. Instead of putting those rules in the
	urn.net zone, the entry instead punts those rules off to a nameserver		urn.net zone, the entry instead punts those rules off to a
	that has a shorter time to live. The record in urn.net would look		nameserver that has a shorter time to live. The record in urn.net
	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 second		Thus, when the client starts out in the resolution process, the
	step is to begin asking 'urn-resolver.foo.com' for the NAPTR records		second step is to begin asking 'urn-resolver.foo.com' for the NAPTR
	that contain the resolution rules. The TTL at the root is very long.		records that contain the resolution rules. The TTL at the root is
	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' URL scheme adheres to a particular syntax
	specifies that the host to ask is specified in the URL in question.		that specifies that the host to ask is specified in the URL in
	Since this syntax does not change, that rule can be specified in the		question. Since this syntax does not change, that rule can be
	uri.net zone. The record would look like this:		specified in the 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		6. Submission Procedure
	Using the MIME Content-Type registration mechanism [6] as a		Using the MIME Content-Type registration mechanism[5]as a model for
	model for a successful registration mechanism, the 'uri.net' and		a successful registration mechanism, the 'uri.net' and 'urn.net'
	'urn.net' procedures consist of a request template submitted to an		procedures consist of a request template submitted to an open
	open mailing list made up of interested parties. If no objections		mailing list made up of interested parties. If no objections are
	are made within a two week period, a representative of the registration		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
	that submission into the nameserver.		submission into the nameserver.
	Registrations for the 'uri.net' zone are sent to 'register@uri.net'.		o Registrations for the 'uri.net' zone are sent to
	Registrations for the 'urn.net' zone are sent to 'register@urn.net'.		'register@uri.net'.
			o 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
	the zone itself or to DNS in general. Objections to the URL		zone itself or to DNS in general. Objections to the URL scheme or to
	scheme or to the URN namespace-id are not allowed, as these should		the URN namespace-id are not allowed, as these should be raised in
	be raised in their respective forums. The logical conclusion of		their respective forums. The logical conclusion of this is that ANY
	this is that ANY sanctioned URL scheme or URN namespace MUST		sanctioned URL scheme or URN namespace MUST be allowed to be
	be allowed to be registered if it meets the requirements specified		registered if it meets the requirements specified in this document
	in this document as regards times to live and general impact		as regards times to live and general impact to the DNS.
	to the DNS.
	6. Registration Template		7. 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.2 Key		7.1 Key
	This is the domain portion. It must be valid according to the		This is the URN NID or URL scheme, which is used as the domain
	procedures specified in the URN namespace-id assignment document		portion of the DNS entry. It must be valid according to the
	and any future standards for registering new URL schemes.		procedures specified in the URN namespace-id assignment document and
			any future standards for registering new URL schemes.
	6.3 Authority		7.2 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 any authority
	specified in the documents submitted for approval by any URN or URL		defined in the URN NID[6] or URL scheme registration[7] documents.
	registration mechanism.
	6.4 Records
	One or more records representing the rule set for the key. The required		7.3 Records
	values are Preference, Order, Flags, Services, Regex, and Replacement
	as defined by RFC2168.
	Mealling [Page 3]		The actual DNS records representing the rule set for the key. The
			required values are Preference, Order, Flags, Services, Regex, and
			Replacement as defined by RFCXXXX[2].
	7. Example Template		8. Example Template
	To: register@urn.net		To: register@urn.net
	From: joe@foo.com		From: joe@foo.com
	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		9. The URN Registration in the uri.net zone
	Since this document discusses the uri.net and urn.net zones and the		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		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:		regisration template for the URN URI rule to be specified here:
	To: register@uri.net		To: register@uri.net
	From: The IETF URN Working Group		From: The IETF URN Working Group
	Key: urn		Key: urn
	Authority: RFC2141		Authority: RFC2141
	Record: urn IN NAPTR 0 0 "" "" "/urn:([^:]+)/\\2/i" .		Record: urn IN NAPTR 0 0 "" "" "/urn:([^:]+)/\\2/i" .
	8. IANA Considerations		10. IANA Considerations
	This document describes a mechanism for registering representations of		This document describes a mechanism for registering representations
	protocol items that have already been registered with some IETF		of 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
	need not determine appropriateness of the underlying namespaces,		IANA need not determine appropriateness of the underlying
	since that is determined by another process.		namespaces, 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		o to maintain (or designate some other entity to maintain) a
	nameserver for the uri.net and urn.net zones;		primary nameserver for the uri.net and urn.net zones;
			o to maintain the mailing lists "register@uri.net" and
	to maintain the mailing lists "register@uri.net" and		"register@uri.net" as the forum for discussions of submissions;
	"register@uri.net" as the forum for discussions of submissions; and		and
			o 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]		References
	7. References
	[1] M. Mealling, R. Daniel, "Resolution of Uniform		[1] Mealling, M., Daniel, R., "Resolution of Uniform Resource
	Resource Identifiers using the Domain Name System",		Identifiers using the Domain Name System", November 1998.
	<draft-ietf-urn-dns-rds-00.txt>. November 1998.
	[2] M. Mealling, R. Daniel, "The Naming Authority Pointer (NAPTR)		[2] Mealling, M., Daniel, R., "The Naming Authority Pointer (NAPTR)
	DNS Resource Record". <draft-ietf-urn-naptr-rr-00.txt>.		DNS Resource Record", November 1998.
	November 1998.
	[3] K. Sollins, "Architectural Principles of Uniform Resource		[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
	Name Resolution", RFC 2276, January 1998.
	[4] Ryan Moats, "URN Syntax", RFC 2141, May 1997.		[4] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource
			Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
	[5] T. Berners-Lee, R. Fielding, L. Masinter. "Uniform		[5] Freed, N., Klensin, J., Postel, J., "Multipurpose Internet Mail
	Resource Identifiers (URI): Generic Syntax", RFC 2396,		Extensions (MIME) Part Four: Registration Procedures", RFC
	August 1998.		2048, November 1996.
	[6] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet		[6] Faltstrom, P., Iannella, R., Daigle, L., van Gulik, D., "URN
	Mail Extensions (MIME) Part Four: Registration Procedures",		Namespace Definition Mechanisms", October 1998.
	RFC 2048, November 1996.
	[7] P. Faltstrom, R. Iannella, L. Daigle, D. van Gulik, "URN		[7] Petke, R., King, I., "Registration Procedures for URL Scheme
	Namespace Definition Mechanisms", 10/26/1998,		Names", January 1999.
	<draft-ietf-urn-nid-req-07.txt>
	8. Author Contact Information		Author's Address
	Michael Mealling		Michael Mealling
	Network Solutions		Network Solutions, Inc.
	505 Huntmar Park Drive		505 Huntmar Park Drive
	Herndon, VA 22070		Herndon, VA 22070
	voice: (703) 742-0400		US
	fax: (703) 742-9552
	email: michaelm@rwhois.net
	Mealling [Page 5]		Phone: +1 770 935 5492
			EMail: michaelm@netsol.com
			URI: http://www.netsol.com
			Full Copyright Statement
			Copyright (C) The Internet Society (1999). 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 implmentation 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.
End of changes. 47 change blocks.
	141 lines changed or deleted		150 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/