< draft-hurst-quic-http-data-offset-frame-00.txt		draft-hurst-quic-http-data-offset-frame-01.txt >
	Network Working Group S. Hurst		Network Working Group S. Hurst
	Internet-Draft BBC Research & Development		Internet-Draft BBC Research & Development
	Intended status: Experimental February 18, 2021		Intended status: Experimental 13 August 2021
	Expires: August 22, 2021		Expires: 14 February 2022
	An Offset Extension Frame For HTTP/3 Data		An Offset Extension Frame For HTTP/3 Data
	draft-hurst-quic-http-data-offset-frame-00		draft-hurst-quic-http-data-offset-frame-01
	Abstract		Abstract
	This document specifies an optional extension frame type for HTTP/3		This document specifies an optional extension frame type for HTTP/3
	that extends the functionality of the "DATA" frame type to include an		that extends the functionality of the "DATA" frame type to include an
	offset for the HTTP message payload. This is useful in situations		offset for the HTTP message payload. This is useful in situations
	where the HTTP/3 exchange is taking place over an unreliable		where the HTTP/3 exchange is taking place over an unreliable
	transport mechanism.		transport mechanism.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 August 22, 2021.		This Internet-Draft will expire on 14 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
	3. DATA_WITH_OFFSET Extension Frame . . . . . . . . . . . . . . 3		3. DATA_WITH_OFFSET Extension Frame . . . . . . . . . . . . . . 3
	4. Realising HTTP Multipart Range Responses With HTTP/3 Binary		4. Realising HTTP Multipart Range Responses With HTTP/3 Binary
	Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		Framing . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Response Headers . . . . . . . . . . . . . . . . . . . . 4		4.1. Response Headers . . . . . . . . . . . . . . . . . . . . 4
	4.2. Usage of DATA_WITH_OFFSET frame with HTTP Range Responses 6		4.2. Usage of DATA_WITH_OFFSET frame with HTTP Range
			Responses . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Negotiating Support For The DATA_WITH_OFFSET Frame . . . . . 6		5. Negotiating Support For The DATA_WITH_OFFSET Frame . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8		Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 8
			B.1. Changes since
			draft-hurst-quic-http-data-offset-frame-00 . . . . . . . 8
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	HTTP/3 [QUIC-HTTP] supports the transfer of HTTP semantics over the		HTTP/3 [QUIC-HTTP] supports the transfer of HTTP semantics over the
	QUIC transport protocol [QUIC-TRANSPORT]. In a conventional HTTP/3		QUIC transport protocol [RFC9000]. In a conventional HTTP/3 message
	message exchange, messages consist of a header field section sent as		exchange, messages consist of a header field section sent as a single
	a single "HEADERS" frame, an optional HTTP message payload sent as a		"HEADERS" frame, an optional HTTP message payload sent as a series of
	series of "DATA" frames, followed optionally by a trailer field		"DATA" frames, followed optionally by a trailer field section sent as
	section sent as a single "HEADERS" frame. Each "DATA" frame does not		a single "HEADERS" frame. Each "DATA" frame does not describe its
	describe its position within the HTTP message payload; rather this is		position within the HTTP message payload; rather this is calculated
	calculated from the position within the QUIC stream minus the		from the position within the QUIC stream minus the overhead from
	overhead from HTTP/3 frame headers and the contents of the header		HTTP/3 frame headers and the contents of the header field section.
	field section.
	In the case where the message exchange is taking place across a		In the case where the message exchange is taking place across a
	partially reliable or unreliable profile of [QUIC-TRANSPORT], packet		partially reliable or unreliable profile of [RFC9000], packet loss
	loss could result in a lack of synchronisation in the receiver		could result in a lack of synchronisation in the receiver between the
	between the perceived HTTP/3 "DATA" frame offset and the QUIC		perceived HTTP/3 "DATA" frame offset and the QUIC "STREAM" frame
	"STREAM" frame offset, potentially resulting in a corrupt HTTP		offset, potentially resulting in a corrupt HTTP representation at the
	representation at the receiver.		receiver.
	In addition, there are other use cases, such as HTTP multipart range		In addition, there are other use cases, such as HTTP multipart range
	requests, where the HTTP/3 payload offset has no direct mapping to		requests, where the HTTP/3 payload offset has no direct mapping to
	the value calculated by the method described above.		the value calculated by the method described above.
	This document introduces an extension frame type "DATA_WITH_OFFSET"		This document introduces an extension frame type "DATA_WITH_OFFSET"
	which can be used to explicitly signal the offset in the original		which can be used to explicitly signal the offset in the original
	representation of the data being conveyed within the frame.		representation of the data being conveyed within the frame.
	2. Conventions and Terminology		2. Conventions and Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This document uses the variable-length integer encoding from		This document uses the variable-length integer encoding from
	[QUIC-TRANSPORT]. The packet and frame diagrams in this document use		[RFC9000]. The packet and frame diagrams in this document use the
	the bespoke format specified in [QUIC-TRANSPORT].		bespoke format specified in [RFC9000].
	3. DATA_WITH_OFFSET Extension Frame		3. DATA_WITH_OFFSET Extension Frame
	Based on the "DATA" frame defined in [QUIC-HTTP], the		Based on the "DATA" frame defined in [QUIC-HTTP], the
	"DATA_WITH_OFFSET" frame conveys arbitrary, variable-length sequences		"DATA_WITH_OFFSET" frame conveys arbitrary, variable-length sequences
	of bytes at a defined offset of an HTTP representation. By carrying		of bytes at a defined offset of an HTTP representation. By carrying
	an explicit payload offset in the HTTP/3 frame header, the HTTP		an explicit payload offset in the HTTP/3 frame header, the HTTP
	message payload offset is decoupled from the QUIC "STREAM" frame		message payload offset is decoupled from the QUIC "STREAM" frame
	header offset value. The additional payload offset field takes the		header offset value. The additional payload offset field takes the
	form of a variable-length integer, as shown in Figure 1 below.		form of a variable-length integer, as shown in Figure 1 below.
	DATA_WITH_OFFSET Frame {		DATA_WITH_OFFSET Frame {
	Type (i) = 0xd00,		Type (i) = 0xd00,
	Length (i),		Length (i),
	Offset (i),		Offset (i),
	Data (..),		Data (..),
	}		}
	Figure 1: DATA_WITH_OFFSET Frame		Figure 1: DATA_WITH_OFFSET Frame
	If its peer has indicated support for the "DATA_WITH_OFFSET"		If its peer has indicated support for the "DATA_WITH_OFFSET"
	extension frame type (as described in Section 5 below) a sender MAY		extension frame type (as described in Section 5 below) a sender MAY
	choose to use either "DATA" frames or "DATA_WITH_OFFSET" frames to		choose to use either "DATA" frames or "DATA_WITH_OFFSET" frames to
	transmit an HTTP representation. Senders MUST NOT mix the use of		transmit an HTTP representation. Senders MUST NOT mix the use of
	"DATA" and "DATA_WITH_OFFSET" frames on the same QUIC stream (i.e. in		"DATA" and "DATA_WITH_OFFSET" frames on the same QUIC stream (i.e. in
	the same HTTP message).		the same HTTP message).
	*Author's Note:* The author welcomes comments about relaxation of		*Author's Note:* The author welcomes comments about relaxation of
	the requirement to not mix the usage of "DATA" and		the requirement to not mix the usage of "DATA" and
	skipping to change at page 4, line 48 ¶		skipping to change at page 5, line 5 ¶
	[HTTP-SEMANTICS] specifies how a server may respond to an HTTP		[HTTP-SEMANTICS] specifies how a server may respond to an HTTP
	multipart range request using the 206 (Partial Content) status code.		multipart range request using the 206 (Partial Content) status code.
	The response message carries a "Content-Type" response header		The response message carries a "Content-Type" response header
	indicating the "multipart/byteranges" media type with its required		indicating the "multipart/byteranges" media type with its required
	boundary parameter. This boundary parameter allows each body part to		boundary parameter. This boundary parameter allows each body part to
	carry its own header area containing a "Content-Range" header to		carry its own header area containing a "Content-Range" header to
	describe what range of the selected representation this body part		describe what range of the selected representation this body part
	conveys, as well as a "Content-Type" header (if applicable) which		conveys, as well as a "Content-Type" header (if applicable) which
	describes the actual media type of the selected representation.		describes the actual media type of the selected representation.
	(Note that section 14.3.7.2 of [HTTP-SEMANTICS] describes several		(Note that section 14.2 of [HTTP-SEMANTICS] describes several reasons
	reasons why a server may choose to deliver a different selection of		why a server may choose to deliver a different selection of parts
	parts than what the client originally requested.)		than what the client originally requested.)
	Because a selected representation may only contain a single "Content-		Because a selected representation may only contain a single "Content-
	Type" header field with a single value, repeating this header field		Type" header field with a single value, repeating this header field
	in every body part is highly inefficient. Moreover, the unbounded		in every body part is highly inefficient. Moreover, the unbounded
	length of the boundary parameter further reduces transmission		length of the boundary parameter further reduces transmission
	efficiency.		efficiency.
	This specification modifies the syntax of the "Content-Range" header		This specification modifies the syntax of the "Content-Range" header
	and explicitly defines it as a list-based field as per section 5.7.1		and explicitly defines it as a list-based field as per section 5.6.1
	of [HTTP-SEMANTICS] that is carried in the first "HEADERS" block sent		of [HTTP-SEMANTICS] that is carried in the first "HEADERS" block sent
	as part of an HTTP/3 response. In addition, when used on the same		as part of an HTTP/3 response. In addition, when used on the same
	QUIC stream as "DATA_WITH_OFFSET" frames, this specification permits		QUIC stream as "DATA_WITH_OFFSET" frames, this specification permits
	the "Content-Range" and "Content-Type" HTTP headers to appear in the		the "Content-Range" and "Content-Type" HTTP headers to appear in the
	"HEADERS" frame of a 206 (Partial Content) response, enabling it to		"HEADERS" frame of a 206 (Partial Content) response, enabling it to
	indicate the MIME media type of the whole representation without		indicate the MIME media type of the whole representation without
	needing to duplicate it for each body part.		needing to duplicate it for each body part.
	Content-Range = 1#range-item		Content-Range = 1#range-item
	range-item = range-unit SP		range-item = range-unit SP
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 41 ¶
	unsatisfied-range = "*/" complete-length		unsatisfied-range = "*/" complete-length
	complete-length = 1*DIGIT		complete-length = 1*DIGIT
	Figure 2: ABNF for extended Content-Range		Figure 2: ABNF for extended Content-Range
	:status = 206		:status = 206
	content-type = video/mp4		content-type = video/mp4
	content-range = bytes 10000-17999/18879543, bytes 24000-41999/18879543		content-range = bytes 10000-17999/18879543, bytes 24000-41999/18879543
	Figure 3: Range-Response header example		Figure 3: Range-Response header example
	Implementations advertising support for the "DATA_WITH_OFFSET" frame		Implementations advertising support for the "DATA_WITH_OFFSET" frame
	as described in Section 5 MUST be able to consume this overloaded		as described in Section 5 MUST be able to consume this overloaded
	form of the "Content-Range" HTTP response header.		form of the "Content-Range" HTTP response header.
	A server MAY continue to use the method described in [HTTP-SEMANTICS]		A server MAY continue to use the method described in [HTTP-SEMANTICS]
	even if a client has expressed support for the "DATA_WITH_OFFSET"		even if a client has expressed support for the "DATA_WITH_OFFSET"
	frame.		frame.
	*Author's Note:* Is it possibly worth splitting this out into its		*Author's Note:* Is it possibly worth splitting this out into its
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	"SETTINGS" frame should mirror the value of the frame to indicate		"SETTINGS" frame should mirror the value of the frame to indicate
	which version of the "DATA_WITH_OFFSET" frame it understands,		which version of the "DATA_WITH_OFFSET" frame it understands,
	should subsequent revisions of this draft change the frame type.		should subsequent revisions of this draft change the frame type.
	An endpoint that implements this specification SHOULD send a		An endpoint that implements this specification SHOULD send a
	"SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME" setting at the beginning of		"SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME" setting at the beginning of
	the connection to indicate that it is able to process		the connection to indicate that it is able to process
	"DATA_WITH_OFFSET" frames from its peer.		"DATA_WITH_OFFSET" frames from its peer.
	An endpoint MUST NOT send a "DATA_WITH_OFFSET" frame unless it has		An endpoint MUST NOT send a "DATA_WITH_OFFSET" frame unless it has
	received a positive (i.e. non-zero)		received a positive (i.e. non-zero)
	"SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME" setting from its peer.		"SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME" setting from its peer.
	6. Security Considerations		6. Security Considerations
	This document introduces no new security considerations beyond those		This document introduces no new security considerations beyond those
	discussed in [QUIC-HTTP].		discussed in [QUIC-HTTP].
	7. IANA Considerations		7. IANA Considerations
	This specification registers a new frame type in the "HTTP/3 Frame		This specification registers a new frame type in the "HTTP/3 Frame
	Type" registry ([QUIC-HTTP]).		Type" registry ([QUIC-HTTP]).
	+------------------+-------+---------------+		+==================+=======+===============+
	| Frame Type | Value | Specification |		| Frame Type | Value | Specification |
	+------------------+-------+---------------+		+==================+=======+===============+
	| DATA_WITH_OFFSET | 0xd00 | Section 3 |		| DATA_WITH_OFFSET | 0xd00 | Section 3 |
	+------------------+-------+---------------+		+------------------+-------+---------------+
	Table 1: Registered HTTP/3 Frame Type		Table 1: Registered HTTP/3 Frame Type
	*Author's Note:* The final, intended value of the frame type is		*Author's Note:* The final, intended value of the frame type is
	0xd0f, but in order to allow for this extension to naturally		0xd0f, but in order to allow for this extension to naturally
	evolve and allow for the frame format to change, it starts at		evolve and allow for the frame format to change, it starts at
	0xd00 and subsequent revisions of this extension can take		0xd00 and subsequent revisions of this extension can take
	incrementally higher frame type values between 0xd00 and 0xd0e.		incrementally higher frame type values between 0xd00 and 0xd0e.
	This specification registers a new setting in the "HTTP/3 Settings"		This specification registers a new setting in the "HTTP/3 Settings"
	registry ([QUIC-HTTP]).		registry ([QUIC-HTTP]).
	+-----------------------------------+------+--------------+---------+		+=======================================+=====+=============+=======+
	| Setting | Valu | Specificatio | Default |		|Setting |Value|Specification|Default|
	| | e | n | |		+=======================================+=====+=============+=======+
	+-----------------------------------+------+--------------+---------+		|SETTINGS_ENABLE_DATA_WITH_OFFSET_FRAME |0xd00|Section 5 |0 |
	| SETTINGS_ENABLE_DATA_WITH_OFFSET_ | 0xd0 | Section 5 | 0 |		+---------------------------------------+-----+-------------+-------+
	| FRAME | 0 | | |
	+-----------------------------------+------+--------------+---------+
	Table 2: Registered HTTP/3 Settings		Table 2: Registered HTTP/3 Settings
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[HTTP-SEMANTICS]		[HTTP-SEMANTICS]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-14		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
	(work in progress).		draft-ietf-httpbis-semantics-17,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			semantics-17>.
	[QUIC-HTTP]		[QUIC-HTTP]
	Bishop, M., Ed., "Hypertext Transfer Protocol Version 3		Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", draft-ietf-quic-http-34 (work in progress).		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
			quic-http-34, <https://datatracker.ietf.org/doc/html/
	[QUIC-TRANSPORT]		draft-ietf-quic-http-34>.
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", draft-ietf-quic-
	transport-34 (work in progress).
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.		<https://www.rfc-editor.org/info/rfc7540>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
			Multiplexed and Secure Transport", RFC 9000,
			DOI 10.17487/RFC9000, May 2021,
			<https://www.rfc-editor.org/info/rfc9000>.
	8.2. Informative References		8.2. Informative References
	[QUIC-QPACK]		[QUIC-QPACK]
	Crasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed.,		Crasic, C., Ed., Bishop, M., Ed., and A. Frindell, Ed.,
	"QPACK: Header Compression for HTTP/3", draft-ietf-quic-		"QPACK: Header Compression for HTTP/3", Work in Progress,
	qpack-21 (work in progress).		Internet-Draft, draft-ietf-quic-qpack-21,
			<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
			qpack-21>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The author would like to thank the following for their contributions		The author would like to thank the following for their contributions
	to the design described in the present document: Lucas Pardue,		to the design described in the present document: Lucas Pardue,
	Richard Bradbury and David Waring.		Richard Bradbury and David Waring.
	I am also grateful for Chris Poole's helpful review comments.		I am also grateful for Chris Poole's helpful review comments.
			Appendix B. Changelog
			*RFC Editor's Note:* Please remove this section prior to
			publication of a final version of this document.
			B.1. Changes since draft-hurst-quic-http-data-offset-frame-00
			* Update reference to QUIC transport I-D to [RFC9000].
			* Update reference to [HTTP-SEMANTICS] I-D.
	Author's Address		Author's Address
	Sam Hurst		Sam Hurst
	BBC Research & Development		BBC Research & Development
	Email: sam.hurst@bbc.co.uk		Email: sam.hurst@bbc.co.uk
End of changes. 25 change blocks.
	59 lines changed or deleted		77 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/