< draft-irtf-dtnrg-sdnv-07.txt		draft-irtf-dtnrg-sdnv-08.txt >
	Network Working Group W. Eddy		Network Working Group W. Eddy
	Internet-Draft MTI Systems		Internet-Draft MTI Systems
	Intended status: Informational E. Davies		Intended status: Informational E. Davies
	Expires: April 14, 2011 Folly Consulting		Expires: July 30, 2011 Folly Consulting
	October 11, 2010		January 26, 2011
	Using Self-Delimiting Numeric Values in Protocols		Using Self-Delimiting Numeric Values in Protocols
	draft-irtf-dtnrg-sdnv-07		draft-irtf-dtnrg-sdnv-08
	Abstract		Abstract
	Self-Delimiting Numeric Values (SDNVs) have recently been introduced		Self-Delimiting Numeric Values (SDNVs) have recently been introduced
	as a field type in proposed Delay-Tolerant Networking protocols.		as a field type in proposed Delay-Tolerant Networking protocols.
	SDNVs encode an arbitrary-length non-negative integer or arbitrary-		SDNVs encode an arbitrary-length non-negative integer or arbitrary-
	length bit-string with minimum overhead. They are intended to		length bit-string with minimum overhead. They are intended to
	provide protocol flexibility without sacrificing economy, and to		provide protocol flexibility without sacrificing economy, and to
	assist in future-proofing protocols under development. This document		assist in future-proofing protocols under development. This document
	describes formats and algorithms for SDNV encoding and decoding,		describes formats and algorithms for SDNV encoding and decoding,
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 April 14, 2011.		This Internet-Draft will expire on July 30, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	through the use of the Window Scale option [RFC1323], which provides		through the use of the Window Scale option [RFC1323], which provides
	a multiplier for the advertised window field. However, the Window		a multiplier for the advertised window field. However, the Window
	Scale multiplier is fixed for the duration of the connection,		Scale multiplier is fixed for the duration of the connection,
	requires support from each end of a TCP connection, and limits the		requires support from each end of a TCP connection, and limits the
	precision of the advertised receive window, so this is certainly a		precision of the advertised receive window, so this is certainly a
	less-than-ideal solution. Because of the field width limit in the		less-than-ideal solution. Because of the field width limit in the
	original design however, the Window Scale is necessary for TCP to		original design however, the Window Scale is necessary for TCP to
	reach high sending rates.		reach high sending rates.
	An IPv4 address is fixed at 32 bits [RFC0791] (as a historical note,		An IPv4 address is fixed at 32 bits [RFC0791] (as a historical note,
	an early version 0 IP header format specification in [IEN21] used		an early version of the IP header format specification in [IEN21]
	variable-length addresses in multiples of 8-bits up to 120-bits).		used variable-length addresses in multiples of 8-bits up to 120-
	Due to the way that subnetting and assignment of address blocks was		bits). Due to the way that subnetting and assignment of address
	performed, the number of IPv4 addresses has been seen as a limit to		blocks was performed, the number of IPv4 addresses has been seen as a
	the growth of the Internet [Hain05]. Two divergent paths to solve		limit to the growth of the Internet [Hain05]. Two divergent paths to
	this problem have been the use of Network Address Translators (NATs)		solve this problem have been the use of Network Address Translators
	and the development of IPv6. NATs have caused a number of other		(NATs) and the development of IPv6. NATs have caused a number of
	issues and problems [RFC2993], leading to increased complexity and		other issues and problems [RFC2993], leading to increased complexity
	fragility, as well as forcing work-arounds to be engineered for many		and fragility, as well as forcing workarounds to be engineered for
	other protocols to function within a NATed environment. The IPv6		many other protocols to function within a NATed environment. The
	solution's transitional work has been underway for several years, but		IPv6 solution's transitional work has been underway for several
	has still only just begun to have visible impact on the global		years, but has still only just begun to have visible impact on the
	Internet.		global Internet.
	Of course, in both the case of the TCP receive window and IPv4		Of course, in both the case of the TCP receive window and IPv4
	address length, the field size chosen by the designers seemed like a		address length, the field size chosen by the designers seemed like a
	good idea at the time. The fields were more than big enough for the		good idea at the time. The fields were more than big enough for the
	originally perceived usage of the protocols, and yet were small		originally perceived usage of the protocols, and yet were small
	enough to allow the headers to remain compact and relatively easy and		enough to allow the headers to remain compact and relatively easy and
	efficient to parse on machines of the time. The fixed sizes that		efficient to parse on machines of the time. The fixed sizes that
	were defined represented a tradeoff between the scalability of the		were defined represented a trade off between the scalability of the
	protocol versus the overhead and efficiency of processing. In both		protocol versus the overhead and efficiency of processing. In both
	cases, these engineering decisions turned out to be painfully		cases, these engineering decisions turned out to be painfully
	restrictive in the longer term.		restrictive in the longer term.
	1.2. SDNVs for DTN Protocols		1.2. SDNVs for DTN Protocols
	In specifications for the DTN Bundle Protocol (BP) [RFC5050] and		In specifications for the DTN Bundle Protocol (BP) [RFC5050] and
	Licklider Transmission Protocol (LTP) [RFC5326], SDNVs have been used		Licklider Transmission Protocol (LTP) [RFC5326], SDNVs have been used
	for several fields including identifiers, payload/header lengths, and		for several fields including identifiers, payload/header lengths, and
	serial (sequence) numbers. SDNVs were developed for use in these		serial (sequence) numbers. SDNVs were developed for use in these
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 40 ¶
	o Sequence numbers as in TCP or SCTP,		o Sequence numbers as in TCP or SCTP,
	o Values used in cryptographic algorithms such as RSA keys, Diffie-		o Values used in cryptographic algorithms such as RSA keys, Diffie-
	Hellman key-agreement, or coordinates of points on elliptic		Hellman key-agreement, or coordinates of points on elliptic
	curves.		curves.
	o Message lengths as used in file transfer protocols.		o Message lengths as used in file transfer protocols.
	o Nonces and cookies.		o Nonces and cookies.
	o Etc.
	As any bit-field can be interpreted as an unsigned integer, SDNVs can		As any bit-field can be interpreted as an unsigned integer, SDNVs can
	also encode arbitrary-length bit-fields, including bit-fields		also encode arbitrary-length bit-fields, including bit-fields
	representing signed integers or other data types; however, this		representing signed integers or other data types; however, this
	document assumes SDNV encoding and decoding in terms of unsigned		document assumes SDNV encoding and decoding in terms of unsigned
	integers. Implementations may differ in the interface that they		integers. Implementations may differ in the interface that they
	provide to SDNV encoding and decoding functions, in terms of whether		provide to SDNV encoding and decoding functions, in terms of whether
	the values are numeric, bit-fields, etc.; this detail does not alter		the values are numeric, bit-fields, etc.; this detail does not alter
	the representation or algorithms described in this document.		the representation or algorithms described in this document.
	The use of SDNVs rather than fixed length fields gives protocol		The use of SDNVs rather than fixed length fields gives protocol
	designers the ability to ameliorate the consequences of making		designers the ability to ameliorate the consequences of making
	difficult-to-reverse field-sizing decisions, as the SDNV format grows		difficult-to-reverse field-sizing decisions, as the SDNV format grows
	and shrinks depending on the particular value encoded. SDNVs do not		and shrinks depending on the particular value encoded. SDNVs do not
	necessarily provide optimal encodings for values of any particular		necessarily provide optimal encodings for values of any particular
	length, however they allow protocol designers to avoid potential		length, however they allow protocol designers to avoid potential
	blunders in assigning fixed lengths, and remove the complexity		blunders in assigning fixed lengths, and remove the complexity
	involved with either negotiating field lengths or constructing		involved with either negotiating field lengths or constructing
	protocol extensions.		protocol extensions. However, if SDNVs are used to encode bit-
			fields, it is essential that the sender and receiver have a
			consistent interpretation of the decoded value. This is discussed
			further in Section 2.
	To our knowledge, at this time, no IETF transport or network-layer		To our knowledge, at this time, no IETF transport or network-layer
	protocol designed for use outside of the DTN domain has proposed to		protocol designed for use outside of the DTN domain has proposed to
	use SDNVs; however there is no inherent reason not to use SDNVs more		use SDNVs; however there is no inherent reason not to use SDNVs more
	broadly in the future. The two examples cited here, of fields that		broadly in the future. The two examples cited here, of fields that
	have proven too small in general Internet protocols, are only a small		have proven too small in general Internet protocols, are only a small
	sampling of the much larger set of similar instances that the authors		sampling of the much larger set of similar instances that the authors
	can think of. Outside the Internet protocols, within ASN.1 and		can think of. Outside the Internet protocols, within ASN.1 and
	previous ITU protocols, constructs very similar to SDNVs have been		previous ITU protocols, constructs very similar to SDNVs have been
	used for many years due to engineering concerns very similar to those		used for many years due to engineering concerns very similar to those
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	Length field of a TLV structure to be an SDNV whose value is the		Length field of a TLV structure to be an SDNV whose value is the
	length of the TLV's Value field. In this way, one can avoid forcing		length of the TLV's Value field. In this way, one can avoid forcing
	large numbers from being directly encoded as an SDNV, yet retain the		large numbers from being directly encoded as an SDNV, yet retain the
	extensibility that using SDNVs grants.		extensibility that using SDNVs grants.
	2. Definition of SDNVs		2. Definition of SDNVs
	Early in the work of the DTNRG, it was agreed that the properties of		Early in the work of the DTNRG, it was agreed that the properties of
	an SDNV were useful for DTN protocols. The exact SDNV format used by		an SDNV were useful for DTN protocols. The exact SDNV format used by
	the DTNRG evolved somewhat over time before the publication of the		the DTNRG evolved somewhat over time before the publication of the
	initial RFCs on LTP and the BP. An ealier version bore resemblance		initial RFCs on LTP and the BP. An earlier version bore resemblance
	to the ASN.1 [ASN1] Basic Encoding Rules (BER) [ASN1-BER] for lengths		to the ASN.1 [ASN1] Basic Encoding Rules (BER) [ASN1-BER] for lengths
	(Section 8.1.3 of X.690). The current SDNV format is the one used by		(Section 8.1.3 of X.690). The current SDNV format is the one used by
	ASN.1 BER for encoding tag identifiers greater than or equal to 31		ASN.1 BER for encoding tag identifiers greater than or equal to 31
	(Section 8.1.2.4.2 of X.690). A comparison between the current SDNV		(Section 8.1.2.4.2 of X.690). A comparison between the current SDNV
	format and the early SDNV format is made in Section 4.		format and the early SDNV format is made in Section 4.
	The format currently used is very simple. Before encoding, an		The format currently used is very simple. Before encoding, an
	integer is represented as a left-to-right bitstring beginning with		integer is represented as a left-to-right bitstring beginning with
	its most significant bit, and ending with its least signifcant bit.		its most significant bit, and ending with its least significant bit.
	If the bitstring's length is not a multiple of 7, then the string is		If the bitstring's length is not a multiple of 7, then the string is
	left-padded with zeros. When transmitted, the bits are encoded into		left-padded with zeros. When transmitted, the bits are encoded into
	a series of bytes. The low-order 7 bits of each byte in the encoded		a series of bytes. The low-order 7 bits of each byte in the encoded
	format are taken left-to-right from the integer's bitstring		format are taken left-to-right from the integer's bitstring
	representation. The most significant bit of each byte specifies		representation. The most significant bit of each byte specifies
	whether it is the final byte of the encoded value (when it holds a		whether it is the final byte of the encoded value (when it holds a
	0), or not (when it holds a 1).		0), or not (when it holds a 1).
	For example:		For example:
	skipping to change at page 8, line 4 ¶		skipping to change at page 8, line 4 ¶
	discarded by the SDNV encoder. Protocols that use SDNVs should not		discarded by the SDNV encoder. Protocols that use SDNVs should not
	rely on leading-zeros being retained after encoding and decoding		rely on leading-zeros being retained after encoding and decoding
	operations. (2) When decoding SDNVs, the relevant number of leading		operations. (2) When decoding SDNVs, the relevant number of leading
	zeros required to pad up to a machine word or other natural data unit		zeros required to pad up to a machine word or other natural data unit
	might be added. These are put in the most-significant positions in		might be added. These are put in the most-significant positions in
	order to not change the value of the number. Protocols using SDNVs		order to not change the value of the number. Protocols using SDNVs
	should consider situations where lost zero-padding may be		should consider situations where lost zero-padding may be
	problematic.		problematic.
	The issues of zero-padding are particularly relevant where an SDNV is		The issues of zero-padding are particularly relevant where an SDNV is
	being used to represent a bit field to be transmitted by a protocol.		being used to represent a bit-field to be transmitted by a protocol.
	The specification of the protocol and any associated IANA registry		The specification of the protocol and any associated IANA registry
	should specify the allocation and usage of bit positions within the		should specify the allocation and usage of bit positions within the
	unencoded field. Both sender and receiver will know of this		unencoded field. Unassigned and reserved bits in the unencoded field
	allocation so that they are implicitly aware of the width of the bit		will be treated as zeros by the SDNV encoding prior to transmission.
	field. Unassigned and reserved bits in the unencoded field will be
	treated as zeroes by the SDNV encoding prior to transmission.
	Assuming the bit positions are numbered starting from 0 at the least		Assuming the bit positions are numbered starting from 0 at the least
	significant bit position in the integer representation, then if		significant bit position in the integer representation, then if
	higher numbered positions in the field contain all zeroes, the		higher numbered positions in the field contain all zeros, the
	encoding process may not transmit these bits explicitly (e.g., if all		encoding process may not transmit these bits explicitly (e.g., if all
	the bit positions numbered 7 or higher are zeroes then the		the bit positions numbered 7 or higher are zeros then the transmitted
	transmitted SDNV can consist of just one octet). On reception the		SDNV can consist of just one octet). On reception the decoding
	decoding process will treat any untransmitted higher numbered bits as		process will treat any untransmitted higher numbered bits as zeros.
	zeroes.		To ensure correct operation of the protocol, the sender and receiver
			must have a consistent interpretation of the width of the bit-field.
			This can be achieved in various ways:
			o the bit-field width is implicitly defined by the version of the
			protocol in use in the sender and receiver,
			o sending the width of the bit-field explicitly in a separate item,
			o the higher numbered bits can be safely ignored by the receiver
			(e.g., because they represent optimizations), or
			o marking the highest numbered bit by prepending a 1 bit to the bit-
			field.
			The protocol specification must record how the consistent
			interpretation is achieved.
			The SDNV encoding technique is also known as Variable Byte Encoding
			(see Section 5.3.1 of [Manning09]) and is equivalent to Base-128
			Elias Gamma Encoding (see Section 5.3.2 of [Manning09] and Section
			3.5 of [Sayood02]). However the primary motivation for SDNVs is to
			provide an extensible protocol framework rather than optimal data
			compression which is the motivation behind the other uses of the
			technique. [Manning09] points out that the key feature of this
			encoding is that it is 'prefix free' meaning that no code is a prefix
			of any other, which an alternative way of expressing the self-
			delimiting property
	3. Basic Algorithms		3. Basic Algorithms
	This section describes some simple algorithms for creating and		This section describes some simple algorithms for creating and
	parsing SDNV fields. These may not be the most efficient algorithms		parsing SDNV fields. These may not be the most efficient algorithms
	possible, however, they are easy to read, understand, and implement.		possible, however, they are easy to read, understand, and implement.
	Appendix A contains Python source code implementing the routines		Appendix A contains Python source code implementing the routines
	described here.		described here. The algorithms presented here are convenient for
			converting between an internal data block and serialized data stream
			associated with a transmission device. Other approaches are possible
			with different efficiencies and trade-offs.
	3.1. Encoding Algorithm		3.1. Encoding Algorithm
	There is a very simple algorithm for the encoding operation that		There is a very simple algorithm for the encoding operation that
	converts a non-negative integer (value n, of length 1+floor(log n)		converts a non-negative integer (value n, of length 1+floor(log n)
	bits) into an SDNV. This algorithm takes n as its only argument and		bits) into an SDNV. This algorithm takes n as its only argument and
	returns a string of bytes:		returns a string of bytes:
	o (Initial Step) Set a variable X to a byte sharing the least		o (Initial Step) Set a variable X to a byte sharing the least
	significant 7 bits of n, and with 0 in the most significant bit,		significant 7 bits of n, and with 0 in the most significant bit,
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 47 ¶
	the expected length of the result and fill that buffer one byte at a		the expected length of the result and fill that buffer one byte at a
	time from the right end.		time from the right end.
	If, for some reason, an implementation requires an encoded SDNV to be		If, for some reason, an implementation requires an encoded SDNV to be
	some specific length (possibly related to a machine word), any		some specific length (possibly related to a machine word), any
	leftmost zero-padding included needs to properly set the high-order		leftmost zero-padding included needs to properly set the high-order
	bit in each byte of padding.		bit in each byte of padding.
	3.2. Decoding Algorithm		3.2. Decoding Algorithm
	Decoding SNDVs is a more difficult operation than encoding them, due		Decoding SDNVs is a more difficult operation than encoding them, due
	to the fact that no bound on the resulting value is known until the		to the fact that no bound on the resulting value is known until the
	SDNV is parsed, at which point the value itself is already known.		SDNV is parsed, at which point the value itself is already known.
	This means that if space is allocated for decoding the value of an		This means that if space is allocated for decoding the value of an
	SDNV into, it is never known whether this space will be overflowed		SDNV into, it is never known whether this space will be overflowed
	until it is 7 bits away from happening.		until it is 7 bits away from happening.
	(Initial Step) Set the result to 0. Set an index to the first byte		(Initial Step) Set the result to 0. Set an index to the first byte
	of the encoded SDNV.		of the encoded SDNV.
	(Recursion Step) Shift the result left 7 bits. Add the low-order 7		(Recursion Step) Shift the result left 7 bits. Add the low-order 7
	skipping to change at page 13, line 49 ¶		skipping to change at page 13, line 49 ¶
	| | | | | |		| | | | | |
	| 130 | N/A | 2^910 - 1 | N/A | 130 |		| 130 | N/A | 2^910 - 1 | N/A | 130 |
	| | | | | |		| | | | | |
	| 256 | N/A | 2^1792 - 1 | N/A | 256 |		| 256 | N/A | 2^1792 - 1 | N/A | 256 |
	+-------+---------------+-------------+---------------+-------------+		+-------+---------------+-------------+---------------+-------------+
	Table 1		Table 1
	In general, it seems like the most promising use of SDNVs may be to		In general, it seems like the most promising use of SDNVs may be to
	define the Length field of a TLV structure to be an SDNV whose value		define the Length field of a TLV structure to be an SDNV whose value
	is the length of the TLV's Value field. This leverages the strengths		is the length of the TLV's Value field. As previously discussed,
	of the SDNV format and limits the effects of its weaknesses.		this leverages the strengths of the SDNV format and limits the
			effects of its weaknesses.
	Another aspect of comparison between SDNVs and alternatives using		Another aspect of comparison between SDNVs and alternatives using
	fixed-length fields is the result of errors in transmission. Bit-		fixed-length fields is the result of errors in transmission. Bit-
	errors in an SDNV can result in either errors in the decoded value,		errors in an SDNV can result in either errors in the decoded value,
	or parsing errors in subsequent fields of the protocol. In fixed-		or parsing errors in subsequent fields of the protocol. In fixed-
	length fields, bit errors always result in errors to the decoded		length fields, bit errors always result in errors to the decoded
	value rather than parsing errors in subsequent fields. If the		value rather than parsing errors in subsequent fields. If the
	decoded values from either type of field encoding (SDNV or fixed-		decoded values from either type of field encoding (SDNV or fixed-
	length) are used as indexes, offsets, or lengths of further fields in		length) are used as indexes, offsets, or lengths of further fields in
	the protocol, similar failures result.		the protocol, similar failures result.
	skipping to change at page 17, line 16 ¶		skipping to change at page 17, line 16 ¶
	Scott Burleigh, Manikantan Ramadas, Michael Demmer, Stephen Farrell,		Scott Burleigh, Manikantan Ramadas, Michael Demmer, Stephen Farrell,
	and other members of the IRTF DTN Research Group contributed to the		and other members of the IRTF DTN Research Group contributed to the
	development and usage of SDNVs in DTN protocols. George Jones and		development and usage of SDNVs in DTN protocols. George Jones and
	Keith Scott from Mitre, Lloyd Wood, Gerardo Izquierdo, Joel Halpern,		Keith Scott from Mitre, Lloyd Wood, Gerardo Izquierdo, Joel Halpern,
	Peter TB Brett, Kevin Fall, and Elwyn Davies also contributed useful		Peter TB Brett, Kevin Fall, and Elwyn Davies also contributed useful
	comments on and criticisms of this document. DTNRG last call		comments on and criticisms of this document. DTNRG last call
	comments on the draft were sent to the mailing list by Lloyd Wood,		comments on the draft were sent to the mailing list by Lloyd Wood,
	Will Ivancic, Jim Wyllie, William Edwards, Hans Kruse, Janico		Will Ivancic, Jim Wyllie, William Edwards, Hans Kruse, Janico
	Greifenberg, Teemu Karkkainen, Stephen Farrell, and Scott Burleigh.		Greifenberg, Teemu Karkkainen, Stephen Farrell, and Scott Burleigh.
	Further constructive comments were incorporated from Dave Crocker.		Further constructive comments were incorporated from Dave Crocker,
			Lachlan Andrew and Michael Welzl.
	Work on this document was performed at NASA's Glenn Research Center,		Work on this document was performed at NASA's Glenn Research Center,
	in support of the NASA Space Communications Architecture Working		in support of the NASA Space Communications Architecture Working
	Group (SCAWG), NASA's Earth Science Technology Office (ESTO), and the		Group (SCAWG), NASA's Earth Science Technology Office (ESTO), and the
	FAA/Eurocontrol Future Communications Study (FCS) in the 2005-2007		FAA/Eurocontrol Future Communications Study (FCS) in the 2005-2007
	timeframe, while the editor was an employee of Verizon Federal		time frame, while the editor was an employee of Verizon Federal
	Network Systems.		Network Systems.
	8. Informative References		8. Informative References
	[ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1).		[ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1).
	Specification of Basic Notation", ISO/IEC 8824-1:2002,		Specification of Basic Notation", ISO/IEC 8824-1:2002,
	2002.		2002.
	[ASN1-BER]		[ASN1-BER]
	ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1).		ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1).
	skipping to change at page 18, line 34 ¶		skipping to change at page 18, line 34 ¶
	[I-D.hixie-thewebsocketprotocol]		[I-D.hixie-thewebsocketprotocol]
	Hickson, I., "The WebSocket protocol",		Hickson, I., "The WebSocket protocol",
	draft-hixie-thewebsocketprotocol-76 (work in progress),		draft-hixie-thewebsocketprotocol-76 (work in progress),
	May 2010.		May 2010.
	[IEN21] Cerf, V. and J. Postel, "Specification of Internetwork		[IEN21] Cerf, V. and J. Postel, "Specification of Internetwork
	Transmission Control Program: TCP Version 3", Internet		Transmission Control Program: TCP Version 3", Internet
	Experimental Note 21, January 1978.		Experimental Note 21, January 1978.
			[Manning09]
			Manning, c., Raghavan, P., and H. Schuetze, "Introduction
			to Information Retrieval", Cambridge University
			Press ISBN-13: 978-0521865715, 2009,
			<http://informationretrieval.org/>.
	[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission		[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission
	Protocol", RFC 713, April 1976.		Protocol", RFC 713, April 1976.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	September 1981.		September 1981.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, September 1981.		RFC 793, September 1981.
	[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions		[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
	skipping to change at page 20, line 5 ¶		skipping to change at page 19, line 24 ¶
	Specification", RFC 5050, November 2007.		Specification", RFC 5050, November 2007.
	[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider		[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
	Transmission Protocol - Motivation", RFC 5325,		Transmission Protocol - Motivation", RFC 5325,
	September 2008.		September 2008.
	[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider		[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
	Transmission Protocol - Specification", RFC 5326,		Transmission Protocol - Specification", RFC 5326,
	September 2008.		September 2008.
			[Sayood02]
			Sayood, K., "Lossless Data Compression", Academic
			Press ISBN-13: 978-0126208610, December 2002,
			<http://books.google.co.uk/books?id=LjQiGwyabVwC>.
	Appendix A. SNDV Python Source Code		Appendix A. SNDV Python Source Code
	# sdnv_decode() takes a string argument (s), which is assumed to be		# sdnv_decode() takes a string argument (s), which is assumed to be
	# an SDNV, and optionally a number (slen) for the maximum number of		# an SDNV, and optionally a number (slen) for the maximum number of
	# bytes to parse from the string. The function returns a pair of		# bytes to parse from the string. The function returns a pair of
	# the non-negative integer n that is the numeric value encoded in		# the non-negative integer n that is the numeric value encoded in
	# the SDNV, and integer that is the distance parsed into the input		# the SDNV, and integer that is the distance parsed into the input
	# string. If the slen argument is not given (or is not a non-zero		# string. If the slen argument is not given (or is not a non-zero
	# number) then, s is parsed up to the first byte whose high-order		# number) then, s is parsed up to the first byte whose high-order
	# bit is 0 -- the length of the SDNV portion of s does not have to		# bit is 0 -- the length of the SDNV portion of s does not have to
End of changes. 21 change blocks.
	40 lines changed or deleted		82 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/