draft-ietf-iri-4395bis-irireg-00.txt		draft-ietf-iri-4395bis-irireg-01.txt
	Network Working Group T. Hansen		Network Working Group T. Hansen
	Internet-Draft AT&T Laboratories		Internet-Draft AT&T Laboratories
	Obsoletes: 4395 (if approved) T. Hardie		Obsoletes: 4395 (if approved) T. Hardie
	Intended status: BCP Panasonic Wireless Research Lab		Intended status: BCP Panasonic Wireless Research Lab
	Expires: April 11, 2011 L. Masinter		Expires: September 30, 2011 L. Masinter
	Adobe Systems		Adobe
	October 8, 2010		March 29, 2011
	Guidelines and Registration Procedures for New URI/IRI Schemes		Guidelines and Registration Procedures for New URI/IRI Schemes
	draft-ietf-iri-4395bis-irireg-00		draft-ietf-iri-4395bis-irireg-01
	Abstract		Abstract
	This document updates the guidelines and recommendations for the		This document updates the guidelines and recommendations for the
	definition of Uniform Resource Identifier (URI) schemes, and extends		definition of Uniform Resource Identifier (URI) schemes, and extends
	the registry and guidelines to apply when the schemes are used with		the registry and guidelines to apply when the schemes are used with
	Internationalized Resource Identifiers (IRIs). It also updates the		Internationalized Resource Identifiers (IRIs). It also updates the
	process and IANA registry for URI/IRI schemes. It obsoletes RFC		process and IANA registry for URI/IRI schemes. It obsoletes RFC
	4395.		4395.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on April 11, 2011.		This Internet-Draft will expire on September 30, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Well-Defined . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6		3.4. Definition of Operations . . . . . . . . . . . . . . . . . 6
	3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7		3.5. Context of Use . . . . . . . . . . . . . . . . . . . . . . 7
	3.6. Internationalization and Character Encoding . . . . . . . 7		3.6. Internationalization and Character Encoding . . . . . . . 7
	3.7. Clear Security Considerations . . . . . . . . . . . . . . 7		3.7. Clear Security Considerations . . . . . . . . . . . . . . 7
	3.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 8		3.8. Scheme Name Considerations . . . . . . . . . . . . . . . . 8
	4. Guidelines for Provisional URI/IRI Scheme Registration . . . . 8		4. Guidelines for Provisional URI/IRI Scheme Registration . . . . 8
	5. Guidelines for Historical URI/IRI Scheme Registration . . . . 9		5. Guidelines for Historical URI/IRI Scheme Registration . . . . 9
	6. URI/IRI Scheme Registration Procedure . . . . . . . . . . . . 9		6. URI/IRI Scheme Registration Procedure . . . . . . . . . . . . 9
	6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Registration Procedures . . . . . . . . . . . . . . . . . 9		6.2. Registration Procedures . . . . . . . . . . . . . . . . . 10
	6.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 11		6.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 11
	6.4. URI/IRI Scheme Registration Template . . . . . . . . . . . 11		6.4. URI/IRI Scheme Registration Template . . . . . . . . . . . 11
	7. The "example" Scheme . . . . . . . . . . . . . . . . . . . . . 12		7. The "example" Scheme . . . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 14		Appendix A. Changes Since RFC 4395 . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . . 14		11.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Uniform Resource Identifier (URI) protocol element and generic		The Uniform Resource Identifier (URI) protocol element and generic
	syntax is defined by [RFC3986]. Each URI begins with a scheme name,		syntax is defined by [RFC3986]. Each URI begins with a scheme name,
	as defined by Section 3.1 of RFC 3986, that refers to a specification		as defined by Section 3.1 of RFC 3986, that refers to a specification
	for identifiers within that scheme. The URI syntax provides a		for identifiers within that scheme. The URI syntax provides a
	federated and extensible naming system, where each scheme's		federated and extensible naming system, where each scheme's
	specification may further restrict the syntax and semantics of		specification may further restrict the syntax and semantics of
	skipping to change at page 5, line 24		skipping to change at page 5, line 24
	global namespace; it is desirable to avoid contention over use of		global namespace; it is desirable to avoid contention over use of
	short, mnemonic scheme names. For these reasons, the unbounded		short, mnemonic scheme names. For these reasons, the unbounded
	registration of new schemes is harmful. New URI/IRI schemes SHOULD		registration of new schemes is harmful. New URI/IRI schemes SHOULD
	have clear utility to the broad Internet community, beyond that		have clear utility to the broad Internet community, beyond that
	available with already registered URI/IRI schemes.		available with already registered URI/IRI schemes.
	3.2. Syntactic Compatibility		3.2. Syntactic Compatibility
	[RFC3986] defines the generic syntax for all URI schemes, along with		[RFC3986] defines the generic syntax for all URI schemes, along with
	the syntax of common URI components that are used by many URI schemes		the syntax of common URI components that are used by many URI schemes
	to define hierarchical identifiers. [RFC3987] and [RFC3987bis]		to define hierarchical identifiers. [RFC3987] and subsequently
	extended this generic syntax to cover IRIs. All URI/IRI scheme		[RFC3987bis] extended this generic syntax to cover IRIs. All URI/IRI
	specifications MUST define their own syntax such that all strings		scheme specifications MUST define their own syntax such that all
	matching their scheme-specific syntax will also match the		strings matching their scheme-specific syntax will also match the
	<absolute-URI> grammar described in [RFC3987bis].		<absolute-URI> grammar described in [RFC3987bis].
	New schemes SHOULD reuse the common components of [RFC3987bis] for		New schemes SHOULD reuse the common components of [RFC3987bis] for
	the definition of hierarchical naming schemes. However, if there is		the definition of hierarchical naming schemes. However, if there is
	a strong reason for a scheme not to use the hierarchical syntax, then		a strong reason for a scheme not to use the hierarchical syntax, then
	the new scheme definition SHOULD follow the syntax of previously		the new scheme definition SHOULD follow the syntax of previously
	registered schemes.		registered schemes.
	Schemes that are not intended for use with relative URIs/IRIs SHOULD		Schemes that are not intended for use with relative URIs/IRIs SHOULD
	avoid use of the forward slash "/" character, which is used for		avoid use of the forward slash "/" character, which is used for
	skipping to change at page 7, line 48		skipping to change at page 7, line 48
	bytes, using UTF-8 or UTF-16. The scheme specification SHOULD be as		bytes, using UTF-8 or UTF-16. The scheme specification SHOULD be as
	restrictive as possible regarding what characters are allowed in the		restrictive as possible regarding what characters are allowed in the
	URI/IRI, because some characters can create several different		URI/IRI, because some characters can create several different
	security considerations (see for example [RFC4690]).		security considerations (see for example [RFC4690]).
	3.7. Clear Security Considerations		3.7. Clear Security Considerations
	Definitions of schemes MUST be accompanied by a clear analysis of the		Definitions of schemes MUST be accompanied by a clear analysis of the
	security implications for systems that use the scheme; this follows		security implications for systems that use the scheme; this follows
	the practice of Security Consideration sections within IANA		the practice of Security Consideration sections within IANA
	registrations [RFC2434].		registrations [RFC5226].
	In particular, Section 7 of RFC 3986 [RFC3986] describes general		In particular, Section 7 of RFC 3986 [RFC3986] describes general
	security considerations for URIs, while Section ??? of [RFC3987bis]		security considerations for URIs, while Section ??? of [RFC3987bis]
	gives those for IRIs. The definition of an individual URI/IRI scheme		gives those for IRIs. The definition of an individual URI/IRI scheme
	should note which of these apply to the specified scheme.		should note which of these apply to the specified scheme.
	3.8. Scheme Name Considerations		3.8. Scheme Name Considerations
	Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this		Section 3.1 of RFC 3986 defines the syntax of a URI scheme name; this
	sytax remains the same for IRIs. New registered schemes		sytax remains the same for IRIs. New registered schemes
	skipping to change at page 8, line 37		skipping to change at page 8, line 37
	that allude to their "universal" or "standard" nature.)		that allude to their "universal" or "standard" nature.)
	Organizations that desire a private name space for URI scheme names		Organizations that desire a private name space for URI scheme names
	are encouraged to use a prefix based on their domain name, expressed		are encouraged to use a prefix based on their domain name, expressed
	in reverse order. For example, a URI scheme name of com-example-info		in reverse order. For example, a URI scheme name of com-example-info
	might be registered by the vendor that owns the example.com domain		might be registered by the vendor that owns the example.com domain
	name.		name.
	4. Guidelines for Provisional URI/IRI Scheme Registration		4. Guidelines for Provisional URI/IRI Scheme Registration
			Provisional registration can be an intermediate step on the way to
			permanent registration, e.g., before the scheme specification is
			finalized. Provisional registration is also appropriate for schemes
			that are known to be used, but where a definitive specification is
			not available. There is no time limit for provisional registration.
	While the guidelines in Section 3 are REQUIRED for permanent		While the guidelines in Section 3 are REQUIRED for permanent
	registration, they are RECOMMENDED for provisional registration. For		registration, they are RECOMMENDED for provisional registration. For
	a provisional registration, the following are REQUIRED:		a provisional registration, the following are REQUIRED:
	o The scheme name meets the syntactic requirements of Section 3.8.		o The scheme name meets the syntactic requirements of Section 3.8.
	o There is not already an entry with the same scheme name. (In the		o There is not already an entry with the same scheme name. (In the
	unfortunate case that there are multiple, different uses of the		unfortunate case that there are multiple, different uses of the
	same scheme name, the IESG may approve a request to modify an		same scheme name, the IESG may approve a request to modify an
	existing entry to note the separate use.)		existing entry to note the separate use.)
	o Contact information identifying the person supplying the		o Contact information identifying the person supplying the
	skipping to change at page 9, line 4		skipping to change at page 9, line 10
	o The scheme name meets the syntactic requirements of Section 3.8.		o The scheme name meets the syntactic requirements of Section 3.8.
	o There is not already an entry with the same scheme name. (In the		o There is not already an entry with the same scheme name. (In the
	unfortunate case that there are multiple, different uses of the		unfortunate case that there are multiple, different uses of the
	same scheme name, the IESG may approve a request to modify an		same scheme name, the IESG may approve a request to modify an
	existing entry to note the separate use.)		existing entry to note the separate use.)
	o Contact information identifying the person supplying the		o Contact information identifying the person supplying the
	registration is included. Previously unregistered schemes		registration is included. Previously unregistered schemes
	discovered in use may be registered by third parties (even if not		discovered in use may be registered by third parties (even if not
	on behalf of those who created the scheme). In this case, both		on behalf of those who created the scheme). In this case, both
	the registering party and the scheme creator SHOULD be identified.		the registering party and the scheme creator SHOULD be identified.
	o If no permanent, citable specification for the scheme definition		o If no permanent, citable specification for the scheme definition
	is included, credible reasons for not providing it should be		is included, credible reasons for not providing it should be
	given.		given.
	o A valid Security Considerations section, as required by Section 6		o A valid Security Considerations section, as required by Section 6
	of [RFC2434].		of [RFC5226].
	o If the scheme definition does not meet the guidelines laid out in		o If the scheme definition does not meet the guidelines laid out in
	Section 3, the differences and reasons SHOULD be noted.		Section 3, the differences and reasons SHOULD be noted.
	5. Guidelines for Historical URI/IRI Scheme Registration		5. Guidelines for Historical URI/IRI Scheme Registration
	In some circumstances, it is appropriate to note a URI scheme that		In some circumstances, it is appropriate to note a URI scheme that
	was once in use or registered but for whatever reason is no longer in		was once in use or registered but for whatever reason is no longer in
	common use or the use is not recommended. In this case, it is		common use or the use is not recommended. In this case, it is
	possible for an individual to request that the scheme be registered		possible for an individual to request that the scheme be registered
	(newly, or as an update to an existing registration) as 'historical'.		(newly, or as an update to an existing registration) as 'historical'.
	Any scheme that is no longer in common use MAY be designated as		Any scheme that is no longer in common use MAY be designated as
	historical; the registration should contain some indication to where		historical; the registration should contain some indication to where
	the scheme was previously defined or documented.		the scheme was previously defined or documented.
	6. URI/IRI Scheme Registration Procedure		6. URI/IRI Scheme Registration Procedure
	6.1. General		6.1. General
	The URI/IRI registration process is described in the terminology of		The URI/IRI registration process is described in the terminology of
	[RFC2434]. The registration process is an optional mailing list		[RFC5226]. The registration process is an optional mailing list
	review, followed by "Expert Review". The registration request should		review, followed by "Expert Review". The registration request should
	note the desired status. The Designated Expert will evaluate the		note the desired status. The Designated Expert will evaluate the
	request against the criteria of the requested status. In the case of		request against the criteria of the requested status. In the case of
	a permanent registration request, the Designated Expert may:		a permanent registration request, the Designated Expert may:
	o Accept the specification of the scheme for permanent registration.		o Accept the specification of the scheme for permanent registration.
	o Suggest provisional registration instead.		o Suggest provisional registration instead.
	o Request IETF review and IESG approval; in the meanwhile, suggest		o Request IETF review and IESG approval; in the meanwhile, suggest
	provisional registration.		provisional registration.
	URI/IRI scheme definitions contained within other IETF documents		URI/IRI scheme definitions contained within other IETF documents
	(Informational, Experimental, or Standards-Track RFCs) must also		(Informational, Experimental, or Standards-Track RFCs) must also
	undergo Expert Review; in the case of Standards-Track documents,		undergo Expert Review; in the case of Standards-Track documents,
	permanent registration status approval is required.		permanent registration status approval is required.
			The registration procedure for URI schemes is intended to be very
			lightweight for non-contentious registrations. For the most part, we
			expect the good sense of submitters and reviewers, guided by these
			procedures, to achieve an acceptable and useful consensus for the
			community.
			In exceptional cases, where the negotiating parties cannot form a
			consensus, the final arbiter of any contested registration shall be
			the IESG.
			If parties achieve consensus on a registration proposal that does not
			fully conform to the strict wording of this procedure, this should be
			drawn to the attention of a relevant member of the IESG.
	6.2. Registration Procedures		6.2. Registration Procedures
	Someone wishing to register a new URI/IRI scheme SHOULD:		Someone wishing to register a new URI/IRI scheme SHOULD:
	1. Check the IANA URI scheme registry to see whether or not there is		1. Check the IANA URI scheme registry to see whether or not there is
	already an entry for the desired name. If there is already an		already an entry for the desired name. If there is already an
	entry under the name, choose a different URI scheme name, or		entry under the name, choose a different URI scheme name, or
	update the existing scheme definition.		update the existing scheme definition.
	2. Prepare a URI/IRI scheme registration template, as specified in		2. Prepare a URI/IRI scheme registration template, as specified in
	Section 6.4. The scheme registration template may be contained		Section 6.4. The scheme registration template may be contained
	skipping to change at page 12, line 49		skipping to change at page 13, line 24
	Security considerations None.		Security considerations None.
	Contact N/A		Contact N/A
	Author/Change controller IETF		Author/Change controller IETF
	References This RFC XXXX.		References This RFC XXXX.
	RFC Editor Note: Replace XXXX with this RFC's reference.		RFC Editor Note: Replace XXXX with this RFC's reference.
	8. IANA Considerations		8. IANA Considerations
	Previously, the former "URL Scheme" registry was replaced by the		Previously, the former "URL Scheme" registry was replaced by the
	Uniform Resource Identifier scheme registry. The process was based		Uniform Resource Identifier scheme registry. The process was based
	on [RFC2434] "Expert Review" with an initial (optional) mailing list		on [RFC5226] "Expert Review" with an initial (optional) mailing list
	review.		review.
	The updated template has an additional field for the status of the		The updated template has an additional field for the status of the
	scheme, and the procedures for entering new name schemes have been		scheme, and the procedures for entering new name schemes have been
	augmented. Section 6 establishes the process for new URI/IRI scheme		augmented. Section 6 establishes the process for new URI/IRI scheme
	registration.		registration.
	The example URI scheme "example" is hereby registered. (See the		The example URI scheme "example" is hereby registered. (See the
	template above for registration.)		template above for registration.)
	skipping to change at page 14, line 23		skipping to change at page 14, line 35
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.		[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	October 1998.		May 2008.
	[RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,		[RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,
	March 2005.		March 2005.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
	Identifiers (IRIs)", RFC 3987, January 2005.
	[RFC3987bis]		[RFC3987bis]
	Duerst, M., Masinter, L., and M. Suignard,		Duerst, M., Masinter, L., and M. Suignard,
	"Internationalized Resource Identifiers (IRIs)",		"Internationalized Resource Identifiers (IRIs)",
	September 2010,		September 2010,
	<http://tools.ietf.org/id/draft-ietf-iri-3987bis>.		<http://tools.ietf.org/id/draft-ietf-iri-3987bis>.
	11.2. Informative References		11.2. Informative References
	[RFC2717] Petke, R. and I. King, "Registration Procedures for URL		[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
	Scheme Names", BCP 35, RFC 2717, November 1999.		Scheme Names", BCP 35, RFC 2717, November 1999.
	skipping to change at page 15, line 11		skipping to change at page 15, line 21
	"Guidelines for new URL Schemes", RFC 2718, November 1999.		"Guidelines for new URL Schemes", RFC 2718, November 1999.
	[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,		[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
	"Uniform Resource Names (URN) Namespace Definition		"Uniform Resource Names (URN) Namespace Definition
	Mechanisms", BCP 66, RFC 3406, October 2002.		Mechanisms", BCP 66, RFC 3406, October 2002.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
			[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
			Identifiers (IRIs)", RFC 3987, January 2005.
	[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and		[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
	Registration Procedures for New URI Schemes", BCP 35,		Registration Procedures for New URI Schemes", BCP 35,
	RFC 4395, February 2006.		RFC 4395, February 2006.
	[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and		[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
	Recommendations for Internationalized Domain Names		Recommendations for Internationalized Domain Names
	(IDNs)", RFC 4690, September 2006.		(IDNs)", RFC 4690, September 2006.
	[W3CWebArch]		[W3CWebArch]
	W3C Technical Architecture Group, "Architecture of the		W3C Technical Architecture Group, "Architecture of the
	skipping to change at page 15, line 33		skipping to change at page 16, line 4
	Authors' Addresses		Authors' Addresses
	Tony Hansen		Tony Hansen
	AT&T Laboratories		AT&T Laboratories
	200 Laurel Ave.		200 Laurel Ave.
	Middletown, NJ 07748		Middletown, NJ 07748
	USA		USA
	Email: tony+urireg@maillennium.att.com		Email: tony+urireg@maillennium.att.com
	Ted Hardie		Ted Hardie
	Panasonic Wireless Research Lab		Panasonic Wireless Research Lab
	10900 Tantau Ave.		10900 Tantau Ave.
	Cupertino, CA		Cupertino, CA
	USA		USA
	Phone: +1 408 628 5864		Phone: +1 408 628 5864
	Email: ted.ietf@gmail.com		Email: ted.ietf@gmail.com
	Larry Masinter		Larry Masinter
	Adobe Systems		Adobe
	345 Park Ave.		345 Park Ave.
	San Jose, CA 95110		San Jose, CA 95110
	US		US
	Phone: +1 408 536 3024		Phone: +1 408 536 3024
	Email: masinter@adobe.com		Email: masinter@adobe.com
	URI: http://larry.masinter.net		URI: http://larry.masinter.net
End of changes. 22 change blocks.
	27 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/