draft-ietf-httpbis-p3-payload-00.txt		draft-ietf-httpbis-p3-payload-01.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2068, 2616 J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	(if approved) One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Intended status: Standards Track J. Mogul		Expires: July 15, 2008 J. Mogul
	Expires: June 22, 2008 HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	December 20, 2007		Y. Lafon, Ed.
			W3C
			J. Reschke, Ed.
			greenbytes
			January 12, 2008
	HTTP/1.1, part 3: Message Payload and Content Negotiation		HTTP/1.1, part 3: Message Payload and Content Negotiation
	draft-ietf-httpbis-p3-payload-00		draft-ietf-httpbis-p3-payload-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 45		skipping to change at page 1, line 49
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 22, 2008.		This Internet-Draft will expire on July 15, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 3 of the		information initiative since 1990. This document is Part 3 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines
	HTTP message content, metadata, and content negotiation.		HTTP message content, metadata, and content negotiation.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	This version of the HTTP specification contains only minimal
	editorial changes from [RFC2616] (abstract, introductory paragraph,
	and authors' addresses). All other changes are due to partitioning
	the original into seven mostly independent parts. The intent is for
	readers of future drafts to able to use draft 00 as the basis for
	comparison when the WG makes later changes to the specification text.
	This draft will shortly be followed by draft 01 (containing the first
	round of changes that have already been agreed to on the mailing
	list). There is no point in reviewing this draft other than to
	verify that the partitioning has been done correctly. Roy T.
	Fielding, Yves Lafon, and Julian Reschke will be the editors after
	draft 00 is submitted.
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://www3.tools.ietf.org/wg/httpbis/>.		<http://www.tools.ietf.org/wg/httpbis/>.
			This draft incorporates those issue resolutions that were either
			collected in the original RFC2616 errata list
			(<http://purl.org/NET/http-errata>), or which were agreed upon on the
			mailing list between October 2006 and November 2007 (as published in
			"draft-lafon-rfc2616bis-03").
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
			1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 5		2. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Character Sets . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 6		2.1.1. Missing Charset . . . . . . . . . . . . . . . . . . . 6
	2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 6		2.2. Content Codings . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Media Types . . . . . . . . . . . . . . . . . . . . . . . 8
	2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 8		2.3.1. Canonicalization and Text Defaults . . . . . . . . . . 9
	2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9		2.3.2. Multipart Types . . . . . . . . . . . . . . . . . . . 9
	2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 9		2.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 10
	2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10		2.5. Language Tags . . . . . . . . . . . . . . . . . . . . . . 10
	3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		3. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 10		3.1. Entity Header Fields . . . . . . . . . . . . . . . . . . . 11
	3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . . 12
	3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 11		3.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 12		3.2.2. Entity Length . . . . . . . . . . . . . . . . . . . . 12
	4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 12		4. Content Negotiation . . . . . . . . . . . . . . . . . . . . . 13
	4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 12		4.1. Server-driven Negotiation . . . . . . . . . . . . . . . . 13
	4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14		4.2. Agent-driven Negotiation . . . . . . . . . . . . . . . . . 14
	4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 14		4.3. Transparent Negotiation . . . . . . . . . . . . . . . . . 15
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 15		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 15
	5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 17		5.2. Accept-Charset . . . . . . . . . . . . . . . . . . . . . . 18
	5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 17		5.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 18
	5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 19		5.4. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20
	5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 20		5.5. Content-Encoding . . . . . . . . . . . . . . . . . . . . . 21
	5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 21		5.6. Content-Language . . . . . . . . . . . . . . . . . . . . . 22
	5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 22		5.7. Content-Location . . . . . . . . . . . . . . . . . . . . . 22
	5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 22		5.8. Content-MD5 . . . . . . . . . . . . . . . . . . . . . . . 23
	5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24		5.9. Content-Type . . . . . . . . . . . . . . . . . . . . . . . 24
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 24		7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 24		7.1. Privacy Issues Connected to Accept Headers . . . . . . . . 25
	7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 25		7.2. Content-Disposition Issues . . . . . . . . . . . . . . . . 26
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
			9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
			9.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Appendix A. Differences Between HTTP Entities and RFC 2045		Appendix A. Differences Between HTTP Entities and RFC 2045
	Entities . . . . . . . . . . . . . . . . . . . . . . 27		Entities . . . . . . . . . . . . . . . . . . . . . . 29
	A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 28		A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 29
	A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 28		A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 30
	A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 29		A.3. Introduction of Content-Encoding . . . . . . . . . . . . . 30
	A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 29		A.4. No Content-Transfer-Encoding . . . . . . . . . . . . . . . 30
	A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 29		A.5. Introduction of Transfer-Encoding . . . . . . . . . . . . 31
	A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 29		A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 31
	Appendix B. Additional Features . . . . . . . . . . . . . . . . . 30		Appendix B. Additional Features . . . . . . . . . . . . . . . . . 31
	B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 30		B.1. Content-Disposition . . . . . . . . . . . . . . . . . . . 31
	Appendix C. Changes from RFC 2068 . . . . . . . . . . . . . . . . 31		Appendix C. Compatibility with Previous Versions . . . . . . . . 32
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31		C.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33		C.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . . . . 36		Appendix D. Change Log (to be removed by RFC Editor before
			publication) . . . . . . . . . . . . . . . . . . . . 33
			D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
			D.2. Since draft-ietf-httpbis-p3-payload-00 . . . . . . . . . . 33
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
			Intellectual Property and Copyright Statements . . . . . . . . . . 39
	1. Introduction		1. Introduction
	This document will define aspects of HTTP related to the payload of		This document defines HTTP/1.1 message payloads (a.k.a., content),
	messages (message content), including metadata and media types, along		the associated metadata header fields that define how the payload is
	with HTTP content negotiation. Right now it only includes the		intended to be interpreted by a recipient, the request header fields
	extracted relevant sections of RFC 2616 without edit.		that may influence content selection, and the various selection
			algorithms that are collectively referred to as HTTP content
			negotiation.
			This document is currently disorganized in order to minimize the
			changes between drafts and enable reviewers to see the smaller errata
			changes. The next draft will reorganize the sections to better
			reflect the content. In particular, the sections on entities will be
			renamed payload and moved to the first half of the document, while
			the sections on content negotiation and associated request header
			fields will be moved to the second half. The current mess reflects
			how widely dispersed these topics and associated requirements had
			become in [RFC2616].
			1.1. Requirements
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			An implementation is not compliant if it fails to satisfy one or more
			of the MUST or REQUIRED level requirements for the protocols it
			implements. An implementation that satisfies all the MUST or
			REQUIRED level and all the SHOULD level requirements for its
			protocols is said to be "unconditionally compliant"; one that
			satisfies all the MUST level requirements but not all the SHOULD
			level requirements for its protocols is said to be "conditionally
			compliant."
	2. Protocol Parameters		2. Protocol Parameters
	2.1. Character Sets		2.1. Character Sets
	HTTP uses the same definition of the term "character set" as that		HTTP uses the same definition of the term "character set" as that
	described for MIME:		described for MIME:
	The term "character set" is used in this document to refer to a		The term "character set" is used in this document to refer to a
	method used with one or more tables to convert a sequence of octets		method used with one or more tables to convert a sequence of octets
	skipping to change at page 5, line 40		skipping to change at page 6, line 20
	to characters. In particular, use of external profiling information		to characters. In particular, use of external profiling information
	to determine the exact mapping is not permitted.		to determine the exact mapping is not permitted.
	Note: This use of the term "character set" is more commonly		Note: This use of the term "character set" is more commonly
	referred to as a "character encoding." However, since HTTP and		referred to as a "character encoding." However, since HTTP and
	MIME share the same registry, it is important that the terminology		MIME share the same registry, it is important that the terminology
	also be shared.		also be shared.
	HTTP character sets are identified by case-insensitive tokens. The		HTTP character sets are identified by case-insensitive tokens. The
	complete set of tokens is defined by the IANA Character Set registry		complete set of tokens is defined by the IANA Character Set registry
	[RFC1700].		(<http://www.iana.org/assignments/character-sets>).
	charset = token		charset = token
	Although HTTP allows an arbitrary token to be used as a charset		Although HTTP allows an arbitrary token to be used as a charset
	value, any token that has a predefined value within the IANA		value, any token that has a predefined value within the IANA
	Character Set registry [RFC1700] MUST represent the character set		Character Set registry MUST represent the character set defined by
	defined by that registry. Applications SHOULD limit their use of		that registry. Applications SHOULD limit their use of character sets
	character sets to those defined by the IANA registry.		to those defined by the IANA registry.
			HTTP uses charset in two contexts: within an Accept-Charset request
			header (in which the charset value is an unquoted token) and as the
			value of a parameter in a Content-Type header (within a request or
			response), in which case the parameter value of the charset parameter
			may be quoted.
	Implementors should be aware of IETF character set requirements		Implementors should be aware of IETF character set requirements
	[RFC2279] [RFC2277].		[RFC3629] [RFC2277].
	2.1.1. Missing Charset		2.1.1. Missing Charset
	Some HTTP/1.0 software has interpreted a Content-Type header without		Some HTTP/1.0 software has interpreted a Content-Type header without
	charset parameter incorrectly to mean "recipient should guess."		charset parameter incorrectly to mean "recipient should guess."
	Senders wishing to defeat this behavior MAY include a charset		Senders wishing to defeat this behavior MAY include a charset
	parameter even when the charset is ISO-8859-1 and SHOULD do so when		parameter even when the charset is ISO-8859-1 ([ISO-8859-1]) and
	it is known that it will not confuse the recipient.		SHOULD do so when it is known that it will not confuse the recipient.
	Unfortunately, some older HTTP/1.0 clients did not deal properly with		Unfortunately, some older HTTP/1.0 clients did not deal properly with
	an explicit charset parameter. HTTP/1.1 recipients MUST respect the		an explicit charset parameter. HTTP/1.1 recipients MUST respect the
	charset label provided by the sender; and those user agents that have		charset label provided by the sender; and those user agents that have
	a provision to "guess" a charset MUST use the charset from the		a provision to "guess" a charset MUST use the charset from the
	content-type field if they support that charset, rather than the		content-type field if they support that charset, rather than the
	recipient's preference, when initially displaying a document. See		recipient's preference, when initially displaying a document. See
	Section 2.3.1.		Section 2.3.1.
	2.2. Content Codings		2.2. Content Codings
	skipping to change at page 6, line 46		skipping to change at page 7, line 31
	indicates what decoding mechanism will be required to remove the		indicates what decoding mechanism will be required to remove the
	encoding.		encoding.
	The Internet Assigned Numbers Authority (IANA) acts as a registry for		The Internet Assigned Numbers Authority (IANA) acts as a registry for
	content-coding value tokens. Initially, the registry contains the		content-coding value tokens. Initially, the registry contains the
	following tokens:		following tokens:
	gzip		gzip
	An encoding format produced by the file compression program "gzip"		An encoding format produced by the file compression program "gzip"
	(GNU zip) as described in RFC 1952 [RFC1952]. This format is a		(GNU zip) as described in [RFC1952]. This format is a Lempel-Ziv
	Lempel-Ziv coding (LZ77) with a 32 bit CRC.		coding (LZ77) with a 32 bit CRC.
	compress		compress
	The encoding format produced by the common UNIX file compression		The encoding format produced by the common UNIX file compression
	program "compress". This format is an adaptive Lempel-Ziv-Welch		program "compress". This format is an adaptive Lempel-Ziv-Welch
	coding (LZW).		coding (LZW).
	Use of program names for the identification of encoding formats is		Use of program names for the identification of encoding formats is
	not desirable and is discouraged for future encodings. Their use		not desirable and is discouraged for future encodings. Their use
	here is representative of historical practice, not good design.		here is representative of historical practice, not good design.
	For compatibility with previous implementations of HTTP,		For compatibility with previous implementations of HTTP,
	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.
	deflate		deflate
	The "zlib" format defined in RFC 1950 [RFC1950] in combination		The "zlib" format defined in [RFC1950] in combination with the
	with the "deflate" compression mechanism described in RFC 1951		"deflate" compression mechanism described in [RFC1951].
	[RFC1951].
	identity		identity
	The default (identity) encoding; the use of no transformation		The default (identity) encoding; the use of no transformation
	whatsoever. This content-coding is used only in the Accept-		whatsoever. This content-coding is used only in the Accept-
	Encoding header, and SHOULD NOT be used in the Content-Encoding		Encoding header, and SHOULD NOT be used in the Content-Encoding
	header.		header.
	New content-coding value tokens SHOULD be registered; to allow		New content-coding value tokens SHOULD be registered; to allow
	interoperability between clients and servers, specifications of the		interoperability between clients and servers, specifications of the
	content coding algorithms needed to implement a new value SHOULD be		content coding algorithms needed to implement a new value SHOULD be
	publicly available and adequate for independent implementation, and		publicly available and adequate for independent implementation, and
	conform to the purpose of content coding defined in this section.		conform to the purpose of content coding defined in this section.
	2.3. Media Types		2.3. Media Types
	HTTP uses Internet Media Types [RFC1590] in the Content-Type		HTTP uses Internet Media Types [RFC2046] in the Content-Type
	(Section 5.9) and Accept (Section 5.1) header fields in order to		(Section 5.9) and Accept (Section 5.1) header fields in order to
	provide open and extensible data typing and type negotiation.		provide open and extensible data typing and type negotiation.
	media-type = type "/" subtype *( ";" parameter )		media-type = type "/" subtype *( ";" parameter )
	type = token		type = token
	subtype = token		subtype = token
	Parameters MAY follow the type/subtype in the form of attribute/value		Parameters MAY follow the type/subtype in the form of attribute/value
	pairs.		pairs.
	skipping to change at page 8, line 15		skipping to change at page 8, line 49
	attribute and its value. The presence or absence of a parameter		attribute and its value. The presence or absence of a parameter
	might be significant to the processing of a media-type, depending on		might be significant to the processing of a media-type, depending on
	its definition within the media type registry.		its definition within the media type registry.
	Note that some older HTTP applications do not recognize media type		Note that some older HTTP applications do not recognize media type
	parameters. When sending data to older HTTP applications,		parameters. When sending data to older HTTP applications,
	implementations SHOULD only use media type parameters when they are		implementations SHOULD only use media type parameters when they are
	required by that type/subtype definition.		required by that type/subtype definition.
	Media-type values are registered with the Internet Assigned Number		Media-type values are registered with the Internet Assigned Number
	Authority (IANA [RFC1700]). The media type registration process is		Authority (IANA). The media type registration process is outlined in
	outlined in RFC 1590 [RFC1590]. Use of non-registered media types is		[RFC4288]. Use of non-registered media types is discouraged.
	discouraged.
	2.3.1. Canonicalization and Text Defaults		2.3.1. Canonicalization and Text Defaults
	Internet media types are registered with a canonical form. An		Internet media types are registered with a canonical form. An
	entity-body transferred via HTTP messages MUST be represented in the		entity-body transferred via HTTP messages MUST be represented in the
	appropriate canonical form prior to its transmission except for		appropriate canonical form prior to its transmission except for
	"text" types, as defined in the next paragraph.		"text" types, as defined in the next paragraph.
	When in canonical form, media subtypes of the "text" type use CRLF as		When in canonical form, media subtypes of the "text" type use CRLF as
	the text line break. HTTP relaxes this requirement and allows the		the text line break. HTTP relaxes this requirement and allows the
	skipping to change at page 9, line 9		skipping to change at page 9, line 42
	parameter is provided by the sender, media subtypes of the "text"		parameter is provided by the sender, media subtypes of the "text"
	type are defined to have a default charset value of "ISO-8859-1" when		type are defined to have a default charset value of "ISO-8859-1" when
	received via HTTP. Data in character sets other than "ISO-8859-1" or		received via HTTP. Data in character sets other than "ISO-8859-1" or
	its subsets MUST be labeled with an appropriate charset value. See		its subsets MUST be labeled with an appropriate charset value. See
	Section 2.1.1 for compatibility problems.		Section 2.1.1 for compatibility problems.
	2.3.2. Multipart Types		2.3.2. Multipart Types
	MIME provides for a number of "multipart" types -- encapsulations of		MIME provides for a number of "multipart" types -- encapsulations of
	one or more entities within a single message-body. All multipart		one or more entities within a single message-body. All multipart
	types share a common syntax, as defined in section 5.1.1 of RFC 2046		types share a common syntax, as defined in Section 5.1.1 of
	[RFC2046], and MUST include a boundary parameter as part of the media		[RFC2046], and MUST include a boundary parameter as part of the media
	type value. The message body is itself a protocol element and MUST		type value. The message body is itself a protocol element and MUST
	therefore use only CRLF to represent line breaks between body-parts.		therefore use only CRLF to represent line breaks between body-parts.
	Unlike in RFC 2046, the epilogue of any multipart message MUST be		Unlike in RFC 2046, the epilogue of any multipart message MUST be
	empty; HTTP applications MUST NOT transmit the epilogue (even if the		empty; HTTP applications MUST NOT transmit the epilogue (even if the
	original multipart contains an epilogue). These restrictions exist		original multipart contains an epilogue). These restrictions exist
	in order to preserve the self-delimiting nature of a multipart		in order to preserve the self-delimiting nature of a multipart
	message-body, wherein the "end" of the message-body is indicated by		message-body, wherein the "end" of the message-body is indicated by
	the ending multipart boundary.		the ending multipart boundary.
	skipping to change at page 9, line 36		skipping to change at page 10, line 21
	within each body-part of a multipart message-body do not have any		within each body-part of a multipart message-body do not have any
	significance to HTTP beyond that defined by their MIME semantics.		significance to HTTP beyond that defined by their MIME semantics.
	In general, an HTTP user agent SHOULD follow the same or similar		In general, an HTTP user agent SHOULD follow the same or similar
	behavior as a MIME user agent would upon receipt of a multipart type.		behavior as a MIME user agent would upon receipt of a multipart type.
	If an application receives an unrecognized multipart subtype, the		If an application receives an unrecognized multipart subtype, the
	application MUST treat it as being equivalent to "multipart/mixed".		application MUST treat it as being equivalent to "multipart/mixed".
	Note: The "multipart/form-data" type has been specifically defined		Note: The "multipart/form-data" type has been specifically defined
	for carrying form data suitable for processing via the POST		for carrying form data suitable for processing via the POST
	request method, as described in RFC 1867 [RFC1867].		request method, as described in [RFC2388].
	2.4. Quality Values		2.4. Quality Values
	HTTP content negotiation (Section 4) uses short "floating point"		HTTP content negotiation (Section 4) uses short "floating point"
	numbers to indicate the relative importance ("weight") of various		numbers to indicate the relative importance ("weight") of various
	negotiable parameters. A weight is normalized to a real number in		negotiable parameters. A weight is normalized to a real number in
	the range 0 through 1, where 0 is the minimum and 1 the maximum		the range 0 through 1, where 0 is the minimum and 1 the maximum
	value. If a parameter has a quality value of 0, then content with		value. If a parameter has a quality value of 0, then content with
	this parameter is `not acceptable' for the client. HTTP/1.1		this parameter is `not acceptable' for the client. HTTP/1.1
	applications MUST NOT generate more than three digits after the		applications MUST NOT generate more than three digits after the
	skipping to change at page 10, line 16		skipping to change at page 10, line 50
	2.5. Language Tags		2.5. Language Tags
	A language tag identifies a natural language spoken, written, or		A language tag identifies a natural language spoken, written, or
	otherwise conveyed by human beings for communication of information		otherwise conveyed by human beings for communication of information
	to other human beings. Computer languages are explicitly excluded.		to other human beings. Computer languages are explicitly excluded.
	HTTP uses language tags within the Accept-Language and Content-		HTTP uses language tags within the Accept-Language and Content-
	Language fields.		Language fields.
	The syntax and registry of HTTP language tags is the same as that		The syntax and registry of HTTP language tags is the same as that
	defined by RFC 1766 [RFC1766]. In summary, a language tag is		defined by [RFC1766]. In summary, a language tag is composed of 1 or
	composed of 1 or more parts: A primary language tag and a possibly		more parts: A primary language tag and a possibly empty series of
	empty series of subtags:		subtags:
	language-tag = primary-tag *( "-" subtag )		language-tag = primary-tag *( "-" subtag )
	primary-tag = 1*8ALPHA		primary-tag = 1*8ALPHA
	subtag = 1*8ALPHA		subtag = 1*8ALPHA
	White space is not allowed within the tag and all tags are case-		White space is not allowed within the tag and all tags are case-
	insensitive. The name space of language tags is administered by the		insensitive. The name space of language tags is administered by the
	IANA. Example tags include:		IANA. Example tags include:
	en, en-US, en-cockney, i-cherokee, x-pig-latin		en, en-US, en-cockney, i-cherokee, x-pig-latin
	skipping to change at page 10, line 49		skipping to change at page 11, line 34
	consists of entity-header fields and an entity-body, although some		consists of entity-header fields and an entity-body, although some
	responses will only include the entity-headers.		responses will only include the entity-headers.
	In this section, both sender and recipient refer to either the client		In this section, both sender and recipient refer to either the client
	or the server, depending on who sends and who receives the entity.		or the server, depending on who sends and who receives the entity.
	3.1. Entity Header Fields		3.1. Entity Header Fields
	Entity-header fields define metainformation about the entity-body or,		Entity-header fields define metainformation about the entity-body or,
	if no body is present, about the resource identified by the request.		if no body is present, about the resource identified by the request.
	Some of this metainformation is OPTIONAL; some might be REQUIRED by
	portions of this specification.
	entity-header = Allow ; [Part2], Section 10.1		entity-header = Allow ; [Part2], Section 10.1
	| Content-Encoding ; Section 5.5		| Content-Encoding ; Section 5.5
	| Content-Language ; Section 5.6		| Content-Language ; Section 5.6
	| Content-Length ; [Part1], Section 8.2		| Content-Length ; [Part1], Section 8.2
	| Content-Location ; Section 5.7		| Content-Location ; Section 5.7
	| Content-MD5 ; Section 5.8		| Content-MD5 ; Section 5.8
	| Content-Range ; [Part5], Section 5.2		| Content-Range ; [Part5], Section 5.2
	| Content-Type ; Section 5.9		| Content-Type ; Section 5.9
	| Expires ; [Part6], Section 3.3		| Expires ; [Part6], Section 15.3
	| Last-Modified ; [Part4], Section 6.6		| Last-Modified ; [Part4], Section 6.6
	| extension-header		| extension-header
	extension-header = message-header		extension-header = message-header
	The extension-header mechanism allows additional entity-header fields		The extension-header mechanism allows additional entity-header fields
	to be defined without changing the protocol, but these fields cannot		to be defined without changing the protocol, but these fields cannot
	be assumed to be recognizable by the recipient. Unrecognized header		be assumed to be recognizable by the recipient. Unrecognized header
	fields SHOULD be ignored by the recipient and MUST be forwarded by		fields SHOULD be ignored by the recipient and MUST be forwarded by
	transparent proxies.		transparent proxies.
	skipping to change at page 13, line 48		skipping to change at page 14, line 34
	HTTP/1.1 includes the following request-header fields for enabling		HTTP/1.1 includes the following request-header fields for enabling
	server-driven negotiation through description of user agent		server-driven negotiation through description of user agent
	capabilities and user preferences: Accept (Section 5.1), Accept-		capabilities and user preferences: Accept (Section 5.1), Accept-
	Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language		Charset (Section 5.2), Accept-Encoding (Section 5.3), Accept-Language
	(Section 5.4), and User-Agent (Section 10.9 of [Part2]). However, an		(Section 5.4), and User-Agent (Section 10.9 of [Part2]). However, an
	origin server is not limited to these dimensions and MAY vary the		origin server is not limited to these dimensions and MAY vary the
	response based on any aspect of the request, including information		response based on any aspect of the request, including information
	outside the request-header fields or within extension header fields		outside the request-header fields or within extension header fields
	not defined by this specification.		not defined by this specification.
	The Vary header field [Part6] can be used to express the parameters		The Vary header field (Section 15.5 of [Part6]) can be used to
	the server uses to select a representation that is subject to server-		express the parameters the server uses to select a representation
	driven negotiation.		that is subject to server-driven negotiation.
	4.2. Agent-driven Negotiation		4.2. Agent-driven Negotiation
	With agent-driven negotiation, selection of the best representation		With agent-driven negotiation, selection of the best representation
	for a response is performed by the user agent after receiving an		for a response is performed by the user agent after receiving an
	initial response from the origin server. Selection is based on a		initial response from the origin server. Selection is based on a
	list of the available representations of the response included within		list of the available representations of the response included within
	the header fields or entity-body of the initial response, with each		the header fields or entity-body of the initial response, with each
	representation identified by its own URI. Selection from among the		representation identified by its own URI. Selection from among the
	representations may be performed automatically (if the user agent is		representations may be performed automatically (if the user agent is
	skipping to change at page 15, line 9		skipping to change at page 15, line 42
	server and also removing the second request delay of agent-driven		server and also removing the second request delay of agent-driven
	negotiation when the cache is able to correctly guess the right		negotiation when the cache is able to correctly guess the right
	response.		response.
	This specification does not define any mechanism for transparent		This specification does not define any mechanism for transparent
	negotiation, though it also does not prevent any such mechanism from		negotiation, though it also does not prevent any such mechanism from
	being developed as an extension that could be used within HTTP/1.1.		being developed as an extension that could be used within HTTP/1.1.
	5. Header Field Definitions		5. Header Field Definitions
	This section defines the syntax and semantics of all standard		This section defines the syntax and semantics of HTTP/1.1 header
	HTTP/1.1 header fields. For entity-header fields, both sender and		fields related to the payload of messages.
	recipient refer to either the client or the server, depending on who
	sends and who receives the entity.		For entity-header fields, both sender and recipient refer to either
			the client or the server, depending on who sends and who receives the
			entity.
	5.1. Accept		5.1. Accept
	The Accept request-header field can be used to specify certain media		The Accept request-header field can be used to specify certain media
	types which are acceptable for the response. Accept headers can be		types which are acceptable for the response. Accept headers can be
	used to indicate that the request is specifically limited to a small		used to indicate that the request is specifically limited to a small
	set of desired types, as in the case of a request for an in-line		set of desired types, as in the case of a request for an in-line
	image.		image.
	Accept = "Accept" ":"		Accept = "Accept" ":"
	skipping to change at page 16, line 18		skipping to change at page 17, line 7
	Accept: audio/*; q=0.2, audio/basic		Accept: audio/*; q=0.2, audio/basic
	SHOULD be interpreted as "I prefer audio/basic, but send me any audio		SHOULD be interpreted as "I prefer audio/basic, but send me any audio
	type if it is the best available after an 80% mark-down in quality."		type if it is the best available after an 80% mark-down in quality."
	If no Accept header field is present, then it is assumed that the		If no Accept header field is present, then it is assumed that the
	client accepts all media types. If an Accept header field is		client accepts all media types. If an Accept header field is
	present, and if the server cannot send a response which is acceptable		present, and if the server cannot send a response which is acceptable
	according to the combined Accept field value, then the server SHOULD		according to the combined Accept field value, then the server SHOULD
	send a 406 (not acceptable) response.		send a 406 (Not Acceptable) response.
	A more elaborate example is		A more elaborate example is
	Accept: text/plain; q=0.5, text/html,		Accept: text/plain; q=0.5, text/html,
	text/x-dvi; q=0.8, text/x-c		text/x-dvi; q=0.8, text/x-c
	Verbally, this would be interpreted as "text/html and text/x-c are		Verbally, this would be interpreted as "text/html and text/x-c are
	the preferred media types, but if they do not exist, then send the		the preferred media types, but if they do not exist, then send the
	text/x-dvi entity, and if that does not exist, send the text/plain		text/x-dvi entity, and if that does not exist, send the text/plain
	entity."		entity."
	skipping to change at page 17, line 46		skipping to change at page 18, line 34
	matches every character set (including ISO-8859-1) which is not		matches every character set (including ISO-8859-1) which is not
	mentioned elsewhere in the Accept-Charset field. If no "*" is		mentioned elsewhere in the Accept-Charset field. If no "*" is
	present in an Accept-Charset field, then all character sets not		present in an Accept-Charset field, then all character sets not
	explicitly mentioned get a quality value of 0, except for ISO-8859-1,		explicitly mentioned get a quality value of 0, except for ISO-8859-1,
	which gets a quality value of 1 if not explicitly mentioned.		which gets a quality value of 1 if not explicitly mentioned.
	If no Accept-Charset header is present, the default is that any		If no Accept-Charset header is present, the default is that any
	character set is acceptable. If an Accept-Charset header is present,		character set is acceptable. If an Accept-Charset header is present,
	and if the server cannot send a response which is acceptable		and if the server cannot send a response which is acceptable
	according to the Accept-Charset header, then the server SHOULD send		according to the Accept-Charset header, then the server SHOULD send
	an error response with the 406 (not acceptable) status code, though		an error response with the 406 (Not Acceptable) status code, though
	the sending of an unacceptable response is also allowed.		the sending of an unacceptable response is also allowed.
	5.3. Accept-Encoding		5.3. Accept-Encoding
	The Accept-Encoding request-header field is similar to Accept, but		The Accept-Encoding request-header field is similar to Accept, but
	restricts the content-codings (Section 2.2) that are acceptable in		restricts the content-codings (Section 2.2) that are acceptable in
	the response.		the response.
	Accept-Encoding = "Accept-Encoding" ":"		Accept-Encoding = "Accept-Encoding" ":"
	1#( codings [ ";" "q" "=" qvalue ] )		#( codings [ ";" "q" "=" qvalue ] )
	codings = ( content-coding | "*" )		codings = ( content-coding | "*" )
	Examples of its use are:		Examples of its use are:
	Accept-Encoding: compress, gzip		Accept-Encoding: compress, gzip
	Accept-Encoding:		Accept-Encoding:
	Accept-Encoding: *		Accept-Encoding: *
	Accept-Encoding: compress;q=0.5, gzip;q=1.0		Accept-Encoding: compress;q=0.5, gzip;q=1.0
	Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0		Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
	skipping to change at page 22, line 37		skipping to change at page 23, line 24
	requested URI; it is only a statement of the location of the resource		requested URI; it is only a statement of the location of the resource
	corresponding to this particular entity at the time of the request.		corresponding to this particular entity at the time of the request.
	Future requests MAY specify the Content-Location URI as the request-		Future requests MAY specify the Content-Location URI as the request-
	URI if the desire is to identify the source of that particular		URI if the desire is to identify the source of that particular
	entity.		entity.
	A cache cannot assume that an entity with a Content-Location		A cache cannot assume that an entity with a Content-Location
	different from the URI used to retrieve it can be used to respond to		different from the URI used to retrieve it can be used to respond to
	later requests on that Content-Location URI. However, the Content-		later requests on that Content-Location URI. However, the Content-
	Location can be used to differentiate between multiple entities		Location can be used to differentiate between multiple entities
	retrieved from a single requested resource, as described in [Part6].		retrieved from a single requested resource, as described in Section 7
			of [Part6].
	If the Content-Location is a relative URI, the relative URI is		If the Content-Location is a relative URI, the relative URI is
	interpreted relative to the Request-URI.		interpreted relative to the Request-URI.
	The meaning of the Content-Location header in PUT or POST requests is		The meaning of the Content-Location header in PUT or POST requests is
	undefined; servers are free to ignore it in those cases.		undefined; servers are free to ignore it in those cases.
	5.8. Content-MD5		5.8. Content-MD5
	The Content-MD5 entity-header field, as defined in RFC 1864		The Content-MD5 entity-header field, as defined in [RFC1864], is an
	[RFC1864], is an MD5 digest of the entity-body for the purpose of		MD5 digest of the entity-body for the purpose of providing an end-to-
	providing an end-to-end message integrity check (MIC) of the entity-		end message integrity check (MIC) of the entity-body. (Note: a MIC
	body. (Note: a MIC is good for detecting accidental modification of		is good for detecting accidental modification of the entity-body in
	the entity-body in transit, but is not proof against malicious		transit, but is not proof against malicious attacks.)
	attacks.)
	Content-MD5 = "Content-MD5" ":" md5-digest		Content-MD5 = "Content-MD5" ":" md5-digest
	md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>		md5-digest = <base64 of 128 bit MD5 digest as per [RFC1864]>
	The Content-MD5 header field MAY be generated by an origin server or		The Content-MD5 header field MAY be generated by an origin server or
	client to function as an integrity check of the entity-body. Only		client to function as an integrity check of the entity-body. Only
	origin servers or clients MAY generate the Content-MD5 header field;		origin servers or clients MAY generate the Content-MD5 header field;
	proxies and gateways MUST NOT generate it, as this would defeat its		proxies and gateways MUST NOT generate it, as this would defeat its
	value as an end-to-end integrity check. Any recipient of the entity-		value as an end-to-end integrity check. Any recipient of the entity-
	body, including gateways and proxies, MAY check that the digest value		body, including gateways and proxies, MAY check that the digest value
	in this header field matches that of the entity-body as received.		in this header field matches that of the entity-body as received.
	The MD5 digest is computed based on the content of the entity-body,		The MD5 digest is computed based on the content of the entity-body,
	skipping to change at page 25, line 27		skipping to change at page 26, line 16
	identifier. In environments where proxies are used to enhance		identifier. In environments where proxies are used to enhance
	privacy, user agents ought to be conservative in offering accept		privacy, user agents ought to be conservative in offering accept
	header configuration options to end users. As an extreme privacy		header configuration options to end users. As an extreme privacy
	measure, proxies could filter the accept headers in relayed requests.		measure, proxies could filter the accept headers in relayed requests.
	General purpose user agents which provide a high degree of header		General purpose user agents which provide a high degree of header
	configurability SHOULD warn users about the loss of privacy which can		configurability SHOULD warn users about the loss of privacy which can
	be involved.		be involved.
	7.2. Content-Disposition Issues		7.2. Content-Disposition Issues
	RFC 1806 [RFC1806], from which the often implemented Content-		[RFC1806], from which the often implemented Content-Disposition (see
	Disposition (see Appendix B.1) header in HTTP is derived, has a		Appendix B.1) header in HTTP is derived, has a number of very serious
	number of very serious security considerations. Content-Disposition		security considerations. Content-Disposition is not part of the HTTP
	is not part of the HTTP standard, but since it is widely implemented,		standard, but since it is widely implemented, we are documenting its
	we are documenting its use and risks for implementors. See RFC 2183		use and risks for implementors. See [RFC2183] (which updates
	[RFC2183] (which updates RFC 1806) for details.		[RFC1806]) for details.
	8. Acknowledgments		8. Acknowledgments
	Based on an XML translation of RFC 2616 by Julian Reschke.
	9. References		9. References
			9.1. Normative References
			[ISO-8859-1]
			International Organization for Standardization,
			"Information technology -- 8-bit single-byte coded graphic
			character sets -- Part 1: Latin alphabet No. 1", ISO/
			IEC 8859-1:1998, 1998.
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 1: URIs, Connections, and Message Parsing",		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	draft-ietf-httpbis-p1-messaging-00 (work in progress),		and Message Parsing", draft-ietf-httpbis-p1-messaging-01
	December 2007.		(work in progress), January 2008.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 2: Message Semantics",		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	draft-ietf-httpbis-p2-semantics-00 (work in progress),		Semantics", draft-ietf-httpbis-p2-semantics-01 (work in
	December 2007.		progress), January 2008.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 4: Conditional Requests",		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	draft-ietf-httpbis-p4-conditional-00 (work in progress),		Requests", draft-ietf-httpbis-p4-conditional-01 (work in
	December 2007.		progress), January 2008.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 5: Range Requests and Partial Responses",		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	draft-ietf-httpbis-p5-range-00 (work in progress),		Partial Responses", draft-ietf-httpbis-p5-range-01 (work
	December 2007.		in progress), January 2008.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	progress), December 2007.		draft-ietf-httpbis-p6-cache-01 (work in progress),
			January 2008.
	[RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590,
	November 1996.
	[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
	RFC 1700, October 1994.
	[RFC1766] Alvestrand, H., "Tags for the Identification of		[RFC1766] Alvestrand, H., "Tags for the Identification of
	Languages", RFC 1766, March 1995.		Languages", RFC 1766, March 1995.
	[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
	Information in Internet Messages: The Content-Disposition
	Header", RFC 1806, June 1995.
	[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",		[RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
	RFC 1864, October 1995.		RFC 1864, October 1995.
	[RFC1867] Masinter, L. and E. Nebel, "Form-based File Upload in
	HTML", RFC 1867, November 1995.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950, May 1996.		Specification version 3.3", RFC 1950, May 1996.
			RFC1950 is an Informational RFC, thus it may be less
			stable than this specification. On the other hand, this
			downward reference was present since [RFC2068] (published
			in 1997), therefore it is unlikely to cause problems in
			practice.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, May 1996.		version 1.3", RFC 1951, May 1996.
			RFC1951 is an Informational RFC, thus it may be less
			stable than this specification. On the other hand, this
			downward reference was present since [RFC2068] (published
			in 1997), therefore it is unlikely to cause problems in
			practice.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.
	Randers-Pehrson, "GZIP file format specification version		Randers-Pehrson, "GZIP file format specification version
	4.3", RFC 1952, May 1996.		4.3", RFC 1952, May 1996.
			RFC1952 is an Informational RFC, thus it may be less
			stable than this specification. On the other hand, this
			downward reference was present since [RFC2068] (published
			in 1997), therefore it is unlikely to cause problems in
			practice.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, November 1996.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
			Registration Procedures", BCP 13, RFC 4288, December 2005.
			9.2. Informative References
			[RFC1806] Troost, R. and S. Dorner, "Communicating Presentation
			Information in Internet Messages: The Content-Disposition
			Header", RFC 1806, June 1995.
			[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
			Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Five: Conformance Criteria and		Extensions (MIME) Part Five: Conformance Criteria and
	Examples", RFC 2049, November 1996.		Examples", RFC 2049, November 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, January 1997.		RFC 2068, January 1997.
	[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,		[RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076,
	February 1997.		February 1997.
	[RFC2110] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
	Aggregate Documents, such as HTML (MHTML)", RFC 2110,
	March 1997.
	[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating		[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
	Presentation Information in Internet Messages: The		Presentation Information in Internet Messages: The
	Content-Disposition Header Field", RFC 2183, August 1997.		Content-Disposition Header Field", RFC 2183, August 1997.
	[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and		[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
	Languages", BCP 18, RFC 2277, January 1998.		Languages", BCP 18, RFC 2277, January 1998.
	[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC2388] Masinter, L., "Returning Values from Forms: multipart/
	10646", RFC 2279, January 1998.		form-data", RFC 2388, August 1998.
			[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
			"MIME Encapsulation of Aggregate Documents, such as HTML
			(MHTML)", RFC 2557, March 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	text messages", STD 11, RFC 822, August 1982.		April 2001.
			[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", RFC 3629, STD 63, November 2003.
	Appendix A. Differences Between HTTP Entities and RFC 2045 Entities		Appendix A. Differences Between HTTP Entities and RFC 2045 Entities
	HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC		HTTP/1.1 uses many of the constructs defined for Internet Mail
	822 [RFC822]) and the Multipurpose Internet Mail Extensions (MIME		([RFC2822]) and the Multipurpose Internet Mail Extensions (MIME
	[RFC2045]) to allow entities to be transmitted in an open variety of		[RFC2045]) to allow entities to be transmitted in an open variety of
	representations and with extensible mechanisms. However, RFC 2045		representations and with extensible mechanisms. However, RFC 2045
	discusses mail, and HTTP has a few features that are different from		discusses mail, and HTTP has a few features that are different from
	those described in RFC 2045. These differences were carefully chosen		those described in RFC 2045. These differences were carefully chosen
	to optimize performance over binary connections, to allow greater		to optimize performance over binary connections, to allow greater
	freedom in the use of new media types, to make date comparisons		freedom in the use of new media types, to make date comparisons
	easier, and to acknowledge the practice of some early HTTP servers		easier, and to acknowledge the practice of some early HTTP servers
	and clients.		and clients.
	This appendix describes specific areas where HTTP differs from RFC		This appendix describes specific areas where HTTP differs from RFC
	skipping to change at page 28, line 23		skipping to change at page 29, line 41
	where necessary. Proxies and gateways from MIME environments to HTTP		where necessary. Proxies and gateways from MIME environments to HTTP
	also need to be aware of the differences because some conversions		also need to be aware of the differences because some conversions
	might be required.		might be required.
	A.1. MIME-Version		A.1. MIME-Version
	HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages		HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages
	MAY include a single MIME-Version general-header field to indicate		MAY include a single MIME-Version general-header field to indicate
	what version of the MIME protocol was used to construct the message.		what version of the MIME protocol was used to construct the message.
	Use of the MIME-Version header field indicates that the message is in		Use of the MIME-Version header field indicates that the message is in
	full compliance with the MIME protocol (as defined in RFC		full compliance with the MIME protocol (as defined in [RFC2045]).
	2045[RFC2045]). Proxies/gateways are responsible for ensuring full		Proxies/gateways are responsible for ensuring full compliance (where
	compliance (where possible) when exporting HTTP messages to strict		possible) when exporting HTTP messages to strict MIME environments.
	MIME environments.
	MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT		MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
	MIME version "1.0" is the default for use in HTTP/1.1. However,		MIME version "1.0" is the default for use in HTTP/1.1. However,
	HTTP/1.1 message parsing and semantics are defined by this document		HTTP/1.1 message parsing and semantics are defined by this document
	and not the MIME specification.		and not the MIME specification.
	A.2. Conversion to Canonical Form		A.2. Conversion to Canonical Form
	RFC 2045 [RFC2045] requires that an Internet mail entity be converted		[RFC2045] requires that an Internet mail entity be converted to
	to canonical form prior to being transferred, as described in section		canonical form prior to being transferred, as described in Section 4
	4 of RFC 2049 [RFC2049]. Section 2.3.1 of this document describes		of [RFC2049]. Section 2.3.1 of this document describes the forms
	the forms allowed for subtypes of the "text" media type when		allowed for subtypes of the "text" media type when transmitted over
	transmitted over HTTP. RFC 2046 requires that content with a type of		HTTP. [RFC2046] requires that content with a type of "text"
	"text" represent line breaks as CRLF and forbids the use of CR or LF		represent line breaks as CRLF and forbids the use of CR or LF outside
	outside of line break sequences. HTTP allows CRLF, bare CR, and bare		of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
	LF to indicate a line break within text content when a message is		indicate a line break within text content when a message is
	transmitted over HTTP.		transmitted over HTTP.
	Where it is possible, a proxy or gateway from HTTP to a strict MIME		Where it is possible, a proxy or gateway from HTTP to a strict MIME
	environment SHOULD translate all line breaks within the text media		environment SHOULD translate all line breaks within the text media
	types described in Section 2.3.1 of this document to the RFC 2049		types described in Section 2.3.1 of this document to the RFC 2049
	canonical form of CRLF. Note, however, that this might be		canonical form of CRLF. Note, however, that this might be
	complicated by the presence of a Content-Encoding and by the fact		complicated by the presence of a Content-Encoding and by the fact
	that HTTP allows the use of some character sets which do not use		that HTTP allows the use of some character sets which do not use
	octets 13 and 10 to represent CR and LF, as is the case for some		octets 13 and 10 to represent CR and LF, as is the case for some
	multi-byte character sets.		multi-byte character sets.
	skipping to change at page 29, line 26		skipping to change at page 30, line 45
	media type, proxies and gateways from HTTP to MIME-compliant		media type, proxies and gateways from HTTP to MIME-compliant
	protocols MUST either change the value of the Content-Type header		protocols MUST either change the value of the Content-Type header
	field or decode the entity-body before forwarding the message. (Some		field or decode the entity-body before forwarding the message. (Some
	experimental applications of Content-Type for Internet mail have used		experimental applications of Content-Type for Internet mail have used
	a media-type parameter of ";conversions=<content-coding>" to perform		a media-type parameter of ";conversions=<content-coding>" to perform
	a function equivalent to Content-Encoding. However, this parameter		a function equivalent to Content-Encoding. However, this parameter
	is not part of RFC 2045).		is not part of RFC 2045).
	A.4. No Content-Transfer-Encoding		A.4. No Content-Transfer-Encoding
	HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC		HTTP does not use the Content-Transfer-Encoding field of RFC 2045.
	2045. Proxies and gateways from MIME-compliant protocols to HTTP		Proxies and gateways from MIME-compliant protocols to HTTP MUST
	MUST remove any non-identity CTE ("quoted-printable" or "base64")		remove any Content-Transfer-Encoding prior to delivering the response
	encoding prior to delivering the response message to an HTTP client.		message to an HTTP client.
	Proxies and gateways from HTTP to MIME-compliant protocols are		Proxies and gateways from HTTP to MIME-compliant protocols are
	responsible for ensuring that the message is in the correct format		responsible for ensuring that the message is in the correct format
	and encoding for safe transport on that protocol, where "safe		and encoding for safe transport on that protocol, where "safe
	transport" is defined by the limitations of the protocol being used.		transport" is defined by the limitations of the protocol being used.
	Such a proxy or gateway SHOULD label the data with an appropriate		Such a proxy or gateway SHOULD label the data with an appropriate
	Content-Transfer-Encoding if doing so will improve the likelihood of		Content-Transfer-Encoding if doing so will improve the likelihood of
	safe transport over the destination protocol.		safe transport over the destination protocol.
	A.5. Introduction of Transfer-Encoding		A.5. Introduction of Transfer-Encoding
	HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7		HTTP/1.1 introduces the Transfer-Encoding header field (Section 8.7
	of [Part1]). Proxies/gateways MUST remove any transfer-coding prior		of [Part1]). Proxies/gateways MUST remove any transfer-coding prior
	to forwarding a message via a MIME-compliant protocol.		to forwarding a message via a MIME-compliant protocol.
	A.6. MHTML and Line Length Limitations		A.6. MHTML and Line Length Limitations
	HTTP implementations which share code with MHTML [RFC2110]		HTTP implementations which share code with MHTML [RFC2557]
	implementations need to be aware of MIME line length limitations.		implementations need to be aware of MIME line length limitations.
	Since HTTP does not have this limitation, HTTP does not fold long		Since HTTP does not have this limitation, HTTP does not fold long
	lines. MHTML messages being transported by HTTP follow all		lines. MHTML messages being transported by HTTP follow all
	conventions of MHTML, including line length limitations and folding,		conventions of MHTML, including line length limitations and folding,
	canonicalization, etc., since HTTP transports all message-bodies as		canonicalization, etc., since HTTP transports all message-bodies as
	payload (see Section 2.3.2) and does not interpret the content or any		payload (see Section 2.3.2) and does not interpret the content or any
	MIME header lines that might be contained therein.		MIME header lines that might be contained therein.
	Appendix B. Additional Features		Appendix B. Additional Features
	RFC 1945 and RFC 2068 document protocol elements used by some		[RFC1945] and [RFC2068] document protocol elements used by some
	existing HTTP implementations, but not consistently and correctly		existing HTTP implementations, but not consistently and correctly
	across most HTTP/1.1 applications. Implementors are advised to be		across most HTTP/1.1 applications. Implementors are advised to be
	aware of these features, but cannot rely upon their presence in, or		aware of these features, but cannot rely upon their presence in, or
	interoperability with, other HTTP/1.1 applications. Some of these		interoperability with, other HTTP/1.1 applications. Some of these
	describe proposed experimental features, and some describe features		describe proposed experimental features, and some describe features
	that experimental deployment found lacking that are now addressed in		that experimental deployment found lacking that are now addressed in
	the base HTTP/1.1 specification.		the base HTTP/1.1 specification.
	A number of other headers, such as Content-Disposition and Title,		A number of other headers, such as Content-Disposition and Title,
	from SMTP and MIME are also often implemented (see RFC 2076		from SMTP and MIME are also often implemented (see [RFC2076]).
	[RFC2076]).
	B.1. Content-Disposition		B.1. Content-Disposition
	The Content-Disposition response-header field has been proposed as a		The Content-Disposition response-header field has been proposed as a
	means for the origin server to suggest a default filename if the user		means for the origin server to suggest a default filename if the user
	requests that the content is saved to a file. This usage is derived		requests that the content is saved to a file. This usage is derived
	from the definition of Content-Disposition in RFC 1806 [RFC1806].		from the definition of Content-Disposition in [RFC1806].
	content-disposition = "Content-Disposition" ":"		content-disposition = "Content-Disposition" ":"
	disposition-type *( ";" disposition-parm )		disposition-type *( ";" disposition-parm )
	disposition-type = "attachment" | disp-extension-token		disposition-type = "attachment" | disp-extension-token
	disposition-parm = filename-parm | disp-extension-parm		disposition-parm = filename-parm | disp-extension-parm
	filename-parm = "filename" "=" quoted-string		filename-parm = "filename" "=" quoted-string
	disp-extension-token = token		disp-extension-token = token
	disp-extension-parm = token "=" ( token | quoted-string )		disp-extension-parm = token "=" ( token | quoted-string )
	An example is		An example is
	skipping to change at page 31, line 7		skipping to change at page 32, line 29
	parameter believed to apply to HTTP implementations at this time.		parameter believed to apply to HTTP implementations at this time.
	The filename SHOULD be treated as a terminal component only.		The filename SHOULD be treated as a terminal component only.
	If this header is used in a response with the application/		If this header is used in a response with the application/
	octet-stream content-type, the implied suggestion is that the user		octet-stream content-type, the implied suggestion is that the user
	agent should not display the response, but directly enter a `save		agent should not display the response, but directly enter a `save
	response as...' dialog.		response as...' dialog.
	See Section 7.2 for Content-Disposition security issues.		See Section 7.2 for Content-Disposition security issues.
	Appendix C. Changes from RFC 2068		Appendix C. Compatibility with Previous Versions
			C.1. Changes from RFC 2068
			Transfer-coding and message lengths all interact in ways that
			required fixing exactly when chunked encoding is used (to allow for
			transfer encoding that may not be self delimiting); it was important
			to straighten out exactly how message lengths are computed.
			(Section 3.2.2, see also [Part1], [Part5] and [Part6]).
	Charset wildcarding is introduced to avoid explosion of character set		Charset wildcarding is introduced to avoid explosion of character set
	names in accept headers. (Section 5.2)		names in accept headers. (Section 5.2)
	Content-Base was deleted from the specification: it was not		Content-Base was deleted from the specification: it was not
	implemented widely, and there is no simple, safe way to introduce it		implemented widely, and there is no simple, safe way to introduce it
	without a robust extension mechanism. In addition, it is used in a		without a robust extension mechanism. In addition, it is used in a
	similar, but not identical fashion in MHTML [RFC2110].		similar, but not identical fashion in MHTML [RFC2557].
	A content-coding of "identity" was introduced, to solve problems		A content-coding of "identity" was introduced, to solve problems
	discovered in caching. (Section 2.2)		discovered in caching. (Section 2.2)
	Quality Values of zero should indicate that "I don't want something"		Quality Values of zero should indicate that "I don't want something"
	to allow clients to refuse a representation. (Section 2.4)		to allow clients to refuse a representation. (Section 2.4)
	The Alternates, Content-Version, Derived-From, Link, URI, Public and		The Alternates, Content-Version, Derived-From, Link, URI, Public and
	Content-Base header fields were defined in previous versions of this		Content-Base header fields were defined in previous versions of this
	specification, but not commonly implemented. See RFC 2068 [RFC2068].		specification, but not commonly implemented. See [RFC2068].
			C.2. Changes from RFC 2616
			Clarify contexts that charset is used in. (Section 2.1)
			Remove reference to non-existant identity transfer-coding value
			tokens. (Appendix A.4)
			Appendix D. Change Log (to be removed by RFC Editor before publication)
			D.1. Since RFC2616
			Extracted relevant partitions from [RFC2616].
			D.2. Since draft-ietf-httpbis-p3-payload-00
			Closed issues:
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
			Registrations" (<http://purl.org/NET/http-errata#media-reg>)
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/14>:
			"Clarification regarding quoting of charset values"
			(<http://purl.org/NET/http-errata#charactersets>)
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
			'identity' token references"
			(<http://purl.org/NET/http-errata#identity>)
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept-
			Encoding BNF"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
			and Informative references"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
			references"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
			"Informative references"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>:
			"ISO-8859-1 Reference"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
			References Normative"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
			up-to-date references"
	Index		Index
	A		A
	Accept header 15		Accept header 16
	Accept-Charset header 17		Accept-Charset header 18
	Accept-Encoding header 17		Accept-Encoding header 18
	Accept-Language header 19		Accept-Language header 20
	Alternates header 31		Alternates header 33
	C		C
	compress 6		compress 7
	Content-Base header 31		Content-Base header 33
	Content-Disposition header 30		Content-Disposition header 31
	Content-Encoding header 20		Content-Encoding header 21
	Content-Language header 21		Content-Language header 22
	Content-Location header 22		Content-Location header 22
	Content-MD5 header 22		Content-MD5 header 23
	Content-Type header 24		Content-Type header 24
	Content-Version header 31		Content-Version header 33
	D		D
	deflate 7		deflate 7
	Derived-From header 31		Derived-From header 33
	G		G
	Grammar		Grammar
	Accept 15		Accept 16
	Accept-Charset 17		Accept-Charset 18
	Accept-Encoding 18		Accept-Encoding 18
	accept-extension 15		accept-extension 16
	Accept-Language 19		Accept-Language 20
	accept-params 15		accept-params 16
	attribute 7		attribute 8
	charset 5		charset 6
	codings 18		codings 18
	content-coding 6		content-coding 7
	content-disposition 30		content-disposition 32
	Content-Encoding 20		Content-Encoding 21
	Content-Language 21		Content-Language 22
	Content-Location 22		Content-Location 23
	Content-MD5 23		Content-MD5 23
	Content-Type 24		Content-Type 24
	disp-extension-parm 30		disp-extension-parm 32
	disp-extension-token 30		disp-extension-token 32
	disposition-parm 30		disposition-parm 32
	disposition-type 30		disposition-type 32
	entity-body 11		entity-body 12
	entity-header 11		entity-header 11
	extension-header 11		extension-header 11
	filename-parm 30		filename-parm 32
	language-range 19		language-range 20
	language-tag 10		language-tag 11
	md5-digest 23		md5-digest 23
	media-range 15		media-range 16
	media-type 7		media-type 8
	MIME-Version 28		MIME-Version 29
	parameter 7		parameter 8
	primary-tag 10		primary-tag 11
	qvalue 9		qvalue 10
	subtag 10		subtag 11
	subtype 7		subtype 8
	type 7		type 8
	value 7		value 8
	gzip 6		gzip 7
	H		H
	Headers		Headers
	Accept 15		Accept 16
	Accept-Charset 17		Accept-Charset 18
	Accept-Encoding 17		Accept-Encoding 18
	Accept-Language 19		Accept-Language 20
	Alternate 31		Alternate 33
	Content-Base 31		Content-Base 33
	Content-Disposition 30		Content-Disposition 31
	Content-Encoding 20		Content-Encoding 21
	Content-Language 21		Content-Language 22
	Content-Location 22		Content-Location 22
	Content-MD5 22		Content-MD5 23
	Content-Type 24		Content-Type 24
	Content-Version 31		Content-Version 33
	Derived-From 31		Derived-From 33
	Link 31		Link 33
	Public 31		Public 33
	URI 31		URI 33
	I		I
	identity 7		identity 8
	L		L
	Link header 31		Link header 33
	P		P
	Public header 31		Public header 33
	U		U
	URI header 31		URI header 33
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
	skipping to change at page 36, line 4		skipping to change at page 38, line 4
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		Email: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
			Yves Lafon (editor)
			World Wide Web Consortium
			W3C / ERCIM
			2004, rte des Lucioles
			Sophia-Antipolis, AM 06902
			France
			Email: ylafon@w3.org
			URI: http://www.raubacapeu.net/people/yves/
			Julian F. Reschke (editor)
			greenbytes GmbH
			Hafenweg 16
			Muenster, NW 48155
			Germany
			Phone: +49 251 2807760
			Fax: +49 251 2807761
			Email: julian.reschke@greenbytes.de
			URI: http://greenbytes.de/tech/webdav/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 89 change blocks.
	245 lines changed or deleted		387 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/