< draft-irtf-dtnrg-sdnv-05.txt		draft-irtf-dtnrg-sdnv-06.txt >
	Network Working Group W. Eddy		Network Working Group W. Eddy
	Internet-Draft MTI Systems		Internet-Draft MTI Systems
	Intended status: Informational December 21, 2009		Intended status: Informational January 13, 2010
	Expires: June 24, 2010		Expires: July 17, 2010
	Using Self-Delimiting Numeric Values in Protocols		Using Self-Delimiting Numeric Values in Protocols
	draft-irtf-dtnrg-sdnv-05		draft-irtf-dtnrg-sdnv-06
	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 46 ¶		skipping to change at page 1, line 46 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 24, 2010.		This Internet-Draft will expire on July 17, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 3, line 12 ¶		skipping to change at page 3, line 12 ¶
	Appendix A. SNDV Python Source Code . . . . . . . . . . . . . . . 19		Appendix A. SNDV Python Source Code . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document is a product of the Internet Research Task Force (IRTF)		This document is a product of the Internet Research Task Force (IRTF)
	Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document		Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document
	has received review and support within the DTNRG, as discussed in the		has received review and support within the DTNRG, as discussed in the
	Acknowledgements section of this document.		Acknowledgements section of this document.
	This document begins by describing a common problem encountered in		This document begins by describing the drawbacks of using fixed-width
	network protocol engineering. It then provides some background on		protocol fields. It then provides some background on the Self-
	the Self-Delimiting Numeric Values (SDNVs) proposed for use in DTN		Delimiting Numeric Values (SDNVs) proposed for use in DTN protocols,
	protocols, and motivates their potential applicability in other		and motivates their potential applicability in other networking
	networking protocols. One example of SDNVs being used outside of the		protocols. One example of SDNVs being used outside of the DTN
	DTN protocols is in Hixie's Web Socket protocol		protocols is in Hixie's Web Socket protocol
	[I-D.hixie-thewebsocketprotocol], which includes a binary frame		[I-D.hixie-thewebsocketprotocol], which includes a binary frame
	length indicator field identical to an SDNV. The DTNRG has created		length indicator field identical to an SDNV. The DTNRG has created
	SDNVs to meet the challenges it attempts to solve, and it has been		SDNVs to meet the challenges it attempts to solve, and it has been
	noted that SDNVs closely resemble certain constructs within ASN.1 and		noted that SDNVs closely resemble certain constructs within ASN.1 and
	even older ITU protocols, so the problems are not new or unique to		even older ITU protocols, so the problems are not new or unique to
	DTN. SDNVs focus strictly on numeric values or bitstrings, while		DTN. SDNVs focus strictly on numeric values or bitstrings, while
	other mechanisms have been developed for encoding more complex data		other mechanisms have been developed for encoding more complex data
	structures, such as ASN.1 encoding rules, and Haverty's MSDTP		structures, such as ASN.1 encoding rules, and Haverty's MSDTP
	[RFC0713]. Because of this focus, SDNVs are can be quickly		[RFC0713]. Because of this focus, SDNVs are can be quickly
	implemented with only a small amount of code.		implemented with only a small amount of code.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	address length.		address length.
	TCP segments contain an advertised receive window field that is fixed		TCP segments contain an advertised receive window field that is fixed
	at 16 bits [RFC0793], encoding a maximum value of around 65		at 16 bits [RFC0793], encoding a maximum value of around 65
	kilobytes. The purpose of this value is to provide flow control, by		kilobytes. The purpose of this value is to provide flow control, by
	allowing a receiver to specify how many sent bytes its peer can have		allowing a receiver to specify how many sent bytes its peer can have
	outstanding (unacknowledged) at any time, thus allowing the receiver		outstanding (unacknowledged) at any time, thus allowing the receiver
	to limit its buffer size. As network speeds have grown by several		to limit its buffer size. As network speeds have grown by several
	orders of magnitude since TCP's inception, the combination of the 65		orders of magnitude since TCP's inception, the combination of the 65
	kilobyte maximum advertised window and long round-trip times		kilobyte maximum advertised window and long round-trip times
	prevented TCP senders from being able to acheive the high throughput		prevented TCP senders from being able to achieve the high throughput
	that the underlying network supported. This limitation was remedied		that the underlying network supported. This limitation was remedied
	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.
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 13 ¶
	avoiding fixed sizes that may not end up being appropriate. For		avoiding fixed sizes that may not end up being appropriate. For
	example, since LTP is intended primarily for use in long-delay		example, since LTP is intended primarily for use in long-delay
	interplanetary communications [RFC5325], where links may be fairly		interplanetary communications [RFC5325], where links may be fairly
	low in capacity, it is desirable to avoid the header overhead of		low in capacity, it is desirable to avoid the header overhead of
	routinely sending a 64-bit field where a 16-bit field would suffice.		routinely sending a 64-bit field where a 16-bit field would suffice.
	Since many of the nodes implementing LTP are expected to be beyond		Since many of the nodes implementing LTP are expected to be beyond
	the current range of human spaceflight, upgrading their on-board LTP		the current range of human spaceflight, upgrading their on-board LTP
	implementations to use longer values if the defined fields are found		implementations to use longer values if the defined fields are found
	to be too short would also be problematic. Furthermore, extensions		to be too short would also be problematic. Furthermore, extensions
	similar in mechanism to TCP's Window Scale option are unsuitable for		similar in mechanism to TCP's Window Scale option are unsuitable for
	use in DTN protocols since due to high delays, DTN protocols must		use in DTN protocols since, due to high delays, DTN protocols must
	avoid handshaking and configuration parameter negotiation to the		avoid handshaking and configuration parameter negotiation to the
	greatest extent possible. All of these reasons make the choice of		greatest extent possible. All of these reasons make the choice of
	SDNVs for use in DTN protocols attractive.		SDNVs for use in DTN protocols attractive.
	1.3. SDNV Usage		1.3. SDNV Usage
	In short, an SDNV is simply a way of representing non-negative		In short, an SDNV is simply a way of representing non-negative
	integers (both positive integers of arbitrary magnitude and 0),		integers (both positive integers of arbitrary magnitude and 0),
	without expending much unneccessary space. This definition allows		without expending much unnecessary space. This definition allows
	SDNVs to represent many common protocol header fields, such as:		SDNVs to represent many common protocol header fields, such as:
	o Random identification fields as used in the IPsec Security		o Random identification fields as used in the IPsec Security
	Parameters Index or in IP headers for fragment reassembly (Note:		Parameters Index or in IP headers for fragment reassembly (Note:
	the 16-bit IP ID field for fragment reassembly was recently found		the 16-bit IP ID field for fragment reassembly was recently found
	to be too short in some environments [RFC4963]),		to be too short in some environments [RFC4963]),
	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.		o Etc.
	As any bit-string can be interpreted as an unsigned integer, SDNVs		As any bit-field can be interpreted as an unsigned integer, SDNVs can
	can also encode arbitrary-length bit strings, including bit-strings		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-strings, 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
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 25 ¶
	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
	facing the DTNRG.		facing the DTNRG.
	Many protocols use a Type-Length-Value method for encoding variable		Many protocols use a Type-Length-Value method for encoding variable
	length strings (e.g. TCP's options format, or many of the fields in		length fields (e.g. TCP's options format, or many of the fields in
	IKEv2). An SDNV is equivalent to combining the length and value		IKEv2). An SDNV is equivalent to combining the length and value
	portions of this type of field, with the overhead of the length		portions of this type of field, with the overhead of the length
	portion amortized out over the bytes of the value. The penalty paid		portion amortized out over the bytes of the value. The penalty paid
	for this in an SDNV may be several extra bytes for long values (e.g.		for this in an SDNV may be several extra bytes for long values (e.g.
	1024 bit RSA keys). See Section 4 for further discussion and a		1024 bit RSA keys). See Section 4 for further discussion and a
	comparison.		comparison.
	As is shown in later sections, for large values, the current SDNV		As is shown in later sections, for large values, the current SDNV
	scheme is fairly inefficient in terms of space (1/8 of the bits are		scheme is fairly inefficient in terms of space (1/8 of the bits are
	overhead) and not particularly easy to encode/decode in comparison to		overhead) and not particularly easy to encode/decode in comparison to
	alternatives. The best use of SDNVs may often be to define the		alternatives. The best use of SDNVs may often be to define the
	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
	An early definition of the SDNV format bore resemblance to the ASN.1		Early in the work of the DTNRG, it was agreed that the properties of
	[ASN1] Basic Encoding Rules (BER) [ASN1-BER] for lengths (Section		an SDNV were useful for DTN protocols. The exact SDNV format used by
	8.1.3 of X.690). The current SDNV format is the one used by ASN.1		the DTNRG evolved somewhat over time before the publication of the
	BER for encoding tag identifiers greater than or equal to 31 (Section		initial RFCs on LTP and the BP. An ealier version bore resemblance
	8.1.2.4.2 of X.690). A comparison between the current SDNV format		to the ASN.1 [ASN1] Basic Encoding Rules (BER) [ASN1-BER] for lengths
	and the early SDNV format is made in Section 4.		(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
			(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.
	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 signifcant bit.
	When transmitted, the bits are encoded into a series of bytes. The		If the bitstring's length is not a multiple of 7, then the string is
	most significant bit of each byte specifies whether it is the final		left-padded with zeros. When transmitted, the bits are encoded into
	byte of the encoded value (when it holds a 0), or not (when it holds		a series of bytes. The low-order 7 bits of each byte in the encoded
	a 1). The remaining 7 bits of each byte in the wire format are taken		format are taken left-to-right from the integer's bitstring
	in order from the integer's bitstring representation. If the		representation. The most significant bit of each byte specifies
	bitstring's length is not a multiple of 7, then the string is left-		whether it is the final byte of the encoded value (when it holds a
	padded with 0s.		0), or not (when it holds a 1).
	For example:		For example:
	o 1 (decimal) is represented by the bitstring "0000001" and encoded		o 1 (decimal) is represented by the bitstring "0000001" and encoded
	as the single byte 0x01 (in hexadecimal)		as the single byte 0x01 (in hexadecimal)
	o 128 is represented by the bitstring "10000001 00000000" and		o 128 is represented by the bitstring "10000001 00000000" and
	encoded as the bytes 0x81 followed by 0x00.		encoded as the bytes 0x81 followed by 0x00.
	o Other values can be found in the test vectors of the source code		o Other values can be found in the test vectors of the source code
	skipping to change at page 8, line 16 ¶		skipping to change at page 8, line 16 ¶
	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.
	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_2 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 the return value 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,
	but do not return yet. Right shift n 7 bits and use this as the		and a variable Y to n, right-shifted by 7 bits.
	new n value. If implemented using call-by-reference rather than
	call-by-value, make a copy of n for local use at the start of the
	function call.
	o (Recursion Step) If n == 0, return. Otherwise, take the byte		o (Recursion Step) If Y == 0, return X. Otherwise, set Z to the
	0x80, and bitwise-or it with the 7 least significant bits of n.		bitwise-or of 0x80 with the 7 least significant bits of Y, and
	Set the return value to this result with the previous return		append Z to X. Right-shift Y by 7 bits and repeat the Recursion
	string appended to it. Shift n right 7 bits again. Repeat		Step.
	Recursion Step.
	This encoding algorithm can easily be seen to have time complexity of		This encoding algorithm has time complexity of O(log n), since it
	O(log_2 n), since it takes a number of steps equal to ceil(n/7), and		takes a number of steps equal to ceil(n/7), and no additional space
	no additional space beyond the size of the result (8/7 log_2 n) is		beyond the size of the result (8/7 log n) is required. One aspect of
	required. One aspect of this algorithm is that it assumes strings		this algorithm is that it assumes strings can be efficiently appended
	can be efficiently appended to new bytes. One way to implement this		to new bytes. One way to implement this is to allocate a buffer for
	is to allocate a buffer for the expected length of the result and		the expected length of the result and fill that buffer one byte at a
	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 SNDVs 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 a pointer to the beginning		(Initial Step) Set the result to 0. Set an index to the first byte
	of the SDNV.		of the encoded SDNV.
	(Recursion Step) Shift the result left 7 bits. Add the lower 7 bits		(Recursion Step) Shift the result left 7 bits. Add the low-order 7
	of the value at the pointer to the result. If the high-order bit		bits of the value at the index to the result. If the high-order bit
	under the pointer is a 1, move the pointer right one byte and repeat		under the pointer is a 1, advance the index by one byte within the
	the Recursion Step, otherwise return the current value of the result.		encoded SDNV and repeat the Recursion Step, otherwise return the
			current value of the result.
	This decoding algorithm takes no more additional space than what is		This decoding algorithm takes no more additional space than what is
	required for the result (7/8 the length of the SDNV) and the pointer.		required for the result (7/8 the length of the SDNV) and the pointer.
	The complication is that before the result can be left-shifted in the		The complication is that before the result can be left-shifted in the
	Recursion Step, an implementation needs to first make sure that this		Recursion Step, an implementation needs to first make sure that this
	won't cause any bits to be lost, and re-allocate a larger piece of		won't cause any bits to be lost, and re-allocate a larger piece of
	memory for the result, if required. The pure time complexity is the		memory for the result, if required. The pure time complexity is the
	same as for the encoding algorithm given, but if re-allocation is		same as for the encoding algorithm given, but if re-allocation is
	needed due to the inability to predict the size of the result,		needed due to the inability to predict the size of the result,
	decoding may be slower.		decoding may be slower.
	skipping to change at page 19, line 7 ¶		skipping to change at page 19, line 7 ¶
	[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,
	March 2008.		March 2008.
	Appendix A. SNDV Python Source Code		Appendix A. SNDV Python Source Code
	# sdnv_decode() takes a string argument s, which is assumed to be an		# sdnv_decode() takes a string argument (s), which is assumed to be
	# SDNV. The function returns a pair of the non-negative integer n		# an SDNV, and optionally a number (slen) for the maximum number of
	# that is the numeric value encoded in the SDNV, and and integer l		# bytes to parse from the string. The function returns a pair of
	# that is the distance parsed into the input string. If the slen		# the non-negative integer n that is the numeric value encoded in
	# argument is not given (or is not a non-zero number) then, s is		# the SDNV, and integer that is the distance parsed into the input
	# parsed up to the first byte whose high-order bit is 0 -- the		# string. If the slen argument is not given (or is not a non-zero
	# length of the SDNV portion of s does not have to be pre-computed		# number) then, s is parsed up to the first byte whose high-order
	# by calling code. If the slen argument is given as a non-zero		# bit is 0 -- the length of the SDNV portion of s does not have to
	# value, then slen bytes of s are parsed. The value for n of -1 is		# be pre-computed by calling code. If the slen argument is given
	# returned for any type of parsing error.		# as a non-zero value, then slen bytes of s are parsed. The value
			# for n of -1 is returned for any type of parsing error.
	#		#
	# NOTE: In python, integers can be of arbitrary size. In other		# NOTE: In python, integers can be of arbitrary size. In other
	# languages, such as C, SDNV-parsing routines should take		# languages, such as C, SDNV-parsing routines should take
	# precautions to avoid overflow (e.g. by using the Gnu MP library,		# precautions to avoid overflow (e.g. by using the Gnu MP library,
	# or similar).		# or similar).
	#		#
	def sdnv_decode(s, slen=0):		def sdnv_decode(s, slen=0):
	n = long(0)		n = long(0)
	for i in range(0, len(s)):		for i in range(0, len(s)):
	v = ord(s[i])		v = ord(s[i])
	skipping to change at page 19, line 52 ¶		skipping to change at page 20, line 4 ¶
	flag = 0		flag = 0
	done = False		done = False
	while not done:		while not done:
	# encode lowest 7 bits from n		# encode lowest 7 bits from n
	newbits = n & 0x7F		newbits = n & 0x7F
	n = n>>7		n = n>>7
	r = chr(newbits + flag) + r		r = chr(newbits + flag) + r
	if flag == 0:		if flag == 0:
	flag = 0x80		flag = 0x80
	if n == 0:		if n == 0:
	done = True
			done = True
	return r		return r
	# test cases from LTP and BP internet-drafts, only print failures		# test cases from LTP and BP internet-drafts, only print failures
	def sdnv_test():		def sdnv_test():
	tests = [(0xABC, chr(0x95) + chr(0x3C)),		tests = [(0xABC, chr(0x95) + chr(0x3C)),
	(0x1234, chr(0xA4) + chr (0x34)),		(0x1234, chr(0xA4) + chr (0x34)),
	(0x4234, chr(0x81) + chr(0x84) + chr(0x34)),		(0x4234, chr(0x81) + chr(0x84) + chr(0x34)),
	(0x7F, chr(0x7F))]		(0x7F, chr(0x7F))]
	for tp in tests:		for tp in tests:
End of changes. 23 change blocks.
	66 lines changed or deleted		67 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/