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/