< draft-snell-httpbis-bohe-00.txt		draft-snell-httpbis-bohe-01.txt >
	Network Working Group J. Snell		Network Working Group J. Snell
	Internet-Draft August 2, 2012		Internet-Draft October 3, 2012
	Intended status: Informational		Intended status: Informational
	Expires: February 3, 2013		Expires: April 6, 2013
	HTTP/2.0 Discussion: Binary Optimized Header Encoding		HTTP/2.0 Discussion: Binary Optimized Header Encoding
	draft-snell-httpbis-bohe-00		draft-snell-httpbis-bohe-01
	Abstract		Abstract
	This memo describes a proposed alternative encoding for headers		This memo describes a proposed alternative encoding for headers
	within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames.		within SPDY SYN_STREAM, SYN_REPLY and HEADERS frames.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31		skipping to change at page 1, line 31
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 3, 2013.		This Internet-Draft will expire on April 6, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3		1. Binary Optimized Header Encoding . . . . . . . . . . . . . . . 3
	1.1. Registered Headers . . . . . . . . . . . . . . . . . . . . 3		1.1. Registered Headers . . . . . . . . . . . . . . . . . . . . 3
	1.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 5		1.2. Extension Headers . . . . . . . . . . . . . . . . . . . . 4
	1.3. Binary vs. Character Values . . . . . . . . . . . . . . . 5		1.3. Binary vs. Character Values . . . . . . . . . . . . . . . 5
	1.4. Example Headers . . . . . . . . . . . . . . . . . . . . . 7		1.4. Example Headers . . . . . . . . . . . . . . . . . . . . . 7
	2. Security Considerations . . . . . . . . . . . . . . . . . . . 9		2. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	3. Normative References . . . . . . . . . . . . . . . . . . . . . 9		3. Normative References . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Additional Examples . . . . . . . . . . . . . . . . . 9		Appendix A. Additional Examples . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Binary Optimized Header Encoding		1. Binary Optimized Header Encoding
	Binary Optimized Header Encoding is a proposed alternative		Binary Optimized Header Encoding is a proposed alternative
	serialization for headers within SPDY SYN_STREAM, SYN_REPLY and		serialization for headers within SPDY SYN_STREAM, SYN_REPLY and
	HEADERS frames that is designed to optimize generation, consumption		HEADERS frames that is designed to optimize generation, consumption
	and processing of the most commonly used HTTP headers.		and processing of the most commonly used HTTP headers.
	skipping to change at page 3, line 26		skipping to change at page 3, line 26
	+------------------------------------+		+------------------------------------+
	|T| Header |		|T| Header |
	+------------------------------------+		+------------------------------------+
	| ... |		| ... |
	Within the existing SPDY Header Block, a 32-bit value is used to		Within the existing SPDY Header Block, a 32-bit value is used to
	identify the number of headers within the block. For all practical		identify the number of headers within the block. For all practical
	purposes, it is exceedingly unlikely that a single block of headers		purposes, it is exceedingly unlikely that a single block of headers
	will contain anywhere near 4,294,967,295 distinct headers. Obviously		will contain anywhere near 4,294,967,295 distinct headers. Obviously
	a 32-bit integer is significant overkill for this purpose. As an		a 32-bit integer is significant overkill for this purpose. As an
	alternative, an 8-bit value suggested.		alternative, an 8-bit value is suggested.
	The header block consists of zero or more distinct headers, each of		The header block consists of zero or more distinct headers, each of
	which begin with a single Type-bit whose value indicates the type of		which begin with a single Type-bit whose value indicates the type of
	header. There are two header types: Registered and Extension. The		header. There are two header types: Registered and Extension. The
	specific structure of the remaining header depends on the header		specific structure of the header depends on the type.
	type.
	The header block MAY be compressed as described within		The header block MAY be compressed as described within
	[draft-montenegro-httpbis-speed-mobility-02].		[draft-montenegro-httpbis-speed-mobility-02].
	1.1. Registered Headers		1.1. Registered Headers
	Registered Headers are well-known and well-defined headers for which		Registered Headers are well-known and well-defined header fields for
	there is a published RFC and IANA registration. Each is assigned an		which there is a published RFC and IANA registration. Each is
	unsigned 12-bit integer identifier and an unsigned 3-bit integer		assigned an unsigned 15-bit integer identifier.
	codepage. If the codepage is 0, the implication is that the header
	MUST be understood in order for the request or response message to be
	handled properly. Codepages 1-5 represent "MUST-IGNORE" headers;
	that is, such headers MUST be ignored by processors if they are
	unrecognized by the processing application. Codepages 6 and 7 are
	reserved for "Private Use", with Codepage 6 being used for "MUST
	UNDERSTAND PRIVATE USE" headers.
	The structure of Registered Headers:		The structure of Registered Headers:
	+------------------------------+		+------------------------------+
	|0| cp(3-bit) | id (12-bit) |		|0| id (15-bit) |
	+------------------------------+		+------------------------------+
	| flags(8-bit) | len (16-bit) |		|E|M| len (22-bit) |
	+------------------------------+		+------------------------------+
	| value... |		| value... |
	+------------------------------+		+------------------------------+
	The first single bit within the structure is the Type-bit. When this		The first single bit within the structure is the Type-bit. When this
	bit is off, the header is a Registered Header.		bit is off, the header is a Registered Header.
	The next three bits identify the headers codepage. The value is		The next fifteen bits specify the header's specific numeric
	interpreted as an unsigned integer in the range 0-7.		identifier as assigned within the IANA registry.
	The next twelve bits specify the header's specific numeric identifier		The next bit (E) indicates, when set, that the header field value
	within the codepage.		contains UTF-8 encoded character content. If the bit is not set, the
			value is assumed to contain non-character-based binary data.
	Following the identifier are 8 reserved flag bits.		Following the identifier are 2 reserved bits:
	o Bit 0x1 indicates that the header value contains UTF-8 encoded		o The first (E) indicates that the header value contains UTF-8
	character content. If the bit is not set, the value is assumed to		encoded character content. If the bit is not set, the value is
	contain non-character-based binary data.		assumed to contain non-character-based binary data.
	o Bit 0x2 indicates that the header specifies multiple NUL (0)		o The second (M) indicates that the value includes multiple NUL (0)
	separated values. When set, processors MUST treat NUL (0) octets		separated values. When set, processors MUST treat NUL (0) octets
	within the value as a delimiter and not as part of the value		within the value as a delimiter and not as part of the value
	itself.		itself.
	The remaining content of the structure consists of a 16-bit unsigned		The remaining content of the structure consists of a 22-bit unsigned
	integer specifying the remaining length of the header value. The		integer specifying the remaining length of the header value. The
	value MAY be zero length.		value MAY be zero length.
	The minimum length of a registered header is 5-octets (40-bits).		The minimum length of a registered header is 5-octets (40-bits).
	When Flag 0x2 is set, the header may contain multiple values		When bit M is set, the header may contain multiple values separated
	separated by a single NUL (0) byte. Each distinct value MUST NOT be		by a single NUL (0) byte. Each distinct value MUST NOT be zero-
	zero-length. When Flag 0x2 is not set, and Flag 0x1 is also not set,		length. When bits E and M are bot not set, NUL bytes contained
	NUL bytes contained within the value are to be considered part of the		within the value are to be considered part of the value. The use of
	value. The use of NUL bytes within character-based values is not		NUL bytes within character-based values is not permitted except when
	permitted except when used as a delimiter separating multiple values.		used as a delimiter separating multiple values.
	When multiple values are included, the value length field MUST		When multiple values are included, the value length field MUST
	specify the total length, in octets, of all values plus the number of		specify the total length, in octets, of all values plus the number of
	NUL (0) byte separators. For example, for a header value consisting		NUL (0) byte separators. For example, for a header value consisting
	of the two strings "foo" and "bar", the total value length would be		of the two strings "foo" and "bar", the total value length would be
	7.		7.
	1.2. Extension Headers		1.2. Extension Headers
	Extension Headers are simple name+value pairs essentially as they		Extension Headers are simple name+value pairs essentially as they
	exist today, but with a number of important modifications.		exist today, but with a number of important modifications.
	The structure of Extension Headers		The structure of Extension Headers
	+------------------------------+		+------------------------------+
	|1| flags(7-bit) | namelen (8) |		|1| namelen (7) | name |
	+------------------------------+		+------------------------------+
	| name | val len (16) | value |		|E|M| val len (22) | value |
	+------------------------------+		+------------------------------+
	The first single bit is the Type-bit. When this bit is on, the		The first single bit is the Type-bit. When this bit is on, the
	header is an Extension Header.		header is an Extension Header.
	The next seven bits are reserved flags.		The next 7-bits specify the length in octets of the ASCII-encoded
	o Bit 0x1 indicates that the header value contains UTF-8 encoded
	character content. If the bit is not set, the value is assumed to
	contain non-character-based binary data.
	o Bit 0x2 indicates that the header specifies multiple NUL (0)
	separated values. When set, processors MUST treat NUL (0) octets
	within the value as a value-separated and not as part of the value
	itself.
	The next 8-bits specify the length in octets of the ASCII-encoded
	header name as unsigned integer, followed by the name itself. The		header name as unsigned integer, followed by the name itself. The
	name MUST conform to the field-name construction as defined in		name MUST conform to the field-name construction as defined in
	[draft-ietf-httpbis-p1-messaging-2].		[draft-ietf-httpbis-p1-messaging-2].
	The length of the remaining value is specified as an unsigned 16-bit		Following the identifier are 2 reserved bits:
			o The first (E) indicates that the header value contains UTF-8
			encoded character content. If the bit is not set, the value is
			assumed to contain non-character-based binary data.
			o The second (M) indicates that the header specifies multiple NUL
			(0) separated values. When set, processors MUST treat NUL (0)
			octets within the value as a value-separator and not as part of
			the value itself.
			The length of the remaining value is specified as an unsigned 22-bit
	integer, followed by the value itself. Zero length values are		integer, followed by the value itself. Zero length values are
	permitted.		permitted.
	When Flag 0x2 is set, the header may contain multiple values		When bit M is set, the header may contain multiple values separated
	separated by a single NUL (0) byte. Each distinct value MUST be		by a single NUL (0) byte. Each distinct value MUST NOT be zero-
	zero-length.		length. When bits E and M are bot not set, NUL bytes contained
			within the value are to be considered part of the value. The use of
			NUL bytes within character-based values is not permitted except when
			used as a delimiter separating multiple values.
	When multiple values are included, the value length field MUST		When multiple values are included, the value length field MUST
	specify the total length, in octets, of all values plus the number of		specify the total length, in octets, of all values plus the number of
	NUL (0) byte separators. For example, for a header value consisting		NUL (0) byte separators. For example, for a header value consisting
	of the two strings "foo" and "bar", the total value length would be		of the two strings "foo" and "bar", the total value length would be
	7.		7.
	1.3. Binary vs. Character Values		1.3. Binary vs. Character Values
	Specific header values can be encoded as either a stream of binary		Specific header values can be encoded as either a stream of binary
	skipping to change at page 6, line 21		skipping to change at page 6, line 19
	00 00 00 08 3a 76 65 72 |....:ver|		00 00 00 08 3a 76 65 72 |....:ver|
	73 69 6f 6e 00 00 00 03 |sion....|		73 69 6f 6e 00 00 00 03 |sion....|
	31 2e 31 |2.0|		31 2e 31 |2.0|
	Using the Binary Optimized Header Encoding, this can be reduced to a		Using the Binary Optimized Header Encoding, this can be reduced to a
	compact 7 or 8 bytes using either binary or character data:		compact 7 or 8 bytes using either binary or character data:
	Version Header using Character Data:		Version Header using Character Data:
	00 01 01 00 03 31 2e 31 |.....2.0|		00 01 80 00 03 31 2e 31 |.....2.0|
	Version Header using Binary Data:		Version Header using Binary Data:
	00 01 00 00 02 02 00 |.......|		00 01 00 00 02 02 00 |.......|
	Likewise, SPDY uses a ":method" header to specify the HTTP Method		Likewise, SPDY uses a ":method" header to specify the HTTP Method
	used for a particular request, with the value represented as an ASCII		used for a particular request, with the value represented as an ASCII
	string, consuming 18 bytes for GET requests.		string, consuming 18 bytes for GET requests.
	Method Header using the existing SPDY encoding:		Method Header using the existing SPDY encoding:
	00 00 00 07 3a 6d 65 74 |....:met|		00 00 00 07 3a 6d 65 74 |....:met|
	68 6f 64 00 00 00 03 47 |hod....G|		68 6f 64 00 00 00 03 47 |hod....G|
	45 54 |GET|		45 54 |GET|
	Using optimized encoding, this can be reduced to a compact 6 or 8		Using optimized encoding, this can be reduced to a compact 6 or 8
	bytes using either binary or character data:		bytes using either binary or character data:
	Method Header using Character Data:		Method Header using Character Data:
	00 02 01 00 03 47 45 54 |.....GET|		00 02 80 00 03 47 45 54 |.....GET|
	Method Header using Binary Data, assuming the value 0x1 is defined to		Method Header using Binary Data, assuming the value 0x1 is defined to
	represent the GET method:		represent the GET method:
	00 02 00 00 01 01 |......|		00 02 00 00 01 01 |......|
	There are many headers used within HTTP applications for which binary		There are many headers used within HTTP applications for which binary
	encodings would be difficult or unnecessary. For those, utilizing		encodings would be difficult or unnecessary. For those, utilizing
	the character encoding option would be appropriate. With some work		the character encoding option would be appropriate. With some work
	it should be possible to define optimized binary encodings for many		it should be possible to define optimized binary encodings for many
	of the existing complex headers.		of the existing complex headers.
	1.4. Example Headers		1.4. Example Headers
	Assume the following registered headers:		Assume the following registered headers:
	+--------------------+----------+----+		+--------------------+----+
	| HTTP Header | Codepage | ID |		| HTTP Header | ID |
	+--------------------+----------+----+		+--------------------+----+
	| Version | 0 | 1 |		| Version | 1 |
	| Method | 0 | 2 |		| Method | 2 |
	| Host | 0 | 3 |		| Host | 3 |
	| Path (Request URI) | 0 | 4 |		| Path (Request URI) | 4 |
	| Accept-Language | 1 | 1 |		| Accept-Language | 5 |
	+--------------------+----------+----+		+--------------------+----+
	And the following values representing known HTTP Methods:		And the following values representing known HTTP Methods:
	+---------+-------+		+---------+-------+
	| Method | Value |		| Method | Value |
	+---------+-------+		+---------+-------+
	| GET | 1 |		| GET | 1 |
	| POST | 2 |		| POST | 2 |
	| PUT | 3 |		| PUT | 3 |
	| DELETE | 4 |		| DELETE | 4 |
	skipping to change at page 7, line 45		skipping to change at page 7, line 44
	The Version header can be encoded as (7-bytes):		The Version header can be encoded as (7-bytes):
	00 01 00 00 02 02 00 |.......|		00 01 00 00 02 02 00 |.......|
	The GET Method header can be encoded as (6-bytes):		The GET Method header can be encoded as (6-bytes):
	00 02 00 00 01 01 |......|		00 02 00 00 01 01 |......|
	The Host Header can be encoded as (20-bytes):		The Host Header can be encoded as (20-bytes):
	00 03 01 00 0f 77 77 77 |.....www|		00 03 80 00 0f 77 77 77 |.....www|
	2e 65 78 61 6d 70 6c 65 |.example|		2e 65 78 61 6d 70 6c 65 |.example|
	2e 6f 72 67 |.org|		2e 6f 72 67 |.org|
	A simple Accept-Lang header would be encoded as (10-bytes):		A simple Accept-Lang header would be encoded as (10-bytes):
	10 01 01 00 05 65 6e 2d |.....en-|		00 05 80 00 05 65 6e 2d |.....en-|
	55 53 |US|		55 53 |US|
	A Path header encoding the request URI (45-bytes):		A Path header encoding the request URI (45-bytes):
	00 04 01 00 28 2f 74 68 |...../th|		00 04 80 00 28 2f 74 68 |...../th|
	69 73 2f 69 73 2f 74 68 |is/is/th|		69 73 2f 69 73 2f 74 68 |is/is/th|
	65 2f 72 65 71 75 65 73 |e/reques|		65 2f 72 65 71 75 65 73 |e/reques|
	74 3f 69 73 3d 69 74 26 |t?is=it&|		74 3f 69 73 3d 69 74 26 |t?is=it&|
	6e 6f 74 3d 62 65 61 75 |not=beau|		6e 6f 74 3d 62 65 61 75 |not=beau|
	74 69 66 75 6c |tiful|		74 69 66 75 6c |tiful|
	The combined serialization of the five headers into a single block		The combined serialization of the five headers into a single block
	requires a total of 89 bytes. By comparison, the equivalent		requires a total of 89 bytes. By comparison, the equivalent
	serialization using the existing SPDY encoding requires 150 bytes		serialization using the existing SPDY encoding requires 150 bytes
	sans compression (28 bytes of which are wasted by the unnecessary use		sans compression (28 bytes of which are wasted by the unnecessary use
	skipping to change at page 10, line 5		skipping to change at page 9, line 15
	3. Normative References		3. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Appendix A. Additional Examples		Appendix A. Additional Examples
	Assuming the following (intentionally incomplete) header		Assuming the following (intentionally incomplete) header
	registrations adapted from the existing http-bis specifications.		registrations adapted from the existing http-bis specifications.
	+---------------------+----------+----+		+---------------------+----+
	| HTTP Header | Codepage | ID |		| HTTP Header | ID |
	+---------------------+----------+----+		+---------------------+----+
	| Version | 0 | 1 |		| Version | 1 |
	| Method | 0 | 2 |		| Method | 2 |
	| Host | 0 | 3 |		| Host | 3 |
	| Path (Request URI) | 0 | 4 |		| Path (Request URI) | 4 |
	| Status | 0 | 5 |		| Status | 5 |
	| Status-Text | 0 | 6 |		| Status-Text | 6 |
	| Content-Length | 0 | 7 |		| Content-Length | 7 |
	| Content-Type | 0 | 8 |		| Content-Type | 8 |
	| Content-Encoding | 0 | 9 |		| Content-Encoding | 9 |
	| Expect | 0 | 10 |		| Expect | 10 |
	| Location | 0 | 11 |		| Location | 11 |
	| Last-Modified | 0 | 12 |		| Last-Modified | 12 |
	| ETag | 0 | 13 |		| ETag | 13 |
	| If-Match | 0 | 14 |		| If-Match | 14 |
	| If-None-Match | 0 | 15 |		| If-None-Match | 15 |
	| If-Modified-Since | 0 | 16 |		| If-Modified-Since | 16 |
	| If-Unmodified-Since | 0 | 17 |		| If-Unmodified-Since | 17 |
	| Age | 0 | 18 |		| Age | 18 |
	| Cache-Control | 0 | 19 |		| Cache-Control | 19 |
	| Expires | 0 | 20 |		| Expires | 20 |
	| Vary | 0 | 21 |		| Vary | 21 |
	| Accept | 1 | 1 |		| Accept | 22 |
	| Accept-Language | 1 | 2 |		| Accept-Language | 23 |
	| Accept-Charset | 1 | 3 |		| Accept-Charset | 24 |
	| Accept-Encoding | 1 | 4 |		| Accept-Encoding | 25 |
	| Allow | 1 | 5 |		| Allow | 26 |
	| Content-Language | 1 | 6 |		| Content-Language | 27 |
	| Content-Location | 1 | 7 |		| Content-Location | 28 |
	| Date | 1 | 8 |		| Date | 29 |
	| From | 1 | 9 |		| From | 30 |
	| Warning | 1 | 10 |		| Warning | 31 |
	+---------------------+----------+----+		+---------------------+----+
	And the following values representing known HTTP Methods:		And the following values representing known HTTP Methods:
	+---------+-------+		+---------+-------+
	| Method | Value |		| Method | Value |
	+---------+-------+		+---------+-------+
	| GET | 1 |		| GET | 1 |
	| POST | 2 |		| POST | 2 |
	| PUT | 3 |		| PUT | 3 |
	| DELETE | 4 |		| DELETE | 4 |
	skipping to change at page 11, line 34		skipping to change at page 10, line 34
	Method Header (GET Request)		Method Header (GET Request)
	00 02 00 00 01 01 |......|		00 02 00 00 01 01 |......|
	Method Header (PATCH Request)		Method Header (PATCH Request)
	00 02 00 00 01 05 |......|		00 02 00 00 01 05 |......|
	Method Header (Custom "FOO" Method)		Method Header (Custom "FOO" Method)
	00 02 01 00 03 46 4F 4F |.....FOO|		00 02 80 00 03 46 4F 4F |.....FOO|
	Host Header:		Host Header:
	00 03 01 00 0f 77 77 77 |.....www|		00 03 80 00 0f 77 77 77 |.....www|
	2e 65 78 61 6d 70 6c 65 |.example|		2e 65 78 61 6d 70 6c 65 |.example|
	2e 6f 72 67 |.org|		2e 6f 72 67 |.org|
	Representation of HTTP Response Status ("200 OK"):		Representation of HTTP Response Status ("200 OK") as two separate
			headers, one containing the status code, the other containing the
			status text:
	00 05 00 00 01 C8 00 06 |........|		00 05 00 00 01 C8 00 06 |........|
	01 00 02 4F 4B |...OK|		80 00 02 4F 4B |...OK|
	The status above is represented as two separate headers, one		An alternative would be represent the status as a single header
	containing the status code, the other containing the status text.		containing multiple values:
			00 05 C0 00 04 C8 00 4F |.......O|
			4B |K|
	Content-Length Header (value encoded as uint32):		Content-Length Header (value encoded as uint32):
	00 07 00 00 04 00 00 00 |........|		00 07 00 00 04 00 00 00 |........|
	C8 |.|		C8 |.|
	Content-Type Header:		Content-Type Header:
	00 08 01 00 0A 69 6d 61 |.....ima|		00 08 80 00 0A 69 6d 61 |.....ima|
	67 65 2f 6a 70 65 67 |ge/jpeg|		67 65 2f 6a 70 65 67 |ge/jpeg|
	Expect Header (Expect: 100):		Expect Header (Expect: 100):
	00 0A 00 00 01 64 |......|		00 0A 00 00 01 64 |......|
	Last-Modified (Using RFC3339 Format):		Last-Modified (Using RFC3339 Format):
	00 0C 01 00 19 32 30 31 |.....201|		00 0C 80 00 19 32 30 31 |.....201|
	32 2d 30 38 2d 30 31 54 |2-08-01T|		32 2d 30 38 2d 30 31 54 |2-08-01T|
	30 34 3a 32 33 3a 31 32 |04:23:12|		30 34 3a 32 33 3a 31 32 |04:23:12|
	2e 31 32 33 34 5a |.1234Z|		2e 31 32 33 34 5a |.1234Z|
	ETag (Strong Entity-Tag, String-format):		ETag (Strong Entity-Tag, String-format):
	00 0D 01 00 07 22 61 62 |....."ab|		00 0D 80 00 07 22 61 62 |....."ab|
	63 64 65 22 |cde"|		63 64 65 22 |cde"|
	If-None-Match:		If-None-Match:
	00 0F 01 00 07 22 61 62 |....."ab|		00 0F 80 00 07 22 61 62 |....."ab|
	63 64 65 22 |cde"|		63 64 65 22 |cde"|
	If-None-Match (Multiple values)		If-None-Match (Multiple values)
	00 0F 03 00 0F 22 61 62 |....."ab|		00 0F C0 00 0F 22 61 62 |....."ab|
	63 64 65 22 00 22 61 62 |cde"."ab|		63 64 65 22 00 22 61 62 |cde"."ab|
	63 64 66 22 |cdf"|		63 64 66 22 |cdf"|
	Allow (GET, POST, FOO):		Allow (GET, POST, FOO):
	10 05 02 00 07 01 00 02 |........|		00 1A C0 00 07 01 00 02 |........|
	00 46 4f 4f |.FOO|		00 46 4f 4f |.FOO|
	Author's Address		Author's Address
	James M Snell		James M Snell
	Email: jasnell@gmail.com		Email: jasnell@gmail.com
End of changes. 39 change blocks.
	114 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/tools/rfcdiff/