draft-ietf-httpbis-p1-messaging-02.txt		draft-ietf-httpbis-p1-messaging-03.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: August 27, 2008 J. Mogul		Expires: December 19, 2008 J. Mogul
	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
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	February 24, 2008		June 17, 2008
	HTTP/1.1, part 1: URIs, Connections, and Message Parsing		HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	draft-ietf-httpbis-p1-messaging-02		draft-ietf-httpbis-p1-messaging-03
	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 49		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 August 27, 2008.		This Internet-Draft will expire on December 19, 2008.
	Copyright Notice
	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 1 of the		information initiative since 1990. This document is Part 1 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 1 provides		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
	an overview of HTTP and its associated terminology, defines the		an overview of HTTP and its associated terminology, defines the
	skipping to change at page 2, line 30		skipping to change at page 2, line 26
	frames, and describes general security concerns for implementations.		frames, and describes general security concerns for implementations.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	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://www.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://www.tools.ietf.org/wg/httpbis/>.		<http://www.tools.ietf.org/wg/httpbis/>.
	This draft incorporates those issue resolutions that were either		The changes in this draft are summarized in Appendix E.4.
	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. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9		1.4. Overall Operation . . . . . . . . . . . . . . . . . . . . 9
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 11		2. Notational Conventions and Generic Grammar . . . . . . . . . . 11
	2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11		2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . . 11
	skipping to change at page 4, line 16		skipping to change at page 4, line 16
	8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40		8.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 40
	8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		8.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42		8.3.1. Clockless Origin Server Operation . . . . . . . . . . 42
	8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		8.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		8.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44		8.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 44
	8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44		8.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 44
	8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45		8.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 45
	8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		8.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 47		9.1. Message Header Registration . . . . . . . . . . . . . . . 47
			10. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48		10.1. Personal Information . . . . . . . . . . . . . . . . . . . 48
	10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48		10.2. Abuse of Server Log Information . . . . . . . . . . . . . 48
	10.3. Attacks Based On File and Path Names . . . . . . . . . . . 48		10.3. Attacks Based On File and Path Names . . . . . . . . . . . 49
	10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49		10.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 49
	10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 49		10.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 50
	10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50		10.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 50
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 51		12.1. Normative References . . . . . . . . . . . . . . . . . . . 52
	12.2. Informative References . . . . . . . . . . . . . . . . . . 52		12.2. Informative References . . . . . . . . . . . . . . . . . . 53
	Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 54		Appendix A. Internet Media Types . . . . . . . . . . . . . . . . 55
	A.1. Internet Media Type message/http . . . . . . . . . . . . . 54		A.1. Internet Media Type message/http . . . . . . . . . . . . . 55
	A.2. Internet Media Type application/http . . . . . . . . . . . 56		A.2. Internet Media Type application/http . . . . . . . . . . . 56
	Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57		Appendix B. Tolerant Applications . . . . . . . . . . . . . . . . 57
	Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58		Appendix C. Conversion of Date Formats . . . . . . . . . . . . . 58
	Appendix D. Compatibility with Previous Versions . . . . . . . . 58		Appendix D. Compatibility with Previous Versions . . . . . . . . 58
	D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 58		D.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 59
	D.1.1. Changes to Simplify Multi-homed Web Servers and		D.1.1. Changes to Simplify Multi-homed Web Servers and
	Conserve IP Addresses . . . . . . . . . . . . . . . . 59		Conserve IP Addresses . . . . . . . . . . . . . . . . 59
	D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 59		D.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 60
	D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60		D.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 60
	D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 60		D.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 61
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 61		publication) . . . . . . . . . . . . . . . . . . . . 61
	E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61		E.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 61
	E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61		E.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 61
	E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 62		E.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 63
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63		E.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 64
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
	Intellectual Property and Copyright Statements . . . . . . . . . . 70		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
			Intellectual Property and Copyright Statements . . . . . . . . . . 71
	1. Introduction		1. Introduction
	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. The first version of HTTP,		information initiative since 1990. The first version of HTTP,
	commonly referred to as HTTP/0.9, was a simple protocol for raw data		commonly referred to as HTTP/0.9, was a simple protocol for raw data
	transfer across the Internet with only a single method and no		transfer across the Internet with only a single method and no
	metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol		metadata. HTTP/1.0, as defined by [RFC1945], improved the protocol
	skipping to change at page 15, line 46		skipping to change at page 15, line 46
	A string of text is parsed as a single word if it is quoted using		A string of text is parsed as a single word if it is quoted using
	double-quote marks.		double-quote marks.
	quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )		quoted-string = ( DQUOTE *(qdtext | quoted-pair ) DQUOTE )
	qdtext = <any TEXT excluding DQUOTE and "\">		qdtext = <any TEXT excluding DQUOTE and "\">
	The backslash character ("\") MAY be used as a single-character		The backslash character ("\") MAY be used as a single-character
	quoting mechanism only within quoted-string and comment constructs.		quoting mechanism only within quoted-string and comment constructs.
	quoted-pair = "\" CHAR		quoted-text = %x01-09 |
			%x0B-0C |
			%x0E-FF ; Characters excluding NUL, CR and LF
			quoted-pair = "\" quoted-text
	2.3. ABNF Rules defined in other Parts of the Specification		2.3. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	request-header = <request-header, defined in [Part2], Section 4>		request-header = <request-header, defined in [Part2], Section 4>
	response-header = <response-header, defined in [Part2], Section 6>		response-header = <response-header, defined in [Part2], Section 6>
	accept-params = <accept-params, defined in [Part3], Section 6.1>		accept-params = <accept-params, defined in [Part3], Section 6.1>
	entity-body = <entity-body, defined in [Part3], Section 4.2>		entity-body = <entity-body, defined in [Part3], Section 4.2>
	skipping to change at page 16, line 41		skipping to change at page 16, line 41
	The <minor> number is incremented when the changes made to the		The <minor> number is incremented when the changes made to the
	protocol add features which do not change the general message parsing		protocol add features which do not change the general message parsing
	algorithm, but which may add to the message semantics and imply		algorithm, but which may add to the message semantics and imply
	additional capabilities of the sender. The <major> number is		additional capabilities of the sender. The <major> number is
	incremented when the format of a message within the protocol is		incremented when the format of a message within the protocol is
	changed. See [RFC2145] for a fuller explanation.		changed. See [RFC2145] for a fuller explanation.
	The version of an HTTP message is indicated by an HTTP-Version field		The version of an HTTP message is indicated by an HTTP-Version field
	in the first line of the message. HTTP-Version is case-sensitive.		in the first line of the message. HTTP-Version is case-sensitive.
	HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT		HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
			HTTP-Prot-Name = %x48.54.54.50 ; "HTTP", case-sensitive
	Note that the major and minor numbers MUST be treated as separate		Note that the major and minor numbers MUST be treated as separate
	integers and that each MAY be incremented higher than a single digit.		integers and that each MAY be incremented higher than a single digit.
	Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is		Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
	lower than HTTP/12.3. Leading zeros MUST be ignored by recipients		lower than HTTP/12.3. Leading zeros MUST be ignored by recipients
	and MUST NOT be sent.		and MUST NOT be sent.
	An application that sends a request or response message that includes		An application that sends a request or response message that includes
	HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant		HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
	with this specification. Applications that are at least		with this specification. Applications that are at least
	skipping to change at page 20, line 8		skipping to change at page 20, line 10
	All HTTP date/time stamps MUST be represented in Greenwich Mean Time		All HTTP date/time stamps MUST be represented in Greenwich Mean Time
	(GMT), without exception. For the purposes of HTTP, GMT is exactly		(GMT), without exception. For the purposes of HTTP, GMT is exactly
	equal to UTC (Coordinated Universal Time). This is indicated in the		equal to UTC (Coordinated Universal Time). This is indicated in the
	first two formats by the inclusion of "GMT" as the three-letter		first two formats by the inclusion of "GMT" as the three-letter
	abbreviation for time zone, and MUST be assumed when reading the		abbreviation for time zone, and MUST be assumed when reading the
	asctime format. HTTP-date is case sensitive and MUST NOT include		asctime format. HTTP-date is case sensitive and MUST NOT include
	additional LWS beyond that specifically included as SP in the		additional LWS beyond that specifically included as SP in the
	grammar.		grammar.
	HTTP-date = rfc1123-date | rfc850-date | asctime-date		HTTP-date = rfc1123-date | obsolete-date
			obsolete-date = rfc850-date | asctime-date
	rfc1123-date = wkday "," SP date1 SP time SP "GMT"		rfc1123-date = wkday "," SP date1 SP time SP "GMT"
	rfc850-date = weekday "," SP date2 SP time SP "GMT"		rfc850-date = weekday "," SP date2 SP time SP "GMT"
	asctime-date = wkday SP date3 SP time SP 4DIGIT		asctime-date = wkday SP date3 SP time SP 4DIGIT
	date1 = 2DIGIT SP month SP 4DIGIT		date1 = 2DIGIT SP month SP 4DIGIT
	; day month year (e.g., 02 Jun 1982)		; day month year (e.g., 02 Jun 1982)
	date2 = 2DIGIT "-" month "-" 2DIGIT		date2 = 2DIGIT "-" month "-" 2DIGIT
	; day-month-year (e.g., 02-Jun-82)		; day-month-year (e.g., 02-Jun-82)
	date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))		date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
	; month day (e.g., Jun 2)		; month day (e.g., Jun 2)
	time = 2DIGIT ":" 2DIGIT ":" 2DIGIT		time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
	skipping to change at page 46, line 22		skipping to change at page 46, line 22
	version rules of Section 3.1 and future updates to this		version rules of Section 3.1 and future updates to this
	specification. Any token can be used as a protocol name; however, it		specification. Any token can be used as a protocol name; however, it
	will only be useful if both the client and server associate the name		will only be useful if both the client and server associate the name
	with the same protocol.		with the same protocol.
	8.9. Via		8.9. Via
	The Via general-header field MUST be used by gateways and proxies to		The Via general-header field MUST be used by gateways and proxies to
	indicate the intermediate protocols and recipients between the user		indicate the intermediate protocols and recipients between the user
	agent and the server on requests, and between the origin server and		agent and the server on requests, and between the origin server and
	the client on responses. It is analogous to the "Received" field of		the client on responses. It is analogous to the "Received" field
	[RFC2822] and is intended to be used for tracking message forwards,		defined in Section 3.6.7 of [RFC2822] and is intended to be used for
	avoiding request loops, and identifying the protocol capabilities of		tracking message forwards, avoiding request loops, and identifying
	all senders along the request/response chain.		the protocol capabilities of all senders along the request/response
			chain.
	Via = "Via" ":" 1#( received-protocol received-by [ comment ] )		Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
	received-protocol = [ protocol-name "/" ] protocol-version		received-protocol = [ protocol-name "/" ] protocol-version
	protocol-name = token		protocol-name = token
	protocol-version = token		protocol-version = token
	received-by = ( uri-host [ ":" port ] ) | pseudonym		received-by = ( uri-host [ ":" port ] ) | pseudonym
	pseudonym = token		pseudonym = token
	The received-protocol indicates the protocol version of the message		The received-protocol indicates the protocol version of the message
	received by the server or client along each segment of the request/		received by the server or client along each segment of the request/
	skipping to change at page 47, line 45		skipping to change at page 47, line 46
	Via: 1.0 ricky, 1.1 mertz, 1.0 lucy		Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
	Applications SHOULD NOT combine multiple entries unless they are all		Applications SHOULD NOT combine multiple entries unless they are all
	under the same organizational control and the hosts have already been		under the same organizational control and the hosts have already been
	replaced by pseudonyms. Applications MUST NOT combine entries which		replaced by pseudonyms. Applications MUST NOT combine entries which
	have different received-protocol values.		have different received-protocol values.
	9. IANA Considerations		9. IANA Considerations
	[[anchor1: TBD.]]		9.1. Message Header Registration
			The Message Header Registry located at <http://www.iana.org/
			assignments/message-headers/message-header-index.html> should be
			updated with the permanent registrations below (see [RFC3864]):
			+-------------------+----------+----------+-------------+
			| Header Field Name | Protocol | Status | Reference |
			+-------------------+----------+----------+-------------+
			| Connection | http | standard | Section 8.1 |
			| Content-Length | http | standard | Section 8.2 |
			| Date | http | standard | Section 8.3 |
			| Host | http | standard | Section 8.4 |
			| TE | http | standard | Section 8.5 |
			| Trailer | http | standard | Section 8.6 |
			| Transfer-Encoding | http | standard | Section 8.7 |
			| Upgrade | http | standard | Section 8.8 |
			| Via | http | standard | Section 8.9 |
			+-------------------+----------+----------+-------------+
			The change controller is: "IETF (iesg@ietf.org) - Internet
			Engineering Task Force".
	10. Security Considerations		10. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	10.1. Personal Information		10.1. Personal Information
	skipping to change at page 51, line 43		skipping to change at page 52, line 16
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		IEC 8859-1:1998, 1998.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-02 (work in		Semantics", draft-ietf-httpbis-p2-semantics-03 (work in
	progress), February 2008.		progress), June 2008.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-02		and Content Negotiation", draft-ietf-httpbis-p3-payload-03
	(work in progress), February 2008.		(work in progress), June 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., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-02 (work		Partial Responses", draft-ietf-httpbis-p5-range-03 (work
	in progress), February 2008.		in progress), June 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., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-02 (work in progress),		draft-ietf-httpbis-p6-cache-03 (work in progress),
	February 2008.		June 2008.
	[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.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)		[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	Part Three: Message Header Extensions for Non-ASCII Text",		Part Three: Message Header Extensions for Non-ASCII Text",
	RFC 2047, November 1996.		RFC 2047, November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	skipping to change at page 54, line 13		skipping to change at page 54, line 35
	[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.
	[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,		[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
	April 2001.		April 2001.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.		April 2001.
			[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			September 2004.
	[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",		[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
	RFC 3977, October 2006.		RFC 3977, October 2006.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC822] Crocker, D., "Standard for the format of ARPA Internet		[RFC822] Crocker, D., "Standard for the format of ARPA Internet
	text messages", STD 11, RFC 822, August 1982.		text messages", STD 11, RFC 822, August 1982.
	[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",		[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol",
	skipping to change at page 60, line 48		skipping to change at page 61, line 23
	codings), a new header field (TE) and enabling trailer headers in the		codings), a new header field (TE) and enabling trailer headers in the
	future. Transfer encoding is a major performance benefit, so it was		future. Transfer encoding is a major performance benefit, so it was
	worth fixing [Nie1997]. TE also solves another, obscure, downward		worth fixing [Nie1997]. TE also solves another, obscure, downward
	interoperability problem that could have occurred due to interactions		interoperability problem that could have occurred due to interactions
	between authentication trailers, chunked encoding and HTTP/1.0		between authentication trailers, chunked encoding and HTTP/1.0
	clients.(Section 3.4, 3.4.1, and 8.5)		clients.(Section 3.4, 3.4.1, and 8.5)
	D.4. Changes from RFC 2616		D.4. Changes from RFC 2616
	The CHAR rule does not allow the NUL character anymore (this affects		The CHAR rule does not allow the NUL character anymore (this affects
	the comment and quoted-string rules). (Section 2.2)		the comment and quoted-string rules). Furthermore, the quoted-pair
			rule does not allow escaping NUL, CR or LF anymore. (Section 2.2)
	Clarify that HTTP-Version is case sensitive. (Section 3.1)		Clarify that HTTP-Version is case sensitive. (Section 3.1)
	Remove reference to non-existant identity transfer-coding value		Remove reference to non-existant identity transfer-coding value
	tokens. (Sections 3.4 and 4.4)		tokens. (Sections 3.4 and 4.4)
	Clarification that the chunk length does not include the count of the		Clarification that the chunk length does not include the count of the
	octets in the chunk header and trailer. (Section 3.4.1)		octets in the chunk header and trailer. (Section 3.4.1)
	Fix BNF to add query, as the abs_path production in Section 3 of		Fix BNF to add query, as the abs_path production in Section 3 of
	[RFC2396] doesn't define it. (Section 5.1.2)		[RFC2396] doesn't define it. (Section 5.1.2)
	Clarify exactly when close connection options must be sent.		Clarify exactly when close connection options must be sent.
	skipping to change at page 63, line 43		skipping to change at page 64, line 22
	o Move "Product Tokens" section (back) into Part 1, as "token" is		o Move "Product Tokens" section (back) into Part 1, as "token" is
	used in the definition of the Upgrade header.		used in the definition of the Upgrade header.
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule		o Rewrite prose rule "token" in terms of "tchar", rewrite prose rule
	"TEXT".		"TEXT".
			E.4. Since draft-ietf-httpbis-p1-messaging-02
			Closed issues:
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/51>: "HTTP-date
			vs. rfc1123-date"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/64>: "WS in
			quoted-pair"
			Ongoing work on IANA Message Header Registration
			(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):
			o Reference RFC 3984, and update header registrations for headers
			defined in this document.
			Ongoing work on ABNF conversion
			(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Replace string literals when the string really is case-sensitive
			(HTTP-Version).
	Index		Index
	A		A
	application/http Media Type 56		application/http Media Type 56
	C		C
	cache 8		cache 8
	cacheable 9		cacheable 9
	client 7		client 7
	connection 6		connection 6
	skipping to change at page 65, line 11		skipping to change at page 66, line 12
	field-content 25		field-content 25
	field-name 25		field-name 25
	field-value 25		field-value 25
	general-header 28		general-header 28
	generic-message 24		generic-message 24
	HEX 15		HEX 15
	Host 42		Host 42
	HTAB 14		HTAB 14
	HTTP-date 20		HTTP-date 20
	HTTP-message 24		HTTP-message 24
			HTTP-Prot-Name 16
	http-URL 18		http-URL 18
	HTTP-Version 16		HTTP-Version 16
	last-chunk 22		last-chunk 22
	LF 14		LF 14
	LWS 14		LWS 14
	message-body 25		message-body 25
	message-header 25		message-header 25
	Method 29		Method 29
	month 20		month 20
			obsolete-date 20
	OCTET 14		OCTET 14
	parameter 20		parameter 20
	path-absolute 18		path-absolute 18
	port 18		port 18
	product 23		product 23
	product-version 23		product-version 23
	protocol-name 46		protocol-name 46
	protocol-version 46		protocol-version 46
	pseudonym 46		pseudonym 46
	qdtext 15		qdtext 15
	query 18		query 18
	quoted-pair 15		quoted-pair 15
	quoted-string 15		quoted-string 15
			quoted-text 15
	Reason-Phrase 32		Reason-Phrase 32
	received-by 46		received-by 46
	received-protocol 46		received-protocol 46
	relativeURI 18		relativeURI 18
	Request 28		Request 28
	Request-Line 28		Request-Line 28
	Request-URI 29		Request-URI 29
	Response 31		Response 31
	rfc850-date 20		rfc850-date 20
	rfc1123-date 20		rfc1123-date 20
	skipping to change at page 66, line 32		skipping to change at page 67, line 36
	Date 41		Date 41
	Host 42		Host 42
	TE 43		TE 43
	Trailer 44		Trailer 44
	Transfer-Encoding 44		Transfer-Encoding 44
	Upgrade 45		Upgrade 45
	Via 46		Via 46
	Host header 42		Host header 42
	I		I
			implied *LWS 13
	inbound 9		inbound 9
	M		M
	Media Type		Media Type
	application/http 56		application/http 56
	message/http 54		message/http 55
	message 6		message 6
	message/http Media Type 54		message/http Media Type 55
	O		O
	origin server 8		origin server 8
	outbound 9		outbound 9
	P		P
	proxy 8		proxy 8
	R		R
	representation 7		representation 7
	request 6		request 6
	resource 7		resource 7
	response 6		response 6
	S		S
	server 8		server 8
	T		T
	skipping to change at page 70, line 44		skipping to change at line 3284
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 34 change blocks.
	48 lines changed or deleted		100 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/