Internet Research Task Force (IRTF) W. Eddy
Request for Comments: 6256 MTI Systems
Category: Informational E. Davies
ISSN: 2070-1721 Folly Consulting
May 2011
Internet Research Task Force (IRTF) W. Eddy
Request for Comments: 6256 MTI Systems
Category: Informational E. Davies
ISSN: 2070-1721 Folly Consulting
May 2011
Using Self-Delimiting Numeric Values in Protocols
在协议中使用自定界数值
Abstract
摘要
Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary-length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
自定界数值（SDNV）最近被作为一种字段类型引入到提出的延迟容忍网络协议中。SDNVs以最小开销编码任意长度的非负整数或任意长度的位字符串。它们旨在在不牺牲经济性的情况下提供协议灵活性，并帮助开发中的未来验证协议。本文档描述了SDNV编码和解码的格式和算法，以及实现和使用说明。本文件是耐延迟网络研究小组的产品，该小组已对其进行了审查。没有人反对将其作为RFC出版。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。该RFC代表了互联网研究任务组（IRTF）的延迟容忍网络研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6256.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6256.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Problems with Fixed-Value Fields ...........................3
1.2. SDNVs for DTN Protocols ....................................4
1.3. SDNV Usage .................................................5
2. Definition of SDNVs .............................................6
3. Basic Algorithms ................................................8
3.1. Encoding Algorithm .........................................8
3.2. Decoding Algorithm .........................................9
3.3. Limitations of Implementations ............................10
4. Comparison to Alternatives .....................................10
5. Security Considerations ........................................13
6. Acknowledgements ...............................................13
7. Informative References .........................................14
Appendix A. SDNV Python Source Code ...............................15
1. Introduction ....................................................2
1.1. Problems with Fixed-Value Fields ...........................3
1.2. SDNVs for DTN Protocols ....................................4
1.3. SDNV Usage .................................................5
2. Definition of SDNVs .............................................6
3. Basic Algorithms ................................................8
3.1. Encoding Algorithm .........................................8
3.2. Decoding Algorithm .........................................9
3.3. Limitations of Implementations ............................10
4. Comparison to Alternatives .....................................10
5. Security Considerations ........................................13
6. Acknowledgements ...............................................13
7. Informative References .........................................14
Appendix A. SDNV Python Source Code ...............................15
This document is a product of the Internet Research Task Force (IRTF) Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document has received review and support within the DTNRG, as discussed in the Acknowledgements section of this document.
本文件是互联网研究任务组（IRTF）延迟容忍网络（DTN）研究小组（DTNRG）的产品。如本文件确认部分所述，本文件已得到DTNRG的审查和支持。
This document begins by describing the drawbacks of using fixed-width protocol fields. It then provides some background on the Self-Delimiting Numeric Values (SDNVs) proposed for use in DTN protocols, and motivates their potential applicability in other networking protocols. The DTNRG has created SDNVs to meet the challenges it attempts to solve, and it has been noted that SDNVs closely resemble certain constructs within ASN.1 and even older ITU protocols, so the problems are not new or unique to DTN. SDNVs focus strictly on numeric values or bitstrings, while other mechanisms have been developed for encoding more complex data structures, such as ASN.1
本文档首先描述使用固定宽度协议字段的缺点。然后，它提供了一些关于在DTN协议中使用的自定界数值（SDNV）的背景，并激发了它们在其他网络协议中的潜在适用性。DTNRG创建了SDNV以应对其试图解决的挑战，并且已经注意到SDNV与ASN.1甚至更旧的ITU协议中的某些结构非常相似，因此这些问题不是新的，也不是DTN独有的。SDNV严格关注数值或位字符串，而开发了其他机制来编码更复杂的数据结构，如ASN.1
encoding rules and Haverty's Message Services Data Transmission Protocol (MSDTP) [RFC0713]. Because of this focus, SDNVs can be quickly implemented with only a small amount of code.
编码规则和Haverty的消息服务数据传输协议（MSDTP）[RFC0713]。由于这一重点，SDNV只需少量代码即可快速实现。
SDNVs are tersely defined in both the Bundle Protocol [RFC5050] and Licklider Transmission Protocol (LTP) [RFC5326] specifications, due to the flow of document production in the DTNRG. This document clarifies and further explains the motivations and engineering decisions behind SDNVs.
由于DTNRG中的文档生产流程，捆绑协议[RFC5050]和利克利德传输协议（LTP）[RFC5326]规范中都对SDNV进行了简要定义。本文件澄清并进一步解释了SDNV背后的动机和工程决策。
Protocol designers commonly face an optimization problem in determining the proper size for header fields. There is a strong desire to keep fields as small as possible, in order to reduce the protocol's overhead and also allow for fast processing. Since protocols can be used for many years (even decades) after they are designed, and networking technology has tended to change rapidly, it is not uncommon for the use, deployment, or performance of a particular protocol to be limited or infringed upon by the length of some header field being too short. Two well-known examples of this phenomenon are the TCP-advertised receive window and the IPv4 address length.
协议设计者在确定头字段的适当大小时通常面临一个优化问题。人们强烈希望保持字段尽可能小，以减少协议的开销并允许快速处理。由于协议在设计之后可以使用很多年（甚至几十年），并且网络技术趋向于快速变化，因此由于某些报头字段的长度太短而限制或破坏特定协议的使用、部署或性能的情况并不少见。这种现象的两个众所周知的例子是TCP广告接收窗口和IPv4地址长度。
TCP segments contain an advertised receive window field that is fixed at 16 bits [RFC0793], encoding a maximum value of around 65 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 outstanding (unacknowledged) at any time, thus allowing the receiver to limit its buffer size. As network speeds have grown by several orders of magnitude since TCP's inception, the combination of the 65 kilobyte maximum advertised window and long round-trip times prevented TCP senders from being able to achieve the high throughput that the underlying network supported. This limitation was remedied through the use of the Window Scale option [RFC1323], which provides a multiplier for the advertised window field. However, the Window Scale multiplier is fixed for the duration of the connection, requires support from each end of a TCP connection, and limits the precision of the advertised receive window, so this is certainly a less-than-ideal solution. Because of the field width limit in the original design however, the Window Scale is necessary for TCP to reach high sending rates.
TCP段包含一个广告接收窗口字段，该字段固定为16位[RFC0793]，编码的最大值约为65 KB。此值的目的是通过允许接收方指定其对等方在任何时候可以有多少未确认的发送字节来提供流控制，从而允许接收方限制其缓冲区大小。自从TCP诞生以来，网络速度已经增长了好几个数量级，65 KB的最大广告窗口和较长的往返时间的组合使得TCP发送者无法实现底层网络支持的高吞吐量。此限制通过使用窗口比例选项[RFC1323]进行修正，该选项为播发的窗口字段提供乘数。但是，窗口比例乘数在连接期间是固定的，需要TCP连接两端的支持，并且限制了播发接收窗口的精度，因此这肯定不是理想的解决方案。然而，由于原始设计中的字段宽度限制，窗口比例对于TCP达到高发送速率是必要的。
An IPv4 address is fixed at 32 bits [RFC0791] (as a historical note, an early version of the IP header format specification in [IEN21] used variable-length addresses in multiples of 8 bits up to 120 bits). Due to the way that subnetting and assignment of address blocks was performed, the number of IPv4 addresses has been seen as a
IPv4地址固定为32位[RFC0791]（作为历史记录，早期版本的[IEN21]中的IP报头格式规范使用8位到120位的倍数可变长度地址）。由于执行子网和地址块分配的方式，IPv4地址的数量被视为
limit to the growth of the Internet [Hain05]. Two divergent paths to solve this problem have been the use of Network Address Translators (NATs) and the development of IPv6. NATs have caused a number of other issues and problems [RFC2993], leading to increased complexity and fragility, as well as forcing workarounds to be engineered for many other protocols to function within a NATed environment. The IPv6 solution's transitional work has been underway for several years, but has still only just begun to have visible impact on the global Internet.
限制互联网的发展[Hain05]。解决这个问题的两种不同途径是使用网络地址转换器（NAT）和开发IPv6。NAT引发了许多其他问题[RFC2993]，导致复杂性和脆弱性的增加，并迫使为许多其他协议设计解决方案，以在NAT环境中运行。IPv6解决方案的过渡工作已经进行了几年，但对全球互联网的影响才刚刚开始。
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 good idea at the time. The fields were more than big enough for the originally perceived usage of the protocols, and yet were small enough to allow the headers to remain compact and relatively easy and efficient to parse on machines of the time. The fixed sizes that were defined represented a trade-off between the scalability of the protocol versus the overhead and efficiency of processing. In both cases, these engineering decisions turned out to be painfully restrictive in the longer term.
当然，在TCP接收窗口和IPv4地址长度的情况下，设计者选择的字段大小在当时似乎是个好主意。这些字段足够大，可以满足最初对协议的使用，但也足够小，可以使头文件保持紧凑，并在当时的机器上相对容易和高效地进行解析。定义的固定大小表示协议的可伸缩性与处理的开销和效率之间的权衡。在这两种情况下，从长远来看，这些工程决策都是痛苦的限制。
In specifications for the DTN Bundle Protocol (BP) [RFC5050] and Licklider Transmission Protocol (LTP) [RFC5326], SDNVs have been used for several fields including identifiers, payload/header lengths, and serial (sequence) numbers. SDNVs were developed for use in these types of fields, to avoid sending more bytes than needed, as well as avoiding fixed sizes that may not end up being appropriate. For example, since LTP is intended primarily for use in long-delay interplanetary communications [RFC5325], where links may be fairly 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. Since many of the nodes implementing LTP are expected to be beyond the current range of human spaceflight, upgrading their on-board LTP implementations to use longer values if the defined fields are found to be too short would also be problematic. Furthermore, extensions similar in mechanism to TCP's Window Scale option are unsuitable for use in DTN protocols since, due to high delays, DTN protocols must avoid handshaking and configuration parameter negotiation to the greatest extent possible. All of these reasons make the choice of SDNVs for use in DTN protocols attractive.
在DTN捆绑协议（BP）[RFC5050]和利克利德传输协议（LTP）[RFC5326]的规范中，SDNV已用于多个字段，包括标识符、有效负载/报头长度和序列号。SDNV是为在这些类型的字段中使用而开发的，以避免发送超过需要的字节，并避免最终可能不合适的固定大小。例如，由于LTP主要用于长延迟星际通信[RFC5325]，其中链路的容量可能相当低，因此希望避免常规发送16位字段就足够的64位字段的报头开销。由于实现LTP的许多节点预计将超出人类航天的当前范围，因此，如果发现定义的字段太短，则升级其机载LTP实现以使用更长的值也会有问题。此外，在机制上类似于TCP窗口缩放选项的扩展不适合在DTN协议中使用，因为由于高延迟，DTN协议必须尽可能避免握手和配置参数协商。所有这些原因使得在DTN协议中选择SDNV具有吸引力。
In short, an SDNV is simply a way of representing non-negative integers (both positive integers of arbitrary magnitude and 0), without expending much unnecessary space. This definition allows SDNVs to represent many common protocol header fields, such as:
简而言之，SDNV只是表示非负整数（任意大小的正整数和0）的一种方式，而不需要花费太多不必要的空间。此定义允许SDNV表示许多常见的协议头字段，例如：
o Random identification fields as used in the IPsec Security Parameters Index or in IP headers for fragment reassembly (Note: the 16-bit IP ID field for fragment reassembly was recently found to be too short in some environments [RFC4963]).
o IPsec安全参数索引或用于片段重组的IP头中使用的随机标识字段（注意：最近发现用于片段重组的16位IP ID字段在某些环境中太短[RFC4963]）。
o Sequence numbers as in TCP or the Stream Control Transmission Protocol (SCTP).
o TCP或流控制传输协议（SCTP）中的序列号。
o Values used in cryptographic algorithms such as RSA keys, Diffie-Hellman key agreement, or coordinates of points on elliptic curves.
o 密码算法中使用的值，如RSA密钥、Diffie-Hellman密钥协议或椭圆曲线上点的坐标。
o Message lengths as used in file transfer protocols.
o 文件传输协议中使用的消息长度。
o Nonces and cookies.
o 糖果和饼干。
As any bitfield can be interpreted as an unsigned integer, SDNVs can also encode arbitrary-length bitfields, including bitfields representing signed integers or other data types; however, this document assumes SDNV encoding and decoding in terms of unsigned integers. Implementations may differ in the interface that they provide to SDNV encoding and decoding functions, in terms of whether the values are numeric, bitfields, etc.; this detail does not alter the representation or algorithms described in this document.
由于任何位字段都可以解释为无符号整数，SDNV还可以对任意长度的位字段进行编码，包括表示有符号整数或其他数据类型的位字段；然而，本文档假定SDNV编码和解码是无符号整数。在值是否为数字、位字段等方面，实现可能在它们提供给SDNV编码和解码功能的接口上有所不同。；此细节不会改变本文档中描述的表示或算法。
The use of SDNVs rather than fixed-length fields gives protocol designers the ability to ameliorate the consequences of making difficult-to-reverse field-sizing decisions, as the SDNV format grows and shrinks depending on the particular value encoded. SDNVs do not necessarily provide optimal encodings for values of any particular length; however, they allow protocol designers to avoid potential blunders in assigning fixed lengths and remove the complexity involved with either negotiating field lengths or constructing protocol extensions. However, if SDNVs are used to encode bitfields, it is essential that the sender and receiver have a consistent interpretation of the decoded value. This is discussed further in Section 2.
使用SDNV而不是固定长度字段使协议设计人员能够改善做出难以逆转的字段大小决定的后果，因为SDNV格式根据编码的特定值增长和收缩。SDNV不一定为任何特定长度的值提供最佳编码；然而，它们允许协议设计者避免在分配固定长度时可能出现的错误，并消除协商字段长度或构造协议扩展所涉及的复杂性。但是，如果使用SDNV对位字段进行编码，则发送方和接收方对解码值的解释必须一致。这将在第2节中进一步讨论。
To our knowledge, at this time, no IETF transport or network-layer 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
据我们所知，目前还没有设计用于DTN域之外的IETF传输或网络层协议提议使用SDNV；但是，没有内在的理由不更多地使用SDNV
broadly in the future. The two examples cited here, of fields that have proven too small in general Internet protocols, are only a small sampling of the much larger set of similar instances that the authors can think of. Outside the Internet protocols, within ASN.1 and previous ITU protocols, constructs very similar to SDNVs have been used for many years due to engineering concerns very similar to those facing the DTNRG.
大体上，在未来。这里引用的两个例子，在一般互联网协议中被证明太小的领域，只是作者可以想到的更大的一组类似实例的一个小样本。在互联网协议之外，在ASN.1和以前的ITU协议中，由于与DTNRG面临的工程问题非常相似，因此多年来一直使用与SDNV非常相似的结构。
Many protocols use a Type-Length-Value method for encoding variable-length fields (e.g., TCP's options format or many of the fields in the Internet Key Exchange Protocol version 2 (IKEv2)). An SDNV is equivalent to combining the length and value portions of this type of field, with the overhead of the length 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., 1024-bit RSA keys). See Section 4 for further discussion and a comparison.
许多协议使用类型长度值方法来编码可变长度字段（例如，TCP的选项格式或Internet密钥交换协议版本2（IKEv2）中的许多字段）。SDNV相当于组合此类字段的长度和值部分，长度部分的开销在值的字节上摊销。在SDNV中为此支付的罚金可能是长值（例如1024位RSA密钥）的几个额外字节。有关进一步的讨论和比较，请参见第4节。
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 overhead) and not particularly easy to encode/decode in comparison to 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 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 extensibility that using SDNVs grants.
如后面部分所示，对于大值，当前的SDNV方案在空间方面相当低效（1/8位是开销），并且与备选方案相比不太容易编码/解码。SDNV的最佳用途通常是将TLV结构的长度字段定义为SDNV，其值为TLV值字段的长度。通过这种方式，可以避免强制将大量数字直接编码为SDNV，同时保留使用SDNV授予的可扩展性。
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 the DTNRG evolved somewhat over time before the publication of the initial RFCs on LTP and BP. An earlier version (see the initial version of LTP Internet Draft [BRF04]) bore a resemblance to the ASN.1 [ASN1] Basic Encoding Rules (BER) [X.690] for lengths (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.
在DTNRG的早期工作中，人们一致认为SDNV的属性对于DTN协议是有用的。在LTP和BP上发布初始RFC之前，DTNRG使用的确切SDNV格式随着时间的推移有所变化。早期版本（参见LTP互联网草案[BRF04]的初始版本）与ASN.1[ASN1]基本编码规则（BER）[X.690]的长度相似（X.690的第8.1.3节）。当前SDNV格式是ASN.1 BER用于编码大于或等于31的标签标识符的格式（X.690第8.1.2.4.2节）。第4节对当前SDNV格式和早期SDNV格式进行了比较。
The format currently used is very simple. Before encoding, an integer is represented as a left-to-right bitstring beginning with 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 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 format are taken left-to-right from the integer's bitstring
目前使用的格式非常简单。编码之前，整数表示为从左到右的位字符串，从其最高有效位开始，以其最低有效位结束。如果该位字符串的长度不是7的倍数，则该字符串用零填充。传输时，位被编码成一系列字节。编码格式中每个字节的低阶7位从整数的位字符串从左到右取
representation. The most significant bit of each byte specifies whether it is the final byte of the encoded value (when it holds a 0), or not (when it holds a 1).
代表性。每个字节的最高有效位指定它是编码值的最后一个字节（当它包含0时），还是不是（当它包含1时）。
For example:
例如：
o 1 (decimal) is represented by the bitstring "0000001" and encoded as the single byte 0x01 (in hexadecimal).
o 1（十进制）由位字符串“0000001”表示，并编码为单字节0x01（十六进制）。
o 128 is represented by the bitstring "10000001 00000000" and encoded as the bytes 0x81 followed by 0x00.
o 128由位字符串“10000001 00000000”表示，编码为字节0x81，后跟0x00。
o Other values can be found in the test vectors of the source code in Appendix A.
o 其他值可在附录A中源代码的测试向量中找到。
To be perfectly clear, and avoid potential interoperability issues (as have occurred with ASN.1 BER time values), we explicitly state two considerations regarding zero-padding. (1) When encoding SDNVs, any leading (most significant) zero bits in the input number might be discarded by the SDNV encoder. Protocols that use SDNVs should not rely on leading-zeros being retained after encoding and decoding operations. (2) When decoding SDNVs, the relevant number of leading 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 order to not change the value of the number. Protocols using SDNVs should consider situations where lost zero-padding may be problematic.
为了非常清楚，并避免潜在的互操作性问题（如ASN.1 BER时间值），我们明确说明了关于零填充的两个注意事项。（1） 编码SDNV时，SDNV编码器可能会丢弃输入编号中的任何前导（最高有效）零位。使用SDNV的协议不应依赖于编码和解码操作后保留的前导零。（2） 在解码SDNV时，可能会添加填充到机器字或其他自然数据单元所需的相关前导零数。为了不改变数字的值，将其置于最有效的位置。使用SDNVS的协议应该考虑丢失零填充的情况可能是有问题的。
The issues of zero-padding are particularly relevant where an SDNV is being used to represent a bitfield to be transmitted by a protocol. The specification of the protocol and any associated IANA registry should specify the allocation and usage of bit positions within the unencoded field. Unassigned and reserved bits in the unencoded field will be treated as zeros by the SDNV encoding prior to transmission. Assuming the bit positions are numbered starting from 0 at the least significant bit position in the integer representation, then if higher-numbered positions in the field contain all zeros, the encoding process may not transmit these bits explicitly (e.g., if all the bit positions numbered 7 or higher are zeros, then the transmitted SDNV can consist of just one octet). On reception, the decoding process will treat any untransmitted higher-numbered bits as zeros. To ensure correct operation of the protocol, the sender and receiver must have a consistent interpretation of the width of the bitfield. This can be achieved in various ways:
在使用SDNV表示要通过协议传输的位字段的情况下，补零问题尤其相关。协议规范和任何相关IANA注册表应规定未编码字段中位位置的分配和使用。在传输之前，SDNV编码将未编码字段中的未分配和保留位视为零。假设位位置从整数表示中最低有效位位置的0开始编号，则如果字段中编号较高的位置包含所有零，则编码过程可能不会显式传输这些位（例如，如果编号为7或更高的所有位位置均为零，则传输的SDNV只能由一个八位字节组成）。在接收时，解码过程会将任何未传输的高位视为零。为确保协议的正确运行，发送方和接收方必须对位字段的宽度有一致的解释。这可以通过多种方式实现：
o the bitfield width is implicitly defined by the version of the protocol in use in the sender and receiver,
o 位域宽度由发送方和接收方使用的协议版本隐式定义，
o sending the width of the bitfield explicitly in a separate item,
o 在单独的项中显式发送位字段的宽度，
o the higher-numbered bits can be safely ignored by the receiver (e.g., because they represent optimizations), or
o 接收器可以安全地忽略编号较高的位（例如，因为它们代表优化），或者
o marking the highest-numbered bit by prepending a '1' bit to the bitfield.
o 通过在位字段前加一个“1”位来标记编号最高的位。
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 is an alternative way of expressing the self-delimiting property.
SDNV编码技术也称为可变字节编码（见[Manning09]第5.3.1节），相当于Base-128 Elias Gamma编码（见[Manning09]第5.3.2节和[Sayood02]第3.5节）。然而，SDNVs的主要动机是提供可扩展的协议框架，而不是优化数据压缩，这是该技术其他用途背后的动机。[Manning09]指出，这种编码的关键特征是“无前缀”，意思是没有任何代码是任何其他代码的前缀，这是表示自定界属性的另一种方式。
This section describes some simple algorithms for creating and parsing SDNV fields. These may not be the most efficient algorithms possible, however, they are easy to read, understand, and implement. Appendix A contains Python source code implementing the routines 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.
本节介绍一些用于创建和解析SDNV字段的简单算法。这些可能不是最有效的算法，但是，它们易于阅读、理解和实现。附录A包含实现此处所述例程的Python源代码。这里介绍的算法便于在内部数据块和与传输设备相关联的序列化数据流之间进行转换。其他方法可能具有不同的效率和权衡。
There is a very simple algorithm for the encoding operation that 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 returns a string of bytes:
编码操作有一个非常简单的算法，它将非负整数（值n，长度为1+floor（logn）位）转换为SDNV。此算法将n作为其唯一参数，并返回一个字节字符串：
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, and a variable Y to n, right-shifted by 7 bits.
o （初始步骤）将变量X设置为共享n的最低有效7位的字节，最高有效位为0，变量Y设置为n，右移7位。
o (Recursion Step) If Y == 0, return X. Otherwise, set Z to the bitwise-or of 0x80 with the 7 least significant bits of Y, and append Z to X. Right-shift Y by 7 bits and repeat the Recursion Step.
o （递归步骤）如果Y==0，则返回X。否则，将Z设置为0x80的按位or，其中7个最低有效位为Y，并将Z附加到X。将Y右移7位，然后重复递归步骤。
This encoding algorithm has a time complexity of O(log n), since it takes a number of steps equal to ceil(n/7), and no additional space beyond the size of the result (8/7 log n) is required. One aspect of this algorithm is that it assumes strings can be efficiently appended to new bytes. One way to implement this is to allocate a buffer for the expected length of the result and fill that buffer one byte at a time from the right end.
此编码算法的时间复杂度为O（logn），因为它需要的步骤数等于ceil（n/7），并且不需要超出结果大小（8/7logn）的额外空间。该算法的一个方面是假设字符串可以有效地追加到新字节。实现这一点的一种方法是为结果的预期长度分配一个缓冲区，并从右端一次填充一个字节。
If, for some reason, an implementation requires an encoded SDNV to be some specific length (possibly related to a machine word), any leftmost zero-padding included needs to properly set the high-order bit in each byte of padding.
如果出于某种原因，一个实现要求编码的SDNV为某个特定长度（可能与机器字相关），则包含的任何最左边的零填充都需要在填充的每个字节中正确设置高阶位。
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 SDNV is parsed, at which point the value itself is already known. This means that if space is allocated in advance to hold the value that results from decoding an SDNV, in general, it is not known whether this space will be large enough until it is 7 bits away from being overflowed. However, as specified in Section 3.3, protocols using SDNVs must specify the largest number of bits that an implementation is expected to handle, which mitigates this problem.
解码SDNV比编码SDNV更困难，因为在解析SDNV之前，结果值上的任何边界都是未知的，此时值本身是已知的。这意味着，如果预先分配空间来保存解码SDNV所产生的值，通常，在距离溢出7位之前，不知道该空间是否足够大。但是，如第3.3节所述，使用SDNV的协议必须指定实现预期要处理的最大位数，这可以缓解此问题。
o (Initial Step) Set the result to 0. Set an index to the first byte of the encoded SDNV.
o （初始步骤）将结果设置为0。将索引设置为编码SDNV的第一个字节。
o (Recursion Step) Shift the result left 7 bits. Add the low-order 7 bits of the value at the index to the result. If the high-order bit under the pointer is a 1, advance the index by one byte within the encoded SDNV and repeat the Recursion Step, otherwise return the current value of the result.
o （递归步骤）将结果左移7位。将索引处的值的低阶7位添加到结果中。如果指针下的高位为1，则在编码的SDNV内将索引前进一个字节，然后重复递归步骤，否则返回结果的当前值。
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. The complication is that before the result can be left-shifted in the Recursion Step, an implementation needs to first make sure that this will not 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 same as for the encoding algorithm given, but if re-allocation is needed due to the inability to predict the size of the result, decoding may be slower.
此解码算法占用的空间不超过结果（SDNV长度的7/8）和指针所需的空间。复杂的是，在结果可以在递归步骤中左移之前，实现需要首先确保这不会导致任何位丢失，并在需要时为结果重新分配更大的内存。纯时间复杂度与给定的编码算法相同，但如果由于无法预测结果的大小而需要重新分配，则解码可能会较慢。
These decoding steps include removal of any leftmost zero-padding that might be used by an encoder to create encodings of a certain length.
这些解码步骤包括删除编码器可能用于创建特定长度编码的最左边的零填充。
Because of efficiency considerations or convenience of internal representation of decoded integers, implementations may choose to limit the number of bits in SDNVs that they will handle. To avoid interoperability problems, any protocol that uses SDNVs must specify the largest number of bits in an SDNV that an implementation of that protocol is expected to handle.
出于效率考虑或解码整数内部表示的方便性，实现可能会选择限制SDNV中它们将处理的位数。为了避免互操作性问题，任何使用SDNV的协议都必须指定SDNV中预期该协议实现要处理的最大位数。
For example, Section 4.1 of [RFC5050] specifies that implementations of the DTN Bundle Protocol are not required to handle SDNVs with more than 64 bits in their unencoded value. Accordingly, integer values transmitted in SDNVs have an upper limit and SDNV-encoded flag fields must be limited to 64 bit positions in any future revisions of the protocol unless the restriction is altered.
例如，[RFC5050]第4.1节规定，处理未编码值超过64位的SDNV不需要DTN捆绑协议的实现。因此，在SDNV中传输的整数值具有上限，并且在协议的任何未来版本中，SDNV编码的标志字段必须限制在64位位置，除非改变限制。
This section compares three alternative ways of implementing the concept of SDNVs: (1) the TLV scheme commonly used in the Internet family, and many other families of protocols, (2) the old style of SDNVs (both the SDNV-8 and SDNV-16) defined in an early stage of LTP's development [BRF04], and (3) the current SDNV format.
本节比较了实现SDNV概念的三种备选方法：（1）互联网系列和许多其他协议系列中常用的TLV方案，（2）LTP开发早期[BRF04]定义的老式SDNV（SDNV-8和SDNV-16），以及（3）当前的SDNV格式。
The TLV method uses two fixed-length fields to hold the Type and Length elements that then imply the syntax and semantics of the Value element. This is only similar to an SDNV in that the value element can grow or shrink within the bounds capable of being conveyed by the Length field. Two fundamental differences between TLVs and SDNVs are that through the Type element, TLVs also contain some notion of what their contents are semantically, while SDNVs are simply generic non-negative integers, and protocol engineers still have to choose fixed-field lengths for the Type and Length fields in the TLV format.
TLV方法使用两个固定长度的字段来保存Type和length元素，这意味着Value元素的语法和语义。这仅与SDNV相似，因为值元素可以在长度字段能够传递的范围内增长或收缩。TLV和SDNV之间的两个基本区别是，通过Type元素，TLV还包含一些关于其内容在语义上是什么的概念，而SDNV只是泛型非负整数，协议工程师仍然必须为TLV格式的Type和Length字段选择固定字段长度。
Some protocols use TLVs where the value conveyed within the Length field needs to be decoded into the actual length of the Value field. This may be accomplished through simple multiplication, left-shifting, or a look-up table. In any case, this tactic limits the granularity of the possible Value lengths, and can contribute some degree of bloat if Values do not fit neatly within the available decoded Lengths.
一些协议使用TLV，其中长度字段中传递的值需要解码为值字段的实际长度。这可以通过简单的乘法、左移位或查找表来实现。在任何情况下，这种策略都会限制可能值长度的粒度，如果值不完全符合可用的解码长度，则会导致一定程度的膨胀。
In the SDNV format originally used by LTP, parsing the first byte of the SDNV told an implementation how much space was required to hold the contained value. There were two different types of SDNVs defined for different ranges of use. The SDNV-8 type could hold values up to 127 in a single byte, while the SDNV-16 type could hold values up to 32,767 in 2 bytes. Both formats could encode values requiring up to
在LTP最初使用的SDNV格式中，解析SDNV的第一个字节会告诉实现需要多少空间来保存包含的值。针对不同的使用范围定义了两种不同类型的SDNV。SDNV-8类型在一个字节中最多可以保存127个值，而SDNV-16类型在两个字节中最多可以保存32767个值。这两种格式都可以对需要多达
N bytes in N+2 bytes, where N<127. The major difference between this old SDNV format and the current SDNV format is that the new format is not as easily decoded as the old format was, but the new format also has absolutely no limitation on its length.
N+2字节中的N个字节，其中N<127。旧SDNV格式与当前SDNV格式的主要区别在于，新格式不像旧格式那样容易解码，但新格式对其长度也绝对没有限制。
The advantage in ease of parsing the old format manifests itself in two aspects: (1) the size of the value is determinable ahead of time, in a way equivalent to parsing a TLV, and (2) the actual value is directly encoded and decoded, without shifting and masking bits as is required in the new format. For these reasons, the old format requires less computational overhead to deal with, but is also very limited in that it can only hold a 1024-bit number, at maximum. Since according to IETF Best Current Practices, an asymmetric cryptography key needed to last for a long term requires using moduli of over 1228 bits [RFC3766], this could be seen as a severe limitation of the old style of SDNVs, from which the currently used style does not suffer.
易于解析旧格式的优点体现在两个方面：（1）值的大小可以提前确定，其方式相当于解析TLV；（2）直接对实际值进行编码和解码，而无需按照新格式的要求移位和掩蔽位。由于这些原因，旧格式需要较少的计算开销来处理，但也非常有限，因为它最多只能容纳1024位的数字。由于根据IETF当前最佳实践，需要长期使用的非对称加密密钥需要使用超过1228位的模[RFC3766]，这可以被视为旧SDNV的严重限制，当前使用的SDNV不会受到影响。
Table 1 compares the maximum values that can be encoded into SDNVs of various lengths using the old SDNV-8/16 method and the current SDNV method. The only place in this table where SDNV-16 is used rather than SDNV-8 is in the 2-byte row. Starting with a single byte, the two methods are equivalent, but when using 2 bytes, the old method is a more compact encoding by one bit. From 3 to 7 bytes of length though, the current SDNV format is more compact, since it only requires one bit per byte of overhead, whereas the old format used a full byte. Thus, at 8 bytes, both schemes are equivalent in efficiency since they both use 8 bits of overhead. Up to 129 bytes, the old format is more compact than the current one, although after this, limit it becomes unusable.
表1比较了使用旧SDNV-8/16方法和当前SDNV方法可编码为不同长度SDNV的最大值。本表中使用SDNV-16而不是SDNV-8的唯一位置是2字节行。从一个字节开始，这两种方法是等效的，但是当使用2个字节时，旧方法是一位更紧凑的编码。但是，从3到7字节的长度，当前的SDNV格式更紧凑，因为它每字节只需要一位开销，而旧格式使用的是一个完整字节。因此，在8字节时，两种方案的效率相当，因为它们都使用8位的开销。高达129字节，旧格式比当前格式更紧凑，尽管在这一限制之后，它将变得不可用。
+-------+---------------+-------------+---------------+-------------+
| Bytes | SDNV-8/16 | SDNV | SDNV-8/16 | SDNV |
| | Maximum Value | Maximum | Overhead Bits | Overhead |
| | | Value | | Bits |
+-------+---------------+-------------+---------------+-------------+
| 1 | 127 | 127 | 1 | 1 |
| | | | | |
| 2 | 32,767 | 16,383 | 1 | 2 |
| | | | | |
| 3 | 65,535 | 2,097,151 | 8 | 3 |
| | | | | |
| 4 | 2^24 - 1 | 2^28 - 1 | 8 | 4 |
| | | | | |
| 5 | 2^32 - 1 | 2^35 - 1 | 8 | 5 |
| | | | | |
| 6 | 2^40 - 1 | 2^42 - 1 | 8 | 6 |
| | | | | |
| 7 | 2^48 - 1 | 2^49 - 1 | 8 | 7 |
| | | | | |
| 8 | 2^56 - 1 | 2^56 - 1 | 8 | 8 |
| | | | | |
| 9 | 2^64 - 1 | 2^63 - 1 | 8 | 9 |
| | | | | |
| 10 | 2^72 - 1 | 2^70 - 1 | 8 | 10 |
| | | | | |
| 16 | 2^120 - 1 | 2^112 - 1 | 8 | 16 |
| | | | | |
| 32 | 2^248 - 1 | 2^224 - 1 | 8 | 32 |
| | | | | |
| 64 | 2^504 - 1 | 2^448 - 1 | 8 | 64 |
| | | | | |
| 128 | 2^1016 - 1 | 2^896 - 1 | 8 | 128 |
| | | | | |
| 129 | 2^1024 - 1 | 2^903 - 1 | 8 | 129 |
| | | | | |
| 130 | N/A | 2^910 - 1 | N/A | 130 |
| | | | | |
| 256 | N/A | 2^1792 - 1 | N/A | 256 |
+-------+---------------+-------------+---------------+-------------+
+-------+---------------+-------------+---------------+-------------+
| Bytes | SDNV-8/16 | SDNV | SDNV-8/16 | SDNV |
| | Maximum Value | Maximum | Overhead Bits | Overhead |
| | | Value | | Bits |
+-------+---------------+-------------+---------------+-------------+
| 1 | 127 | 127 | 1 | 1 |
| | | | | |
| 2 | 32,767 | 16,383 | 1 | 2 |
| | | | | |
| 3 | 65,535 | 2,097,151 | 8 | 3 |
| | | | | |
| 4 | 2^24 - 1 | 2^28 - 1 | 8 | 4 |
| | | | | |
| 5 | 2^32 - 1 | 2^35 - 1 | 8 | 5 |
| | | | | |
| 6 | 2^40 - 1 | 2^42 - 1 | 8 | 6 |
| | | | | |
| 7 | 2^48 - 1 | 2^49 - 1 | 8 | 7 |
| | | | | |
| 8 | 2^56 - 1 | 2^56 - 1 | 8 | 8 |
| | | | | |
| 9 | 2^64 - 1 | 2^63 - 1 | 8 | 9 |
| | | | | |
| 10 | 2^72 - 1 | 2^70 - 1 | 8 | 10 |
| | | | | |
| 16 | 2^120 - 1 | 2^112 - 1 | 8 | 16 |
| | | | | |
| 32 | 2^248 - 1 | 2^224 - 1 | 8 | 32 |
| | | | | |
| 64 | 2^504 - 1 | 2^448 - 1 | 8 | 64 |
| | | | | |
| 128 | 2^1016 - 1 | 2^896 - 1 | 8 | 128 |
| | | | | |
| 129 | 2^1024 - 1 | 2^903 - 1 | 8 | 129 |
| | | | | |
| 130 | N/A | 2^910 - 1 | N/A | 130 |
| | | | | |
| 256 | N/A | 2^1792 - 1 | N/A | 256 |
+-------+---------------+-------------+---------------+-------------+
Table 1
表1
Suggested usages of the SDNV format that leverage its strengths and limit the effects of its weaknesses are discussed in Section 1.3.
第1.3节讨论了利用SDNV格式的优点并限制其缺点影响的建议用法。
Another aspect of the comparison between SDNVs and alternatives using fixed-length fields is the result of errors in transmission. Bit-errors in an SDNV can result in either errors in the decoded value,
SDNV和使用固定长度字段的备选方案之间比较的另一个方面是传输错误的结果。SDNV中的位错误可能导致解码值中的错误，
or parsing errors in subsequent fields of the protocol. In fixed-length fields, bit errors always result in errors to the decoded value rather than parsing errors in subsequent fields. If the decoded values from either type of field encoding (SDNV or fixed-length) are used as indexes, offsets, or lengths of further fields in the protocol, similar failures result.
或解析协议后续字段中的错误。在固定长度字段中，位错误总是导致解码值出错，而不是在后续字段中解析错误。如果将来自任一类型字段编码（SDNV或固定长度）的解码值用作协议中其他字段的索引、偏移量或长度，则会导致类似的故障。
The only security considerations with regard to SDNVs are that code that parses SDNVs should have bounds-checking logic and be capable of handling cases where an SDNV's value is beyond the code's ability to parse. These precautions can prevent potential exploits involving SDNV decoding routines.
关于SDNV的唯一安全考虑是，解析SDNV的代码应该具有边界检查逻辑，并且能够处理SDNV值超出代码解析能力的情况。这些预防措施可以防止涉及SDNV解码例程的潜在攻击。
Stephen Farrell noted that very early definitions of SDNVs also allowed negative integers. This was considered a potential security hole, since it could expose implementations to underflow attacks during SDNV decoding. There is a precedent in that many existing TLV decoders map the Length field to a signed integer and are vulnerable in this way. An SDNV decoder should be based on unsigned types and not have this issue.
Stephen Farrell指出，SDNV的早期定义也允许负整数。这被认为是一个潜在的安全漏洞，因为在SDNV解码过程中，它可能会使实现受到下溢攻击。有一个先例是，许多现有的TLV解码器将长度字段映射为有符号整数，因此容易受到攻击。SDNV解码器应基于无符号类型，不存在此问题。
Scott Burleigh, Manikantan Ramadas, Michael Demmer, Stephen Farrell, and other members of the IRTF DTN Research Group contributed to the development and usage of SDNVs in DTN protocols. George Jones and Keith Scott from Mitre, Lloyd Wood, Gerardo Izquierdo, Joel Halpern, Peter TB Brett, Kevin Fall, and Elwyn Davies also contributed useful comments on and criticisms of this document. DTNRG last call comments on the document were sent to the mailing list by Lloyd Wood, Will Ivancic, Jim Wyllie, William Edwards, Hans Kruse, Janico Greifenberg, Teemu Karkkainen, Stephen Farrell, and Scott Burleigh. Further constructive comments from Dave Crocker, Lachlan Andrew, and Michael Welzl were incorporated.
Scott Burleigh、Manikantan Ramadas、Michael Demmer、Stephen Farrell和IRTF DTN研究小组的其他成员为DTN协议中SDNV的开发和使用做出了贡献。来自米特、劳埃德·伍德、杰拉尔多·伊兹奎尔多、乔尔·哈尔彭、彼得·特布·布雷特、凯文·法尔和埃尔温·戴维斯的乔治·琼斯和基思·斯科特也对本文件提出了有益的评论和批评。DTNRG对该文件的最后一次通话评论由劳埃德·伍德、威尔·伊万西奇、吉姆·维利、威廉·爱德华兹、汉斯·克鲁斯、杰尼科·格雷芬伯格、蒂姆·卡卡宁、斯蒂芬·法雷尔和斯科特·伯利发送到邮件列表中。Dave Crocker、Lachlan Andrew和Michael Welzl提出了进一步的建设性意见。
Work on this document was performed at NASA's Glenn Research Center, in support of the NASA Space Communications Architecture Working Group (SCAWG), NASA's Earth Science Technology Office (ESTO), and the FAA/Eurocontrol Future Communications Study (FCS) in the 2005-2007 time frame, while the editor was an employee of Verizon Federal Network Systems.
在2005-2007年的时间框架内，为支持NASA空间通信体系结构工作组（SCAWG）、NASA地球科学技术办公室（ESTO）和FAA/Eurocontrol未来通信研究（FCS），NASA格伦研究中心对本文件进行了研究，而编辑是Verizon联邦网络系统公司的雇员。
[ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1). Specification of Basic Notation", ISO/IEC 8824-1:2002, 2002.
[ASN1]ITU-T Rec.X.680，“抽象语法符号1（ASN.1）.基本符号规范”，ISO/IEC 8824-1:2002，2002年。
[BRF04] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol", Work in Progress, May 2004.
[BRF04]Burleigh，S.，Ramadas，M.，和S.Farrell，“利克利德传输协议”，正在进行的工作，2004年5月。
[Hain05] Hain, T., "A Pragmatic Report on IPv4 Address Space Consumption", Internet Protocol Journal Vol. 8, No. 3, September 2005.
[Hain05]Hain，T.，“IPv4地址空间消耗的实用报告”，《互联网协议杂志》第8卷，第3期，2005年9月。
[IEN21] Cerf, V. and J. Postel, "Specification of Internetwork Transmission Control Program: TCP Version 3", Internet Experimental Note 21, January 1978.
[IEN21]Cerf，V.和J.Postel，“互联网传输控制程序规范：TCP版本3”，互联网实验说明21，1978年1月。
[Manning09] Manning, c., Raghavan, P., and H. Schuetze, "Introduction to Information Retrieval", Cambridge University Press ISBN-13: 978-0521865715, 2009, <http://informationretrieval.org/>.
[Manning 09]Manning，c.，Raghavan，P.，和H.Schuetze，“信息检索导论”，剑桥大学出版社ISBN-13:978-05218657152009<http://informationretrieval.org/>.
[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission Protocol", RFC 713, April 1976.
[RFC0713]Haverty，J.，“MSDTP消息服务数据传输协议”，RFC 713，1976年4月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]Scott，K.和S.Burleigh，“捆绑协议规范”，RFC 50502007年11月。
[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[RFC5325]Burleigh，S.，Ramadas，M.，和S.Farrell，“利克利德传输协议-动机”，RFC 53252008年9月。
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[RFC5326]Ramadas，M.，Burleigh，S.和S.Farrell，“利克利德传输协议-规范”，RFC 5326，2008年9月。
[Sayood02] Sayood, K., "Lossless Data Compression", Academic Press ISBN-13: 978-0126208610, December 2002, <http://books.google.co.uk/books?id=LjQiGwyabVwC>.
[Sayood02]Sayood，K.，“无损数据压缩”，学术出版社ISBN-13:978-01262086102002年12月<http://books.google.co.uk/books?id=LjQiGwyabVwC>.
[X.690] ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1). Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2002, 2002.
[X.690]ITU-T Rec.X.690，“抽象语法符号1（ASN.1）.编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ISO/IEC 8825-1:2002。
# This code may be freely copied. Attribution would be appreciated.
#
# sdnv_decode() takes a string argument (s), which is assumed to be
# an SDNV, and optionally a number (slen) for the maximum number 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 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
# 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
# be pre-computed by calling code. If the slen argument is given
# 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
# languages, such as C, SDNV-parsing routines should take
# precautions to avoid overflow (e.g., by using the Gnu MP library,
# or similar).
#
def sdnv_decode(s, slen=0):
n = long(0)
for i in range(0, len(s)):
v = ord(s[i])
n = n<<7
n = n + (v & 0x7F)
if v>>7 == 0:
slen = i+1
break
elif i == len(s)-1 or (slen != 0 and i > slen):
n = -1 # reached end of input without seeing end of SDNV
return (n, slen)
# This code may be freely copied. Attribution would be appreciated.
#
# sdnv_decode() takes a string argument (s), which is assumed to be
# an SDNV, and optionally a number (slen) for the maximum number 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 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
# 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
# be pre-computed by calling code. If the slen argument is given
# 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
# languages, such as C, SDNV-parsing routines should take
# precautions to avoid overflow (e.g., by using the Gnu MP library,
# or similar).
#
def sdnv_decode(s, slen=0):
n = long(0)
for i in range(0, len(s)):
v = ord(s[i])
n = n<<7
n = n + (v & 0x7F)
if v>>7 == 0:
slen = i+1
break
elif i == len(s)-1 or (slen != 0 and i > slen):
n = -1 # reached end of input without seeing end of SDNV
return (n, slen)
# sdnv_encode() returns the SDNV-encoded string that represents n. # An empty string is returned if n is not a non-negative integer def sdnv_encode(n): r = "" # validate input if n >= 0 and (type(n) in [type(int(1)), type(long(1))]): flag = 0 done = False while not done: # encode lowest 7 bits from n newbits = n & 0x7F n = n>>7 r = chr(newbits + flag) + r if flag == 0:
#sdnv_encode（）返回表示n.#的sdnv编码字符串如果n不是非负整数def sdnv_encode（n）：r=”“#如果n>=0和（type（n）在[type（int（1）），type（long（1））]中）：flag=0 done=False而未完成：#从n newbits=n&0x7F n=n>>7编码最低7位r=chr（newbits+flag）+r如果flag==0：
flag = 0x80 if n == 0: done = True return r
如果n==0，则标志=0x80:done=True返回r
# test cases from LTP and BP internet-drafts, only print failures
def sdnv_test():
tests = [(0xABC, chr(0x95) + chr(0x3C)),
(0x1234, chr(0xA4) + chr (0x34)),
(0x4234, chr(0x81) + chr(0x84) + chr(0x34)),
(0x7F, chr(0x7F))]
# test cases from LTP and BP internet-drafts, only print failures
def sdnv_test():
tests = [(0xABC, chr(0x95) + chr(0x3C)),
(0x1234, chr(0xA4) + chr (0x34)),
(0x4234, chr(0x81) + chr(0x84) + chr(0x34)),
(0x7F, chr(0x7F))]
for tp in tests:
# test encoding function
if sdnv_encode(tp[0]) != tp[1]:
print "sdnv_encode fails on input %s" % hex(tp[0])
# test decoding function
if sdnv_decode(tp[1])[0] != tp[0]:
print "sdnv_decode fails on input %s, giving %s" % \
(hex(tp[0]), sdnv_decode(tp[1]))
for tp in tests:
# test encoding function
if sdnv_encode(tp[0]) != tp[1]:
print "sdnv_encode fails on input %s" % hex(tp[0])
# test decoding function
if sdnv_decode(tp[1])[0] != tp[0]:
print "sdnv_decode fails on input %s, giving %s" % \
(hex(tp[0]), sdnv_decode(tp[1]))
Authors' Addresses
作者地址
Wesley M. Eddy MTI Systems NASA Glenn Research Center MS 500-ASRC; 21000 Brookpark Rd Cleveland, OH 44135
美国宇航局格伦研究中心MS 500-ASRC；俄亥俄州克利夫兰布鲁克公园路21000号，邮编44135
Phone: 216-433-6682 EMail: wes@mti-systems.com
电话：216-433-6682电子邮件：wes@mti-系统网
Elwyn Davies Folly Consulting Soham UK
Elwyn Davies Folly咨询英国苏哈姆
Phone: EMail: elwynd@folly.org.uk URI:
电话：电邮：elwynd@folly.org.ukURI: