< draft-saintandre-xdash-02.txt		draft-saintandre-xdash-03.txt >
	Network Working Group P. Saint-Andre		Network Working Group P. Saint-Andre
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: BCP D. Crocker		Intended status: BCP D. Crocker
	Expires: January 12, 2012 Brandenburg InternetWorking		Expires: January 27, 2012 Brandenburg InternetWorking
	M. Nottingham		M. Nottingham
	July 11, 2011		July 26, 2011
	Deprecating Use of the "X-" Prefix in Application Protocols		Deprecating Use of the "X-" Prefix in Application Protocols
	draft-saintandre-xdash-02		draft-saintandre-xdash-03
	Abstract		Abstract
	Many application protocols use named parameters to identify data		Historically, there has often been a perceived distinction between
	(media types, header fields in Internet mail messages and HTTP		"standard" and "non-standard" parameters (such as media types and
	requests, etc.). Historically, protocol designers and implementers		header fields), by prefixing the latter with the string "X-" or
	have often distinguished between "standard" and "non-standard"		similar constructions (e.g., "x.").
	parameters by prefixing the latter with the string "X-" or similar
	constructions (e.g., "x."), where the "X" is commonly understood to		In practice, this convention causes more problems than it solves.
	stand for "eXperimental" or "eXtension". Although in theory the "X-"		Therefore, this document deprecates the "X-" convention for most
	convention was a good way to avoid collisions (and attendant		application protocol parameters.
	interoperability problems) between standard parameters and non-
	standard parameters, in practice the costs associated with the
	advancement of non-standard parameters into the standards space
	outweigh the benefits. Therefore this document deprecates the "X-"
	convention for most application protocols.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 12, 2012.		This Internet-Draft will expire on January 27, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Recommendations for New Parameters . . . . . . . . . . . . . . 3
	4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Recommendations for Application Protocols . . . . . . . . . . 4
	5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 5
	9.2. Informative References . . . . . . . . . . . . . . . . . . 9		Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7
			Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	Many application protocols use named parameters to identify data		Many application protocols use named parameters to identify data
	(media types, header fields in Internet mail messages and HTTP		(media types, header fields in Internet mail messages and HTTP
	requests, etc.). Historically, protocol designers and implementers		requests, etc.). Historically, protocol designers and implementers
	have often distinguished between "standard" and "non-standard"		have often distinguished between "standard" and "non-standard"
	parameters by prefixing the latter with the string "X-" or similar		parameters by prefixing the latter with the string "X-" or similar
	constructions (e.g., "x."), where the "X" is commonly understood to		constructions (e.g., "x."), where the "X" is commonly understood to
	stand for "eXperimental" or "eXtension". Although in theory the "X-"		stand for "eXperimental" or "eXtension".
	convention was a good way to avoid collisions (and attendant
	interoperability problems) between standard parameters and non-		Although in theory the "X-" convention was a good way to avoid
	standard parameters, in practice the costs associated with the		collisions (and attendant interoperability problems) between standard
	advancement of non-standard parameters into the standards space		parameters and non-standard parameters, in practice the costs
	outweigh the benefits. Therefore this document deprecates the "X-"		associated with the advancement of non-standard parameters into the
	convention for most application protocols.		standards space outweigh the benefits. Therefore this document
			deprecates the "X-" convention for most application protocols by
			making specific recommendations.
			See Appendix A for background about the "X-" convention, and
			Appendix B for the reasoning that led to these recommendations.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	3. Background		3. Recommendations for New Parameters
			Creators of new parameters in existing protocols (e.g., HTTP headers,
			Internet media types) -- regardless of who creates them:
			1. SHOULD by default assume that all parameters they create have the
			potential to advance to a standard.
			2. SHOULD utilise meaningful but currently unused names WITHOUT the
			"X-" prefix, when there is a potential for it to becomes widely
			used and/or standardized (e.g., because an extension is public or
			awaiting wider validation) .
			3. SHOULD follow conventions specific to the parameter when creating
			parameters for use in implementation-specific applications or on
			private networks. Depending on the parameter, this could be a
			URI (e.g., "http://example.com/foo"), a name that incorporates
			the relevant organization's name (e.g., "ExampleInc-foo" or
			"VND.ExampleInc.foo") or primary domain name (e.g.,
			"com.example.foo").
			4. SHOULD generate meaningless names for parameters that will not
			become standardized (e.g., because the extension is completely
			private or purely speculative). For example, the output of a
			hash function (e.g., "esuDj6Ssil8kDn4yfvvdwMTRhlU"), a UUID
			(e.g., "1AB9C36F-1618-4C1F-855D-96B5BAFC7FB3"), or even a
			nonsense word (e.g., "foobarbazqux") .
			4. Recommendations for Application Protocols
			Authors of application protocols that allow extension using
			parameters:
			1. SHOULD provide unlimited registries with well-defined
			registration procedures and SHOULD mandate registration of all
			non-private parameters, independent of the form of the parameter
			names.
			2. MUST NOT assume that any parameter with the "X-" prefix is non-
			standard and that any parameter without the "X-" prefix is
			standard.
			3. SHOULD identify a convention (and reserve delimiters as
			necessary) to allow local or implementation-specific extensions;
			e.g. the "vnd." scheme in [RFC4288].
			4. SHOULD NOT bar parameters with the "X-" prefix from being
			registered with IANA, as all existing parameters with the "X-"
			prefix need to be registered with IANA.
			5. Security Considerations
			Interoperability and migration issues with security-critical
			parameters can result in unnecessary vulnerabilities.
			6. IANA Considerations
			[TODO: describe changes to existing procedures to IANA; update RFCs?]
			7. Acknowledgements
			Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric
			Burger, Al Constanzo, Dave Cridland, Martin Duerst, Frank Ellermann,
			J.D. Falk, Tony Finch, Tony Hansen, Ted Hardie, Joe Hildebrand,
			Alfred Hoenes, Paul Hoffman, Eric Johnson, John Klensin, Graham
			Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan,
			Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-
			Jenkins, Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer,
			Andrew Sullivan, Martin Thomson, Nicolas Williams, Tim Williams, and
			Kurt Zeilenga for their feedback.
			8. References
			8.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			8.2. Informative References
			[BCP9] Bradner, S., "The Internet Standards Process -- Revision
			3", BCP 9, RFC 2026, October 1996.
			[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
			[BCP82] Narten, T., "Assigning Experimental and Testing Numbers
			Considered Useful", BCP 82, RFC 3692, January 2004.
			[RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.
			[RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737,
			October 1977.
			[RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743,
			December 1977.
			[RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory
			oriented FTP commands", RFC 775, December 1980.
			[RFC822] Crocker, D., "Standard for the format of ARPA Internet
			text messages", STD 11, RFC 822, August 1982.
			[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
			and Support", STD 3, RFC 1123, October 1989.
			[RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for
			internet messages", RFC 1154, April 1990.
			[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
			Extensions (MIME) Part One: Format of Internet Message
			Bodies", RFC 2045, November 1996.
			[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
			Extensions (MIME) Part Two: Media Types", RFC 2046,
			November 1996.
			[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
			Part Three: Message Header Extensions for Non-ASCII Text",
			RFC 2047, November 1996.
			[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
			Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
			RFC 2068, January 1997.
			[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
			RFC 2426, September 1998.
			[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
			Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
			Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
			[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
			April 2001.
			[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
			of New DHCP Options and Message Types", BCP 43, RFC 2939,
			September 2000.
			[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
			"Uniform Resource Names (URN) Namespace Definition
			Mechanisms", BCP 66, RFC 3406, October 2002.
			[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
			and B. Rosen, "Change Process for the Session Initiation
			Protocol (SIP)", RFC 3427, December 2002.
			[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			September 2004.
			[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
			Resource Identifier (URI): Generic Syntax", STD 66,
			RFC 3986, January 2005.
			[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
			Unique IDentifier (UUID) URN Namespace", RFC 4122,
			July 2005.
			[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
			Registration Procedures", BCP 13, RFC 4288, December 2005.
			[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
			(LDAP): Directory Information Models", RFC 4512,
			June 2006.
			[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
			Description Protocol", RFC 4566, July 2006.
			[RFC5064] Duerst, M., "The Archived-At Message Header Field",
			RFC 5064, December 2007.
			[RFC5451] Kucherawy, M., "Message Header Field for Indicating
			Message Authentication Status", RFC 5451, April 2009.
			[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
			Languages", BCP 47, RFC 5646, September 2009.
			[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
			for the Session Initiation Protocol (SIP) and the Real-
			time Applications and Infrastructure Area", BCP 67,
			RFC 5727, March 2010.
			Appendix A. Background
	The beginnings of the "X-" convention can be found in a suggestion		The beginnings of the "X-" convention can be found in a suggestion
	made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]:		made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]:
	Thus, FTP servers which care about the distinction between Telnet		Thus, FTP servers which care about the distinction between Telnet
	print and non-print could implement SRVR N and SRVR T. Ideally the		print and non-print could implement SRVR N and SRVR T. Ideally the
	SRVR parameters should be registered with Jon Postel to avoid		SRVR parameters should be registered with Jon Postel to avoid
	conflicts, although it is not a disaster if two sites use the same		conflicts, although it is not a disaster if two sites use the same
	parameter for different things. I suggest that parameters be		parameter for different things. I suggest that parameters be
	allowed to be more than one letter, and that an initial letter X		allowed to be more than one letter, and that an initial letter X
	skipping to change at page 5, line 5 ¶		skipping to change at page 9, line 7 ¶
	they are intended only for use in implementation-specific		they are intended only for use in implementation-specific
	applications or on private networks.		applications or on private networks.
	Use of this naming convention is not mandated by the Internet		Use of this naming convention is not mandated by the Internet
	Standards Process [BCP9] or IANA registration rules [BCP26]. Rather		Standards Process [BCP9] or IANA registration rules [BCP26]. Rather
	it is an individual choice by each specification that references the		it is an individual choice by each specification that references the
	convention or each administrative process that chooses to use it. In		convention or each administrative process that chooses to use it. In
	particular, some standards track RFCs have interpreted the convention		particular, some standards track RFCs have interpreted the convention
	in a normative way (e.g., [RFC822] and [RFC5451]).		in a normative way (e.g., [RFC822] and [RFC5451]).
	4. Analysis		Appendix B. Analysis
	The primary problem with the "X-" convention is that non-standard		The primary problem with the "X-" convention is that non-standard
	parameters have a tendency to advance into the protected space of		parameters have a tendency to advance into the protected space of
	standard parameters (whether de jure or de facto), thus introducing		standard parameters (whether de jure or de facto), thus introducing
	the need for migration from the "X-" name to the standard name.		the need for migration from the "X-" name to the standard name.
	Migration, in turn, introduces interoperability issues because older		Migration, in turn, introduces interoperability issues because older
	implementations will support only the "X-" name and newer		implementations will support only the "X-" name and newer
	implementations might support only the standard name. To preserve		implementations might support only the standard name. To preserve
	interoperability, newer implementations simply support the "X-" name		interoperability, newer implementations simply support the "X-" name
	forever, which means that the non-standard name has become a de facto		forever, which means that the non-standard name has become a de facto
	skipping to change at page 5, line 35 ¶		skipping to change at page 9, line 37 ¶
	applications should consider "x-gzip" and "x-compress" to be		applications should consider "x-gzip" and "x-compress" to be
	equivalent to "gzip" and "compress" respectively.		equivalent to "gzip" and "compress" respectively.
	A similar example can be found in [RFC5064], which defined the		A similar example can be found in [RFC5064], which defined the
	"Archived-At" message header field but also found it necessary to		"Archived-At" message header field but also found it necessary to
	define and register the "X-Archived-At" field:		define and register the "X-Archived-At" field:
	For backwards compatibility, this document also describes the		For backwards compatibility, this document also describes the
	X-Archived-At header field, a precursor of the Archived-At header		X-Archived-At header field, a precursor of the Archived-At header
	field. The X-Archived-At header field MAY also be parsed, but		field. The X-Archived-At header field MAY also be parsed, but
	SHOULD not be generated.		SHOULD NOT be generated.
	One of the original reasons for segregation of name spaces into		One of the original reasons for segregation of name spaces into
	standard and non-standard areas was the perceived difficulty of		standard and non-standard areas was the perceived difficulty of
	registering names. However, the solution to that problem has been		registering names. However, the solution to that problem has been
	simpler registration rules, such as those provided by [RFC3864] and		simpler registration rules, such as those provided by [RFC3864] and
	[RFC4288], as well as separate registries for permanent and		[RFC4288], as well as separate registries for permanent and
	provisional names, as explained in xref target='RFC4288'/>:		provisional names, as explained in [RFC4288]:
	[W]ith the simplified registration procedures described above for		[W]ith the simplified registration procedures described above for
	vendor and personal trees, it should rarely, if ever, be necessary		vendor and personal trees, it should rarely, if ever, be necessary
	to use unregistered experimental types. Therefore, use of both		to use unregistered experimental types. Therefore, use of both
	"x-" and "x." forms is discouraged.		"x-" and "x." forms is discouraged.
	Furthermore, often standardization of a non-standard parameter or		Furthermore, often standardization of a non-standard parameter or
	protocol element leads to subtly different behavior (e.g., the		protocol element leads to subtly different behavior (e.g., the
	standard version might have different security properties as a result		standard version might have different security properties as a result
	of security review provided during the standardization process). If		of security review provided during the standardization process). If
	skipping to change at page 7, line 29 ¶		skipping to change at page 11, line 30 ¶
	(including email headers, media types, HTTP headers, vCard		(including email headers, media types, HTTP headers, vCard
	parameters and properties, URNs, and LDAP field names), the name		parameters and properties, URNs, and LDAP field names), the name
	space is not limited or constrained in any way, so there is no		space is not limited or constrained in any way, so there is no
	need to assign a block of names for private use or experimental		need to assign a block of names for private use or experimental
	purposes (see also [BCP26]).		purposes (see also [BCP26]).
	Therefore it appears that segregating the parameter space into a		Therefore it appears that segregating the parameter space into a
	standard area and a non-standard area has few if any benefits, and		standard area and a non-standard area has few if any benefits, and
	has at least one significant cost in terms of interoperability.		has at least one significant cost in terms of interoperability.
	5. Recommendations
	Based on the foregoing considerations, this document makes the
	following recommendations:
	1. Specification authors and implementers SHOULD assume that all
	protocol parameters have the potential to advance into the non-
	standard area into the standard area, and proceed as described in
	the remaining recommendations.
	2. Specification authors SHOULD provide unlimited registries with
	well-defined registration procedures and SHOULD mandate
	registration of all non-private parameters, independent of the
	form of the parameter names.
	3. Specification authors and implementers wishing to experiment with
	parameters that have the potential to be standardized (e.g.,
	because the experiment is public or awaiting wider validation)
	SHOULD generate meaningful but currently unused names without the
	"X-" prefix.
	4. Implementers wishing to experiment with parameters that are
	highly unlikely to be standardized (e.g., because the expriment
	is completely private or purely speculative) SHOULD generate
	meaningless names such as the output of a hash function (e.g.,
	"esuDj6Ssil8kDn4yfvvdwMTRhlU"), a UUID (e.g., "1AB9C36F-1618-
	4C1F-855D-96B5BAFC7FB3"), or even a nonsense word (e.g.,
	"foobarbazqux").
	5. Implementers wishing to create parameters for use in
	implementation-specific applications or on private networks
	SHOULD mint URIs (e.g., "http://example.com/foo"), generate names
	that incorporate the relevant organization's name (e.g.,
	"ExampleInc-foo" or "VND.ExampleInc.foo") or primary domain name
	(e.g., "com.example.foo"), or follow the recommendation just
	provided for generating meaningless names.
	6. Application protocol specifications MUST NOT assume that any
	parameter with the "X-" prefix is non-standard and that any
	parameter without the "X-" prefix is standard.
	7. Application protocol specifications SHOULD NOT mandate that no
	parameters with the "X-" prefix can be registered with the IANA
	whereas all parameters with the "X-" prefix need to be registered
	with the IANA.
	6. Security Considerations
	Interoperability and migration issues with security-critical
	parameters can result in unnecessary vulnerabilities.
	7. IANA Considerations
	This document requests no action by the IANA.
	8. Acknowledgements
	Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric
	Burger, Al Constanzo, Dave Cridland, Martin Duerst, Frank Ellermann,
	J.D. Falk, Tony Finch, Tony Hansen, Ted Hardie, Joe Hildebrand,
	Alfred Hoenes, Paul Hoffman, Eric Johnson, John Klensin, Graham
	Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan,
	Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-
	Jenkins, Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer,
	Andrew Sullivan, Martin Thomson, Nicolas Williams, Tim Williams, and
	Kurt Zeilenga for their feedback.
	9. References
	9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	9.2. Informative References
	[BCP9] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, October 1996.
	[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.
	[BCP82] Narten, T., "Assigning Experimental and Testing Numbers
	Considered Useful", BCP 82, RFC 3692, January 2004.
	[RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.
	[RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737,
	October 1977.
	[RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743,
	December 1977.
	[RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory
	oriented FTP commands", RFC 775, December 1980.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.
	[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
	and Support", STD 3, RFC 1123, October 1989.
	[RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for
	internet messages", RFC 1154, April 1990.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	Part Three: Message Header Extensions for Non-ASCII Text",
	RFC 2047, November 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, January 1997.
	[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
	RFC 2426, September 1998.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.
	[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
	of New DHCP Options and Message Types", BCP 43, RFC 2939,
	September 2000.
	[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
	"Uniform Resource Names (URN) Namespace Definition
	Mechanisms", BCP 66, RFC 3406, October 2002.
	[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
	and B. Rosen, "Change Process for the Session Initiation
	Protocol (SIP)", RFC 3427, December 2002.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,
	July 2005.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
	(LDAP): Directory Information Models", RFC 4512,
	June 2006.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.
	[RFC5064] Duerst, M., "The Archived-At Message Header Field",
	RFC 5064, December 2007.
	[RFC5451] Kucherawy, M., "Message Header Field for Indicating
	Message Authentication Status", RFC 5451, April 2009.
	[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
	Languages", BCP 47, RFC 5646, September 2009.
	[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
	for the Session Initiation Protocol (SIP) and the Real-
	time Applications and Infrastructure Area", BCP 67,
	RFC 5727, March 2010.
	Authors' Addresses		Authors' Addresses
	Peter Saint-Andre		Peter Saint-Andre
	Cisco		Cisco
	1899 Wyknoop Street, Suite 600		1899 Wyknoop Street, Suite 600
	Denver, CO 80202		Denver, CO 80202
	USA		USA
	Phone: +1-303-308-3282		Phone: +1-303-308-3282
	Email: psaintan@cisco.com		Email: psaintan@cisco.com
End of changes. 12 change blocks.
	217 lines changed or deleted		221 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/