Network Working Group R. Price
Request for Comments: 3320 Siemens/Roke Manor
Category: Standards Track C. Bormann
TZI/Uni Bremen
J. Christoffersson
H. Hannu
Ericsson
Z. Liu
Nokia
J. Rosenberg
dynamicsoft
January 2003
Network Working Group R. Price
Request for Comments: 3320 Siemens/Roke Manor
Category: Standards Track C. Bormann
TZI/Uni Bremen
J. Christoffersson
H. Hannu
Ericsson
Z. Liu
Nokia
J. Rosenberg
dynamicsoft
January 2003
Signaling Compression (SigComp)
信令压缩（SigComp）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP) (RFC 3261) and the Real Time Streaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of the SigComp message.
本文档定义了信令压缩（SigComp），这是一种用于压缩应用程序协议（如会话启动协议（SIP）（RFC 3261）和实时流协议（RTSP）（RFC 2326））生成的消息的解决方案。概述了SigComp的体系结构和先决条件，以及SigComp消息的格式。
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).
SigComp的解压功能由通用解压器虚拟机（UDVM）提供，该虚拟机针对运行解压算法的任务进行了优化。UDVM可配置为了解许多知名压缩机的输出，如DEFLATE（RFC-1951）。
Table of Contents
目录
1. Introduction...................................................2
2. Terminology....................................................3
3. SigComp architecture...........................................5
4. SigComp dispatchers...........................................15
5. SigComp compressor............................................18
6. SigComp state handler.........................................20
7. SigComp message format........................................23
8. Overview of the UDVM..........................................28
9. UDVM instruction set..........................................37
10. Security Considerations.......................................56
11. IANA Considerations...........................................58
12. Acknowledgements..............................................59
13. References....................................................59
14. Authors' Addresses............................................60
15. Full Copyright Statement......................................62
1. Introduction...................................................2
2. Terminology....................................................3
3. SigComp architecture...........................................5
4. SigComp dispatchers...........................................15
5. SigComp compressor............................................18
6. SigComp state handler.........................................20
7. SigComp message format........................................23
8. Overview of the UDVM..........................................28
9. UDVM instruction set..........................................37
10. Security Considerations.......................................56
11. IANA Considerations...........................................58
12. Acknowledgements..............................................59
13. References....................................................59
14. Authors' Addresses............................................60
15. Full Copyright Statement......................................62
Many application protocols used for multimedia communications are text-based and engineered for bandwidth rich links. As a result the messages have not been optimized in terms of size. For example, typical SIP messages range from a few hundred bytes up to two thousand bytes or more [RFC3261].
许多用于多媒体通信的应用程序协议都是基于文本的，专为带宽丰富的链路而设计。因此，消息的大小没有得到优化。例如，典型的SIP消息范围从几百字节到两千字节或更多[RFC3261]。
With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G cellular networks, the large message size is problematic. With low-rate IP connectivity the transmission delays are significant. Taking into account retransmissions, and the multiplicity of messages that are required in some flows, call setup and feature invocation are adversely affected. SigComp provides a means to eliminate this problem by offering robust, lossless compression of application messages.
由于计划将这些协议作为2.5G和3G蜂窝网络的一部分在无线手机中使用，因此大消息量是有问题的。对于低速率IP连接，传输延迟非常显著。考虑到重传以及某些流中所需的消息的多样性，调用设置和功能调用会受到不利影响。SigComp提供了一种通过提供应用程序消息的健壮、无损压缩来消除此问题的方法。
This document outlines the architecture and prerequisites of the SigComp solution, the format of the SigComp message and the Universal Decompressor Virtual Machine (UDVM) that provides decompression functionality.
本文档概述了SigComp解决方案的体系结构和先决条件、SigComp消息的格式以及提供解压功能的通用解压器虚拟机（UDVM）。
SigComp is offered to applications as a layer between the application and an underlying transport. The service provided is that of the underlying transport plus compression. SigComp supports a wide range of transports including TCP, UDP and SCTP [RFC-2960].
SigComp作为应用程序和底层传输之间的一层提供给应用程序。提供的服务是底层传输加上压缩的服务。SigComp支持多种传输方式，包括TCP、UDP和SCTP[RFC-2960]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC-2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC-2119]中的说明进行解释。
Application
应用
Entity that invokes SigComp and performs the following tasks:
调用SigComp并执行以下任务的实体：
1. Supplying application messages to the compressor dispatcher 2. Receiving decompressed messages from the decompressor dispatcher 3. Determining the compartment identifier for a decompressed message.
1. 向压缩机调度器2提供应用程序消息。从解压缩器调度器3接收解压缩消息。确定解压缩消息的隔室标识符。
Bytecode
字节码
Machine code that can be executed by a virtual machine.
可由虚拟机执行的机器代码。
Compressor
压缩机
Entity that encodes application messages using a certain compression algorithm, and keeps track of state that can be used for compression. The compressor is responsible for ensuring that the messages it generates can be decompressed by the remote UDVM.
使用某种压缩算法对应用程序消息进行编码并跟踪可用于压缩的状态的实体。压缩器负责确保远程UDVM可以对其生成的消息进行解压缩。
Compressor Dispatcher
压缩机调度员
Entity that receives application messages, invokes a compressor, and forwards the resulting SigComp compressed messages to a remote endpoint.
接收应用程序消息、调用压缩器并将生成的SigComp压缩消息转发到远程端点的实体。
UDVM Cycles
UDVM循环
A measure of the amount of "CPU power" required to execute a UDVM instruction (the simplest UDVM instructions require a single UDVM cycle). An upper limit is placed on the number of UDVM cycles that can be used to decompress each bit in a SigComp message.
执行UDVM指令（最简单的UDVM指令需要一个UDVM周期）所需的“CPU功率”的度量。可以用于解压缩SigComp消息中的每个位的UDVM循环数有一个上限。
Decompressor Dispatcher
解压调度器
Entity that receives SigComp messages, invokes a UDVM, and forwards the resulting decompressed messages to the application.
接收SigComp消息、调用UDVM并将结果解压缩消息转发给应用程序的实体。
Endpoint
端点
One instance of an application, a SigComp layer, and a transport layer for sending and/or receiving SigComp messages.
用于发送和/或接收SigComp消息的应用程序、SigComp层和传输层的一个实例。
Message-based Transport
基于消息的传输
A transport that carries data as a set of bounded messages.
作为一组有界消息传送数据的一种传输。
Compartment
隔间
An application-specific grouping of messages that relate to a peer endpoint. Depending on the signaling protocol, this grouping may relate to application concepts such as "session", "dialog", "connection", or "association". The application allocates state memory on a per-compartment basis, and determines when a compartment should be created or closed.
与对等端点相关的特定于应用程序的消息分组。根据信令协议，该分组可能与诸如“会话”、“对话”、“连接”或“关联”之类的应用概念有关。应用程序按每个隔室分配状态内存，并确定应在何时创建或关闭隔室。
Compartment Identifier
隔室标识符
An identifier (in a locally chosen format) that uniquely references a compartment.
唯一引用隔室的标识符（采用本地选择的格式）。
SigComp
信号压缩
The overall compression solution, comprising the compressor, UDVM, dispatchers and state handler.
整体压缩解决方案，包括压缩器、UDVM、dispatchers和状态处理程序。
SigComp Message
SigComp消息
A message sent from the compressor dispatcher to the decompressor dispatcher. In case of a message-based transport such as UDP, a SigComp message corresponds to exactly one datagram. For a stream-based transport such as TCP, the SigComp messages are separated by reserved delimiters.
从压缩机调度器发送到解压缩器调度器的消息。在基于消息的传输（如UDP）的情况下，SigComp消息只对应于一个数据报。对于基于流的传输（如TCP），SigComp消息由保留分隔符分隔。
Stream-based transport
基于流的传输
A transport that carries data as a continuous stream with no message boundaries.
以连续流的形式传输数据的一种传输方式，没有消息边界。
Transport
运输
Mechanism for passing data between two endpoints. SigComp is capable of sending messages over a wide range of transports including TCP, UDP and SCTP [RFC-2960].
在两个端点之间传递数据的机制。SigComp能够通过多种传输方式发送消息，包括TCP、UDP和SCTP[RFC-2960]。
Universal Decompressor Virtual Machine (UDVM)
通用解压缩器虚拟机（UDVM）
The machine architecture described in this document. The UDVM is used to decompress SigComp messages.
本文档中描述的机器体系结构。UDVM用于解压缩SigComp消息。
State
状态
Data saved for retrieval by later SigComp messages.
保存供以后SigComp消息检索的数据。
State Handler
状态处理程序
Entity responsible for accessing and storing state information once permission is granted by the application.
应用程序授予权限后，负责访问和存储状态信息的实体。
State Identifier
状态标识符
Reference used to access a previously created item of state.
用于访问以前创建的状态项的引用。
In the SigComp architecture, compression and decompression is performed at two communicating endpoints. The layout of a single endpoint is illustrated in Figure 1:
在SigComp体系结构中，在两个通信端点处执行压缩和解压缩。单个端点的布局如图1所示：
+-------------------------------------------------------------------+
| |
| Local application |
| |
+-------------------------------------------------------------------+
| ^ |
Application message & | Decompressed | | Compartment
compartment identifier | message | | identifier
| | |
+-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+
v | v
| +------------------------+ +----------------------+ |
| | | |
| +--| Compressor | | Decompressor |<-+ |
| | dispatcher | | dispatcher | |
| | | | | | | |
| +------------------------+ +----------------------+ |
| | ^ ^ ^ | |
| | | | |
| | | v | | |
| | +--------------+ +---------------+ | |
| | | | | | +-------+ | v | |
| | | Compressor 1 |<----->|State 1| | +--------------+ |
| | | | | | +-------+ | | | | |
| | +--------------+ | | | Decompressor | |
| | | | State handler |<-->| | | |
| | +--------------+ | | | (UDVM) | |
| | | | | | +-------+ | | | | |
| +->| Compressor 2 |<----->|State 2| | +--------------+ |
| | | | | +-------+ | | |
| +--------------+ +---------------+ SigComp layer |
| | | |
+-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --|-+
| |
| SigComp SigComp |
| message message |
v |
+-------------------------------------------------------------------+
| |
| Transport layer |
| |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| |
| Local application |
| |
+-------------------------------------------------------------------+
| ^ |
Application message & | Decompressed | | Compartment
compartment identifier | message | | identifier
| | |
+-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+
v | v
| +------------------------+ +----------------------+ |
| | | |
| +--| Compressor | | Decompressor |<-+ |
| | dispatcher | | dispatcher | |
| | | | | | | |
| +------------------------+ +----------------------+ |
| | ^ ^ ^ | |
| | | | |
| | | v | | |
| | +--------------+ +---------------+ | |
| | | | | | +-------+ | v | |
| | | Compressor 1 |<----->|State 1| | +--------------+ |
| | | | | | +-------+ | | | | |
| | +--------------+ | | | Decompressor | |
| | | | State handler |<-->| | | |
| | +--------------+ | | | (UDVM) | |
| | | | | | +-------+ | | | | |
| +->| Compressor 2 |<----->|State 2| | +--------------+ |
| | | | | +-------+ | | |
| +--------------+ +---------------+ SigComp layer |
| | | |
+-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --|-+
| |
| SigComp SigComp |
| message message |
v |
+-------------------------------------------------------------------+
| |
| Transport layer |
| |
+-------------------------------------------------------------------+
Figure 1: High-level architectural overview of one SigComp endpoint
图1：一个SigComp端点的高级体系结构概述
Note that SigComp is offered to applications as a layer between the application and the underlying transport, and so Figure 1 is an endpoint when viewed from a transport layer perspective. From the perspective of multi-hop application layer protocols however, SigComp is applied on a per-hop basis.
请注意，SigComp作为应用程序和底层传输之间的一个层提供给应用程序，因此从传输层的角度来看，图1是一个端点。然而，从多跳应用层协议的角度来看，SigComp是基于每跳应用的。
The SigComp layer is further decomposed into the following entities:
SigComp层进一步分解为以下实体：
1. Compressor dispatcher - the interface from the application. The application supplies the compressor dispatcher with an application message and a compartment identifier (see Section 3.1 for further details). The compressor dispatcher invokes a particular compressor, which returns a SigComp message to be forwarded to the remote endpoint.
1. Compressor dispatcher—应用程序的接口。该应用程序向压缩机调度器提供应用程序消息和隔间标识符（有关更多详细信息，请参阅第3.1节）。压缩器调度器调用特定压缩器，该压缩器返回要转发到远程端点的SigComp消息。
2. Decompressor dispatcher - the interface towards the application. The decompressor dispatcher receives a SigComp message and invokes an instance of the Universal Decompressor Virtual Machine (UDVM). It then forwards the resulting decompressed message to the application, which may return a compartment identifier if it wishes to allow state to be saved for the message.
2. Decompressor dispatcher—面向应用程序的接口。解压缩程序调度器接收SigComp消息并调用通用解压缩程序虚拟机（UDVM）的实例。然后，它将得到的解压缩消息转发给应用程序，如果希望为消息保存状态，应用程序可能会返回一个隔间标识符。
3. One or more compressors - the entities that convert application messages into SigComp messages. Distinct compressors are invoked on a per-compartment basis, using the compartment identifiers supplied by the application. A compressor receives an application message from the compressor dispatcher, compresses the message, and returns a SigComp message to the compressor dispatcher. Each compressor chooses a certain algorithm to encode the data (e.g., DEFLATE).
3. 一个或多个压缩器-将应用程序消息转换为SigComp消息的实体。使用应用程序提供的隔室标识符，在每个隔室的基础上调用不同的压缩器。压缩器从压缩器调度器接收应用程序消息，压缩该消息，并将SigComp消息返回给压缩器调度器。每个压缩机选择特定的算法对数据进行编码（例如，放气）。
4. UDVM - the entity that decompresses SigComp messages. Note that since SigComp can run over an unsecured transport layer, a separate instance of the UDVM is invoked on a per-message basis. However, during the decompression process the UDVM may invoke the state handler to access existing state or create new state.
4. UDVM—解压缩SigComp消息的实体。请注意，由于SigComp可以在不安全的传输层上运行，因此会根据每条消息调用单独的UDVM实例。但是，在解压缩过程中，UDVM可能会调用状态处理程序来访问现有状态或创建新状态。
5. State handler - the entity that can store and retrieve state. State is information that is stored between SigComp messages, avoiding the need to upload the data on a per-message basis. For security purposes it is only possible to create new state with the permission of the application. State creation and retrieval are further described in Chapter 6.
5. 状态处理程序-可以存储和检索状态的实体。状态是存储在SigComp消息之间的信息，无需按每条消息上载数据。出于安全目的，只有在应用程序许可的情况下才能创建新状态。第6章进一步描述了状态创建和检索。
When compressing a bidirectional application protocol the choice to use SigComp can be made independently in both directions, and compression in one direction does not necessarily imply compression in the reverse direction. Moreover, even when two communicating endpoints send SigComp messages in both directions, there is no need to use the same compression algorithm in each direction.
压缩双向应用协议时，可以在两个方向上独立选择使用SigComp，并且一个方向上的压缩不一定意味着反向压缩。此外，即使两个通信端点在两个方向上发送SigComp消息，也不需要在每个方向上使用相同的压缩算法。
Note that a SigComp endpoint can decompress messages from multiple remote endpoints at different locations in a network, as the architecture is designed to prevent SigComp messages from one endpoint interfering with messages from a different endpoint. A consequence of this design choice is that it is difficult for a malicious user to disrupt SigComp operation by inserting false compressed messages on the transport layer.
请注意，SigComp端点可以解压缩来自网络中不同位置的多个远程端点的消息，因为该体系结构旨在防止来自一个端点的SigComp消息干扰来自不同端点的消息。这种设计选择的结果是，恶意用户很难通过在传输层插入错误的压缩消息来中断SigComp操作。
From an application perspective the SigComp layer appears as a new transport, with similar behavior to the original transport used to carry uncompressed data (for example SigComp/UDP behaves similarly to native UDP).
从应用程序的角度来看，SigComp层显示为一个新的传输，其行为类似于用于传输未压缩数据的原始传输（例如，SigComp/UDP的行为类似于本机UDP）。
Mechanisms for discovering whether an endpoint supports SigComp are beyond the scope of this document.
发现端点是否支持SigComp的机制超出了本文档的范围。
All SigComp messages contain a prefix (the five most-significant bits of the first byte are set to one) that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port. Applications can still reserve a new port specifically for SigComp however (e.g., as part of the discovery mechanism).
所有SigComp消息都包含一个前缀（第一个字节的五个最高有效位被设置为一个），该前缀不会出现在UTF-8编码的文本消息[RFC-2279]中，因此对于使用此编码（或ASCII编码）的应用程序，可以在同一端口上多路传输未压缩的应用程序消息和SigComp消息。但是，应用程序仍然可以专门为SigComp保留一个新端口（例如，作为发现机制的一部分）。
If a particular endpoint wishes to be stateful then it needs to partition its decompressed messages into "compartments" under which state can be saved. SigComp relies on the application to provide this partition. So for stateful endpoints a new interface is required to the application in order to leverage the authentication mechanisms used by the application itself.
如果一个特定的端点希望是有状态的，那么它需要将其解压缩的消息划分到“隔间”中，在“隔间”中可以保存状态。SigComp依赖应用程序来提供此分区。因此，对于有状态端点，需要为应用程序提供一个新接口，以便利用应用程序本身使用的身份验证机制。
When the application receives a decompressed message it maps the message to a certain compartment and supplies the compartment identifier to SigComp. Each compartment is allocated a separate compressor and a certain amount of memory to store state information, so the application must assign distinct compartments to distinct remote endpoints. However it is possible for a local endpoint to establish several compartments that relate to the same remote endpoint (this should be avoided where possible as it may waste
当应用程序接收到解压缩的消息时，它将消息映射到某个隔室，并将隔室标识符提供给SigComp。每个隔室分配一个单独的压缩器和一定量的内存来存储状态信息，因此应用程序必须将不同的隔室分配给不同的远程端点。但是，本地端点可以建立多个与同一远程端点相关的隔室（应尽可能避免，因为这可能会造成浪费）
memory and reduce the overall compression ratio, but it does not cause messages to be incorrectly decompressed). In this case, reliable stateful operation is possible only if the decompressor does not lump several messages into one compartment when the compressor expected them to be assigned different compartments.
内存，并降低总体压缩比，但不会导致消息被错误解压缩）。在这种情况下，只有当压缩机希望将多条消息分配给不同的隔间时，解压器不会将多条消息集中到一个隔间中，才可能实现可靠的有状态运行。
The exact format of the compartment identifier is unimportant provided that different identifiers are given to different compartments.
如果为不同的隔间提供不同的标识符，则隔间标识符的确切格式并不重要。
Applications that wish to communicate using SigComp in a stateful fashion should use an authentication mechanism to securely map decompressed messages to compartment identifiers. They should also agree on any limits to the lifetime of a compartment, to avoid the case where an endpoint accesses state information that has already been deleted.
希望以有状态方式使用SigComp进行通信的应用程序应使用身份验证机制将解压缩的消息安全地映射到隔室标识符。他们还应该就隔室寿命的任何限制达成一致，以避免端点访问已经删除的状态信息的情况。
If a signaling protocol sends SigComp messages in both directions and there is a one-to-one relationship between the compartments established by the applications on both ends ("peer compartments"), the two endpoints can cooperate more closely. In this case, it is possible to send feedback information that monitors the behavior of an endpoint and helps to improve the overall compression ratio. SigComp performs feedback on a request/response basis, so a compressor makes a feedback request and receives some feedback data in return. The procedure for requesting and returning feedback in SigComp is illustrated in Figure 2:
如果信令协议在两个方向上发送SigComp消息，并且在两端应用程序建立的隔室（“对等隔室”）之间存在一对一关系，则两个端点可以更紧密地合作。在这种情况下，可以发送反馈信息来监视端点的行为，并帮助提高总体压缩比。SigComp在请求/响应的基础上执行反馈，因此压缩器发出反馈请求并接收一些反馈数据作为回报。在SigComp中请求和返回反馈的过程如图2所示：
+---------------------+ +---------------------+
| +-----------------+ | | +-----------------+ |
-->| Compressor |------------------------>| UDVM |<->
| | sending to B | | SigComp message | | | |2
| +-----------------+ | requesting feedback | +-----------------+ |
| ^ 1,9 | | 3 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | State | | | | State | |
| | handler | | | | handler | |
| +-----------------+ | | +-----------------+ |
| ^ 8 | | 4 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | UDVM | | | | Compressor | |
<->| |<------------------------| sending to A |<--
6| +-----------------+ | SigComp message | +-----------------+ |
| 7 | returning feedback | 5 |
| Endpoint A | | Endpoint B |
+---------------------+ +---------------------+
+---------------------+ +---------------------+
| +-----------------+ | | +-----------------+ |
-->| Compressor |------------------------>| UDVM |<->
| | sending to B | | SigComp message | | | |2
| +-----------------+ | requesting feedback | +-----------------+ |
| ^ 1,9 | | 3 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | State | | | | State | |
| | handler | | | | handler | |
| +-----------------+ | | +-----------------+ |
| ^ 8 | | 4 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | UDVM | | | | Compressor | |
<->| |<------------------------| sending to A |<--
6| +-----------------+ | SigComp message | +-----------------+ |
| 7 | returning feedback | 5 |
| Endpoint A | | Endpoint B |
+---------------------+ +---------------------+
Figure 2: Steps involved in the transmission of feedback data
图2：反馈数据传输中涉及的步骤
The dispatchers, the application and the transport layer are omitted from the diagram for clarity. Note that the decompressed messages pass via the decompressor dispatcher to the application; moreover the SigComp messages transmitted from the compressor to the remote UDVM are sent via first the compressor dispatcher, followed by the transport layer and finally the decompressor dispatcher.
为了清晰起见，图中省略了调度器、应用程序和传输层。请注意，解压缩的消息通过解压缩器调度器传递给应用程序；此外，从压缩器传输到远程UDVM的SigComp消息首先通过压缩器调度器发送，然后是传输层，最后是解压缩器调度器。
The steps for requesting and returning feedback data are described in more detail below:
下面更详细地描述了请求和返回反馈数据的步骤：
1. The compressor that sends messages to Endpoint B piggybacks a feedback request onto a SigComp message.
1. 向端点B发送消息的压缩器将反馈请求装载到SigComp消息上。
2. When the application receives the decompressed message, it may return the compartment identifier for the message.
2. 当应用程序接收到解压缩的消息时，它可以返回消息的隔室标识符。
3. The UDVM in Endpoint B forwards the requested feedback data to the state handler.
3. 端点B中的UDVM将请求的反馈数据转发给状态处理程序。
4. If the UDVM can supply a valid compartment identifier, then the state handler forwards the feedback data to the appropriate compressor (namely the compressor sending to Endpoint A).
4. 如果UDVM可以提供有效的隔间标识符，那么状态处理程序将反馈数据转发给相应的压缩器（即发送到端点a的压缩器）。
5. The compressor returns the requested feedback data to Endpoint A piggybacked onto a SigComp message.
5. 压缩器将请求的反馈数据返回给端点A，并将其装载到SigComp消息中。
6. When the application receives the decompressed message, it may return the compartment identifier for the message.
6. 当应用程序接收到解压缩的消息时，它可以返回消息的隔室标识符。
7. The UDVM in Endpoint A forwards the returned feedback data to the state handler.
7. 端点A中的UDVM将返回的反馈数据转发给状态处理程序。
8. If the UDVM can supply a valid compartment identifier, then the state handler forwards the feedback data to the appropriate compressor (namely the compressor sending to Endpoint B).
8. 如果UDVM可以提供有效的隔间标识符，那么状态处理程序将反馈数据转发给相应的压缩器（即发送到端点B的压缩器）。
9. The compressor makes use of the returned feedback data.
9. 压缩器利用返回的反馈数据。
The detailed role played by each entity in the transmission of feedback data is explained in subsequent chapters.
各实体在反馈数据传输中扮演的详细角色将在后续章节中解释。
An advantage of using a virtual machine for decompression is that almost all of the implementation flexibility lies in the SigComp compressors. When receiving SigComp messages an endpoint generally behaves in a predictable manner.
使用虚拟机进行解压缩的一个优点是，几乎所有的实现灵活性都在于SigComp压缩器。接收SigComp消息时，端点通常以可预测的方式运行。
Note however that endpoints implementing SigComp will typically have a wide range of capabilities, each offering a different amount of working memory, processing power etc. In order to support this wide variation in endpoint capabilities, the following parameters are provided to modify SigComp behavior when receiving SigComp messages:
但是，请注意，实现SigComp的端点通常具有广泛的功能，每个端点提供不同数量的工作内存、处理能力等。为了支持端点功能的广泛变化，提供了以下参数，以在接收SigComp消息时修改SigComp行为：
decompression_memory_size state_memory_size cycles_per_bit SigComp_version locally available state (a set containing 0 or more state items)
解压\内存\大小状态\内存\大小周期\每位SigComp \版本本地可用状态（包含0个或更多状态项的集合）
Each parameter has a minimum value that MUST be offered by all receiving SigComp endpoints. Moreover, endpoints MAY offer additional resources if available; these resources can be advertised to remote endpoints using the SigComp feedback mechanism.
每个参数都有一个必须由所有接收SigComp端点提供的最小值。此外，端点可以提供额外的资源（如果可用）；可以使用SigComp反馈机制将这些资源通告到远程端点。
Particular applications may also agree a-priori to offer additional resources as mandatory (e.g., SigComp for SIP offers a dictionary of common SIP phrases as a mandatory state item).
特定应用程序也可能事先同意提供额外的资源作为强制性资源（例如，SigComp for SIP提供了一个常见SIP短语字典作为强制性状态项）。
Each of the SigComp parameters is described in greater detail below.
下面将更详细地描述每个SigComp参数。
The decompression_memory_size parameter specifies the amount of memory available to decompress one SigComp message. (Note that the term "amount of memory" is used on a conceptual level in order to specify decompressor behavior and allow resource planning on the side of the compressor -- an implementation could require additional, bounded amounts of actual memory resources or could even organize its memory in a completely different way as long as this does not cause decompression failures where the conceptual model would not.) A portion of this memory is used to buffer a SigComp message before it is decompressed; the remainder is given to the UDVM. Note that the memory is allocated on a per-message basis and can be reclaimed after the message has been decompressed. All endpoints implementing SigComp MUST offer a decompression_memory_size of at least 2048 bytes.
解压缩内存大小参数指定可用于解压缩一条SigComp消息的内存量。（注意术语“内存量”在概念级别上使用，以指定解压器行为并允许在压缩器一侧进行资源规划——实现可能需要额外的、有限制的实际内存资源，甚至可能以完全不同的方式组织其内存，只要这不会导致解压失败概念模型不会。）此内存的一部分用于在解压前缓冲SigComp消息；剩余部分将被提供给UDVM。请注意，内存是按每条消息分配的，可以在消息解压缩后回收。实现SigComp的所有端点必须提供至少2048字节的解压缩内存大小。
The state_memory_size parameter specifies the number of bytes offered to a particular compartment for the creation of state. This parameter is set to 0 if the endpoint is stateless.
state_memory_size参数指定为创建状态提供给特定隔室的字节数。如果端点是无状态的，则此参数设置为0。
Unlike the other SigComp parameters, the state_memory_size is offered on a per-compartment basis and may vary for different compartments. The memory for a compartment is reclaimed when the application determines that the compartment is no longer required.
与其他SigComp参数不同，state_memory_大小是按每个隔室提供的，可能因不同隔室而异。当应用程序确定不再需要隔室时，会回收隔室的内存。
The cycles_per_bit parameter specifies the number of "UDVM cycles" available to decompress each bit in a SigComp message. Executing a UDVM instruction requires a certain number of UDVM cycles; a complete list of UDVM instructions and their cost in UDVM cycles can be found in Chapter 9. An endpoint MUST offer a minimum of 16 cycles_per_bit.
cycles_per_bit参数指定可用于解压缩SigComp消息中每个位的“UDVM循环”数。执行UDVM指令需要一定数量的UDVM周期；在第9章中可以找到UDVM指令及其在UDVM周期中的开销的完整列表。端点必须提供至少16个循环\u/位。
Each of the three parameter values MUST be chosen from the limited set given below, so that the parameters can be efficiently encoded for transmission using the SigComp feedback mechanism.
三个参数值中的每一个都必须从下面给出的有限集合中选择，以便可以使用SigComp反馈机制对参数进行有效编码以进行传输。
The cycles_per_bit parameter is encoded using 2 bits, whilst the decompression_memory_size and state_memory_size are both encoded using 3 bits. The bit encodings and their corresponding values are as follows:
cycles_per_bit参数使用2位编码，而解压缩_memory_size和状态_memory_size都使用3位编码。位编码及其对应值如下所示：
Encoding: cycles_per_bit: Encoding: state_memory_size (bytes):
编码：每位循环数：编码：状态内存大小（字节）：
00 16 000 0 01 32 001 2048 10 64 010 4096 11 128 011 8192 100 16384 101 32768 110 65536 111 131072
00 16 000 0 01 32 001 2048 10 64 010 4096 11 128 011 8192 100 16384 101 32768 110 65536 111 131072
The decompression_memory_size is encoded in the same manner as the state_memory_size, except that the bit pattern 000 cannot be used (as an endpoint cannot offer a decompression_memory_size of 0 bytes).
解压缩内存大小的编码方式与状态内存大小的编码方式相同，只是不能使用位模式000（因为端点不能提供0字节的解压缩内存大小）。
The SigComp_version parameter specifies whether only the basic version of SigComp is available, or whether an upgraded version is available offering additional instructions etc. Within the UDVM, it is available as a 2-byte value, generated by zero-extending the 1- byte SigComp_version parameter (i.e., the first byte of the 2-byte value is always zero).
SigComp_version参数指定是否只有SigComp的基本版本可用，或者是否有提供附加指令等的升级版本可用。在UDVM中，它作为2字节值可用，由零扩展1字节SigComp_version参数生成（即，2字节值的第一个字节始终为零）。
The basic version of SigComp is Version 0x01, which is the version described in this document.
SigComp的基本版本为0x01版本，即本文档中描述的版本。
To ensure backwards compatibility, if a SigComp message is successfully decompressed by Version 0x01 of SigComp then it will be successfully decompressed on upgraded versions. Similarly, if the message triggers a manual decompression failure (see Section 8.7), then it will also continue to do so.
为确保向后兼容性，如果SigComp消息由版本0x01的SigComp成功解压缩，则它将在升级版本上成功解压缩。类似地，如果消息触发手动解压缩失败（参见第8.7节），那么它也将继续这样做。
However, messages that cause an unexpected decompression failure on Version 0x01 of SigComp may be successfully decompressed by upgraded versions.
但是，升级版本可能会成功解压缩导致SigComp版本0x01出现意外解压缩失败的消息。
The simplest way to upgrade SigComp in a backwards-compatible manner is to add additional UDVM instructions, as this will not affect the decompression of SigComp messages compatible with Version 0x01. Reserved addresses in the UDVM memory (Useful Values, see Section 7.2) may also be assigned values in future versions of SigComp.
以向后兼容的方式升级SigComp的最简单方法是添加额外的UDVM指令，因为这不会影响与版本0x01兼容的SigComp消息的解压缩。UDVM内存中的保留地址（有用值，见第7.2节）也可以在未来版本的SigComp中分配值。
A SigComp state item is an item of data that is retained between SigComp messages. State items can be retrieved and loaded into the UDVM memory as part of the decompression process, often significantly improving the compression ratio as the same information does not have to be uploaded on a per-message basis.
SigComp状态项是在SigComp消息之间保留的数据项。作为解压缩过程的一部分，可以检索状态项并将其加载到UDVM内存中，这通常会显著提高压缩比，因为不必按每条消息上载相同的信息。
Each endpoint maintains a set of state items where every item is composed of the following information:
每个端点维护一组状态项，其中每个项由以下信息组成：
Name: Type of data:
名称：数据类型：
state_identifier 20-byte value state_length 2-byte value state_address 2-byte value state_instruction 2-byte value minimum_access_length 2-byte value from 6 to 20 inclusive state_value String of state_length consecutive bytes
状态\u标识符20字节值状态\u长度2字节值状态\u地址2字节值状态\u指令2字节值最小值\u访问\u长度2字节值从6到20包含状态\u长度连续字节的值字符串
State items are typically created at an endpoint upon successful decompression of a SigComp message. The remote compressor sending the message makes a state creation request by invoking the appropriate UDVM instruction, and the state is saved once permission is granted by the application.
状态项通常在成功解压缩SigComp消息后在端点处创建。发送消息的远程压缩器通过调用适当的UDVM指令发出状态创建请求，并且一旦应用程序授予权限，就会保存状态。
However, an endpoint MAY also wish to offer a set of locally available state items that have not been uploaded as part of a SigComp message. For example it might offer well-known decompression algorithms, dictionaries of common phrases used in a specific signaling protocol, etc.
但是，端点也可能希望提供一组本地可用的状态项，这些状态项尚未作为SigComp消息的一部分上载。例如，它可能提供众所周知的解压算法、特定信令协议中使用的常用短语词典等。
Since these state items are established locally without input from a remote endpoint, they are most useful if publicly documented so that a wide collection of remote endpoints can determine the data contained in each state item and how it may be used. Further Internet Documents and RFCs may be published to describe particular locally available state items.
由于这些状态项是在本地建立的，没有来自远程端点的输入，因此如果公开记录这些状态项，以便远程端点的广泛集合可以确定每个状态项中包含的数据以及如何使用这些状态项，则这些状态项是最有用的。可能会发布更多的互联网文件和RFC，以描述特定的当地可用的州项目。
Although there are no locally available state items that are mandatory for every SigComp endpoint, certain state items can be made mandatory in a specific environment (e.g., the dictionary of common phrases for a specific signaling protocol could be made mandatory for that signaling protocol's usage of SigComp). Also, remote endpoints can indicate their interest in receiving a list of some of the state items available locally at an endpoint using the SigComp feedback mechanism.
尽管没有对每个SigComp端点强制的本地可用状态项，但某些状态项可以在特定环境中强制设置（例如，对于该信令协议的SigComp使用，特定信令协议的公共短语字典可以强制设置）。此外，远程端点可以表示他们有兴趣使用SigComp反馈机制接收端点本地可用的一些状态项的列表。
It is a matter of local decision for an endpoint what items of locally available state it advertises; this decision has no influence on interoperability, but may increase or decrease the efficiency of the compression achievable between the endpoints.
端点的本地决定是它所宣传的本地可用状态的项目；此决定对互操作性没有影响，但可能会提高或降低端点之间可实现的压缩效率。
This chapter defines the behavior of the compressor and decompressor dispatcher. The function of these entities is to provide an interface between SigComp and its environment, minimizing the effort needed to integrate SigComp into an existing protocol stack.
本章定义了压缩机和解压缩调度器的行为。这些实体的功能是提供SigComp与其环境之间的接口，最大限度地减少将SigComp集成到现有协议栈中所需的工作量。
The compressor dispatcher receives messages from the application and passes the compressed version of each message to the transport layer.
compressor dispatcher从应用程序接收消息，并将每个消息的压缩版本传递给传输层。
Note that SigComp invokes compressors on a per-compartment basis, so when the application provides a message to be compressed it must also provide a compartment identifier. The compressor dispatcher forwards the application message to the correct compressor based on the compartment identifier (invoking a new compressor if a new compartment identifier is encountered). The compressor returns a SigComp message that can be passed to the transport layer.
注意，SigComp以每个隔室为基础调用压缩器，因此当应用程序提供要压缩的消息时，它还必须提供隔室标识符。压缩机调度器根据腔室标识符将应用程序消息转发给正确的压缩机（如果遇到新的腔室标识符，则调用新的压缩机）。压缩器返回可以传递到传输层的SigComp消息。
Additionally, the application should indicate to the compressor dispatcher when it wishes to close a particular compartment, so that the resources taken by the corresponding compressor can be reclaimed.
此外，应用程序应向压缩机调度员指示何时关闭特定隔间，以便回收相应压缩机占用的资源。
The decompressor dispatcher receives messages from the transport layer and passes the decompressed version of each message to the application.
解压缩调度器从传输层接收消息，并将每个消息的解压缩版本传递给应用程序。
To ensure that SigComp can run over an unsecured transport layer, the decompressor dispatcher invokes a new instance of the UDVM for each new SigComp message. Resources for the UDVM are released as soon as the message has been decompressed.
为了确保SigComp可以在不安全的传输层上运行，解压缩程序调度器为每个新的SigComp消息调用一个新的UDVM实例。UDVM的资源将在消息解压缩后立即释放。
The dispatcher MUST NOT make more than one SigComp message available to a given instance of the UDVM. In particular, the dispatcher MUST NOT concatenate two SigComp messages to form a single message.
dispatcher不能为UDVM的给定实例提供多条SigComp消息。特别是，调度器不得将两条SigComp消息连接在一起形成一条消息。
Once the UDVM has been invoked it is initialized using the SigComp message of Chapter 7. The message is then decompressed by the UDVM, returned to the decompressor dispatcher, and passed on to the receiving application. Note that the UDVM has no awareness of whether the underlying transport is message-based or stream-based, and so it always outputs decompressed data as a stream. It is the responsibility of the dispatcher to provide the decompressed message to the application in the expected form (i.e., as a stream or as a distinct, bounded message). The dispatcher knows that the end of a decompressed message has been reached when the UDVM instruction END-MESSAGE is invoked (see Section 9.4.9).
调用UDVM后，使用第7章的SigComp消息对其进行初始化。然后，UDVM对消息进行解压缩，将其返回给解压缩程序调度器，并将其传递给接收应用程序。注意，UDVM不知道底层传输是基于消息的还是基于流的，因此它总是将解压缩的数据作为流输出。dispatcher负责以预期的形式（即，作为流或独特的、有界的消息）向应用程序提供解压缩后的消息。当调用UDVM指令end-message时，调度器知道已到达解压缩消息的结尾（请参阅第9.4.9节）。
For a stream-based transport, two strategies are therefore possible for the decompressor dispatcher:
因此，对于基于流的传输，解压缩调度器可以采用两种策略：
1) The dispatcher collects a complete SigComp message and then invokes the UDVM. The advantage is that, even in implementations that have multiple incoming compressed streams, only one instance of the UDVM is ever required.
1) dispatcher收集完整的SigComp消息，然后调用UDVM。优点是，即使在具有多个传入压缩流的实现中，也只需要一个UDVM实例。
2) The dispatcher collects the SigComp header (see Section 7) and invokes the UDVM; the UDVM stays active while the rest of the message arrives. The advantage is that there is no need to buffer up the rest of the message; the message can be decompressed as it arrives, and any decompressed output can be relayed to the application immediately.
2) 调度器收集SigComp头（参见第7节）并调用UDVM；当消息的其余部分到达时，UDVM保持活动状态。优点是不需要缓冲消息的其余部分；消息到达时可以进行解压缩，任何解压缩的输出都可以立即转发到应用程序。
In general, which of the strategies is used is an implementation choice.
通常，使用哪种策略是一种实现选择。
However, the compressor may want to take advantage of strategy 2 by expecting that some of the application message is passed on to the application before the SigComp message is terminated, e.g., by keeping the UDVM active while expecting the application to continuously receive decompressed output. This approach ("continuous mode") invalidates some assumptions of the SigComp security model and can only be used if the transport itself can provide the required protection against denial of service attacks. Also, since only strategy 2 works in this approach, the use of continuous mode requires previous agreement between the two endpoints.
然而，压缩器可能希望通过期望在SigComp消息终止之前将一些应用消息传递给应用来利用策略2，例如，通过保持UDVM活动，同时期望应用连续接收解压缩输出。这种方法（“连续模式”）使SigComp安全模型的某些假设无效，并且只有在传输本身能够提供针对拒绝服务攻击所需的保护时才能使用。此外，由于这种方法中只有策略2起作用，因此使用连续模式需要两个端点之间事先达成一致。
For a stream-based transport, the dispatcher delimits messages by parsing the compressed data stream for instances of 0xFF and taking the following actions:
对于基于流的传输，调度器通过解析0xFF实例的压缩数据流并采取以下操作来界定消息：
Occurs in data stream: Action:
在数据流中发生：操作：
0xFF 00 one 0xFF byte in the data stream 0xFF 01 same, but the next byte is quoted (could be another 0xFF) : : 0xFF 7F same, but the next 127 bytes are quoted 0xFF 80 to 0xFF FE (reserved for future standardization) 0xFF FF end of SigComp message
0xFF 00数据流0xFF 01中的一个0xFF字节相同，但下一个字节被引用（可以是另一个0xFF）：：0xFF 7F相同，但下一个127字节被引用为0xFF 80到0xFF FE（保留用于将来的标准化）0xFF FF结束SigComp消息
The combinations 0xFF01 to 0xFF7F are useful to limit the worst case expansion of the record marking scheme: the 1 (0xFF01) to 127 (0xFF7F) bytes following the byte combination are copied literally by the decompressor without taking any special action on 0xFF. (Note that 0xFF00 is just a special case of this, where zero following bytes are copied literally.)
0xFF01到0xFF7F的组合有助于限制记录标记方案的最坏情况扩展：字节组合后的1（0xFF01）到127（0xFF7F）字节由解压器逐字复制，而无需对0xFF执行任何特殊操作。（请注意，0xFF00只是这种情况的一个特例，下面的零字节是按字面复制的。）
In UDVM version 0x01, any occurrence of the combinations 0xFF80 to 0xFFFE that are not protected by quoting causes decompression failure; the decompressor SHOULD close the stream-based transport in this case.
在UDVM版本0x01中，任何未受引号保护的组合0xFF80到0xFFFE的出现都会导致解压缩失败；在这种情况下，解压缩程序应关闭基于流的传输。
Upon receiving a decompressed message the application may supply the dispatcher with a compartment identifier. Supplying this identifier grants permission for the following:
收到解压缩消息后，应用程序可向调度器提供隔间标识符。提供此标识符将授予以下权限：
1. Items of state accompanying the decompressed message can be saved using the state memory reserved for the specified compartment.
1. 可以使用为指定隔室保留的状态存储器保存解压缩消息附带的状态项。
2. The feedback data accompanying the decompressed message can be trusted sufficiently that it can be used when sending SigComp messages that relate to the compressor's equivalent for the compartment.
2. 可充分信任伴随解压消息的反馈数据，以便在发送与腔室压缩机等效物相关的SigComp消息时使用。
The dispatcher passes the compartment identifier to the UDVM, where it is used as per the END-MESSAGE instruction (see Section 9.4.9).
调度员将隔间标识符传递给UDVM，在UDVM中按照结束消息指令使用（见第9.4.9节）。
The application uses a suitable authentication mechanism to determine whether the decompressed message belongs to a legitimate compartment or not. If the application fails to authenticate the message with sufficient confidence to allow state to be saved or feedback data to be trusted, it supplies a "no valid compartment" error to the dispatcher and the UDVM is terminated without creating any state or forwarding any feedback data.
应用程序使用合适的身份验证机制来确定解压缩的消息是否属于合法隔室。如果应用程序未能以足够的可信度对消息进行身份验证，以允许保存状态或信任反馈数据，则会向调度器提供“无有效隔室”错误，UDVM将在不创建任何状态或转发任何反馈数据的情况下终止。
An important feature of SigComp is that decompression functionality is provided by a Universal Decompressor Virtual Machine (UDVM). This means that the compressor can choose any algorithm to generate compressed SigComp messages, and then upload bytecode for the corresponding decompression algorithm to the UDVM as part of the SigComp message.
SigComp的一个重要特性是，解压功能由通用解压器虚拟机（UDVM）提供。这意味着压缩器可以选择任何算法来生成压缩的SigComp消息，然后将相应解压缩算法的字节码作为SigComp消息的一部分上载到UDVM。
To help with the implementation and testing of a SigComp endpoint, further Internet Documents and RFCs may be published to describe particular compression algorithms.
为了帮助实施和测试SigComp端点，可能会发布更多的互联网文档和RFC来描述特定的压缩算法。
The overall requirement placed on the compressor is that of transparency, i.e., the compressor MUST NOT send bytecode which causes the UDVM to incorrectly decompress a given SigComp message.
对压缩器的总体要求是透明性，即压缩器不得发送字节码，这会导致UDVM错误地解压缩给定的SigComp消息。
The following more specific requirements are also placed on the compressor (they can be considered particular instances of the transparency requirement):
以下更具体的要求也适用于压缩机（可视为透明度要求的特殊实例）：
1. For robustness, it is recommended that the compressor supply some form of integrity check (not necessarily of cryptographic strength) over the application message to ensure that successful decompression has occurred. A UDVM instruction is provided for CRC verification; also, another instruction can be used to compute a SHA-1 cryptographic hash.
1. 为了健壮性，建议压缩器对应用程序消息提供某种形式的完整性检查（不一定是加密强度），以确保成功解压缩。提供UDVM指令用于CRC验证；此外，还可以使用另一条指令来计算SHA-1加密散列。
2. The compressor MUST ensure that the message can be decompressed using the resources available at the remote endpoint.
2. 压缩器必须确保可以使用远程端点上可用的资源对消息进行解压缩。
3. If the transport is message-based, then the compressor MUST map each application message to exactly one SigComp message.
3. 如果传输是基于消息的，则压缩器必须将每个应用程序消息映射到一条SigComp消息。
4. If the transport is stream-based but the application defines its own internal message boundaries, then the compressor SHOULD map each application message to exactly one SigComp message.
4. 如果传输是基于流的，但应用程序定义了自己的内部消息边界，那么压缩器应该将每个应用程序消息映射到一条SigComp消息。
Message boundaries should be preserved over a stream-based transport so that accidental or malicious damage to one SigComp message does not affect the decompression of subsequent messages.
应在基于流的传输上保留消息边界，以便对一条SigComp消息的意外或恶意损坏不会影响后续消息的解压缩。
Additionally, if the state handler passes some requested feedback to the compressor, then it SHOULD be returned in the next SigComp message generated by the compressor (unless the state handler passes some newer requested feedback before the older feedback has been sent, in which case the older feedback is deleted).
此外，如果状态处理程序将一些请求的反馈传递给压缩器，那么它应该在压缩器生成的下一条SigComp消息中返回（除非状态处理程序在发送旧反馈之前传递一些新请求的反馈，在这种情况下，删除旧反馈）。
If present, the requested feedback item SHOULD be copied unmodified into the returned_feedback_item field provided in the SigComp message. Note that there is no need to transmit any requested feedback item more than once.
如果存在，则应将请求的反馈项复制到SigComp消息中提供的返回的\u反馈\u项字段中，不作修改。请注意，无需多次传输任何请求的反馈项。
The compressor SHOULD also upload the local SigComp parameters to the remote endpoint, unless the endpoint has indicated that it does not wish to receive these parameters or the compressor determines that the parameters have already successfully arrived (see Section 5.1 for details of how this can be achieved). The SigComp parameters are uploaded to the UDVM memory at the remote endpoint as described in Section 9.4.9.
压缩器还应将本地SigComp参数上传到远程端点，除非端点已表示不希望接收这些参数，或者压缩器确定参数已成功到达（有关如何实现的详细信息，请参阅第5.1节）。如第9.4.9节所述，SigComp参数上传至远程端点处的UDVM内存。
A compressor MUST be certain that all of the data needed to decompress a SigComp message is available at the receiving endpoint. One way to ensure this is to send all of the needed information in every SigComp message (including bytecode to decompress the message). However, the compression ratio for this method will be relatively low.
压缩器必须确保对SigComp消息进行解压缩所需的所有数据在接收端点可用。确保这一点的一种方法是在每个SigComp消息中发送所有需要的信息（包括用于解压缩消息的字节码）。然而，这种方法的压缩比相对较低。
To obtain the best overall compression ratio the compressor needs to request the creation of new state items at the remote endpoint. The information saved in these state items can then be accessed by later SigComp messages, avoiding the need to upload the data on a per-message basis.
为了获得最佳的总体压缩比，压缩器需要请求在远程端点创建新的状态项。保存在这些状态项中的信息可由以后的SigComp消息访问，从而避免了按每条消息上载数据的需要。
Before the compressor can access saved state however, it must ensure that the SigComp message carrying the state creation request arrived successfully at the receiving endpoint. For a reliable transport (e.g., TCP or SCTP) this is guaranteed. For an unreliable transport however, the compressor must provide a suitable mechanism itself (see [RFC-3321] for further details).
但是，在压缩器可以访问保存的状态之前，它必须确保承载状态创建请求的SigComp消息成功到达接收端点。对于可靠的传输（如TCP或SCTP），这是有保证的。但是，对于不可靠的运输，压缩机本身必须提供合适的机构（更多详细信息，请参见[RFC-3321]）。
The compressor must also ensure that the state item it wishes to access has not been rejected due to a lack of state memory. This can be accomplished by checking the state_memory_size parameter using the SigComp feedback mechanism (see Section 9.4.9 for further details).
压缩器还必须确保其希望访问的状态项未因缺少状态内存而被拒绝。这可以通过使用SigComp反馈机制检查state_memory_size参数来实现（更多详细信息，请参见第9.4.9节）。
The compressor SHOULD make every effort to successfully compress an application message, but in certain cases this might not be possible (particularly if resources are scarce at the receiving endpoint). In this case a "compression failure" is called.
压缩器应尽一切努力成功压缩应用程序消息，但在某些情况下，这可能是不可能的（特别是在接收端点资源不足的情况下）。在这种情况下，称为“压缩故障”。
If a compression failure occurs then the compressor informs the dispatcher and takes no further action. The dispatcher MUST report this failure to the application so that it can try other methods to deliver the message.
如果发生压缩故障，则压缩机通知调度员，不再采取进一步的措施。dispatcher必须向应用程序报告此故障，以便它可以尝试其他方法来传递消息。
This chapter defines the behavior of the SigComp state handler. The function of the state handler is to retain information between received SigComp messages; it is the only SigComp entity that is capable of this function, and so it is of particular importance from a security perspective.
本章定义SigComp状态处理程序的行为。状态处理程序的功能是在收到的SigComp消息之间保留信息；它是唯一能够实现此功能的SigComp实体，因此从安全角度来看，它特别重要。
To provide security against the malicious insertion or modification of SigComp messages, a separate instance of the UDVM is invoked to decompress each message. This ensures that damaged SigComp messages do not prevent the successful decompression of subsequent valid messages.
为了防止恶意插入或修改SigComp消息，将调用单独的UDVM实例来解压缩每条消息。这可确保损坏的SigComp消息不会阻止后续有效消息的成功解压缩。
Note, however, that the overall compression ratio is often significantly higher if messages can be compressed relative to the information contained in previous messages. For this reason, it is possible to create state items for access when a later message is being decompressed. Both the creation and access of state are designed to be secure against malicious tampering with the compressed data. The UDVM can only create a state item when a complete message has been successfully decompressed and the application has returned a compartment identifier under which the state can be saved.
但是，请注意，如果消息可以相对于先前消息中包含的信息进行压缩，则总体压缩比通常会显著提高。由于这个原因，可以在以后的消息解压缩时创建状态项以供访问。状态的创建和访问都是为了防止恶意篡改压缩数据而设计的。UDVM只能在完整消息已成功解压缩且应用程序已返回可保存状态的分区标识符时创建状态项。
State access cannot be protected by relying on the application alone, since the authentication mechanism may require information from the decompressed message (which of course is not available until after the state has been accessed). Instead, SigComp protects state access by creating a state identifier that is a hash over the item of state to be retrieved. This state_identifier must be supplied to retrieve an item of state from the state handler.
仅依靠应用程序无法保护状态访问，因为身份验证机制可能需要来自解压缩消息的信息（当然，只有在访问状态之后才可用）。相反，SigComp通过创建状态标识符来保护状态访问，该状态标识符是要检索的状态项上的散列。必须提供此state_标识符才能从状态处理程序检索状态项。
Also note that state is not deleted when it is accessed. So even if a malicious sender manages to access some state information, subsequent messages compressed relative to this state can still be successfully decompressed.
还请注意，状态在被访问时不会被删除。因此，即使恶意发送者设法访问某些状态信息，相对于该状态压缩的后续消息仍然可以成功解压缩。
Each state item contains a state_identifier that is used to access the state. One state identifier can be supplied in the SigComp message header to initialize the UDVM (see Chapter 7); additional state items can be retrieved using the STATE-ACCESS instruction. The
每个状态项都包含一个用于访问状态的状态标识符。可以在SigComp消息头中提供一个状态标识符来初始化UDVM（参见第7章）；可以使用state-ACCESS指令检索其他状态项。这个
UDVM can also request the creation of a new state item by using the STATE-CREATE and END-MESSAGE instructions (see Chapter 9 for further details).
UDVM还可以使用state-CREATE和END-MESSAGE指令请求创建新的状态项（有关更多详细信息，请参阅第9章）。
The state handler manages state memory on a per-compartment basis. Each compartment can store state up to a certain state_memory_size (where the application may assign different values for the state_memory_size parameter to different compartments).
状态处理程序以每个隔室为基础管理状态内存。每个隔室可以存储高达特定状态\内存\大小的状态（其中应用程序可以为不同隔室分配不同的状态\内存\大小参数值）。
As well as storing the state items themselves, the state handler maintains a list of the state items created by a particular compartment and ensures that no compartment exceeds its allocated state_memory_size. For the purpose of calculation, each state item is considered to cost (state_length + 64) bytes.
除了存储状态项本身，状态处理程序还维护由特定隔室创建的状态项列表，并确保没有任何隔室超过其分配的状态内存大小。出于计算目的，每个状态项被视为成本（状态长度+64）字节。
Each instance of the UDVM can pass up to four state creation requests to the state handler, as well as up to four state free requests (the latter are requests to free the memory taken by a state item in a certain compartment). When the state handler receives a state creation request from the UDVM it takes the following steps:
UDVM的每个实例最多可以向状态处理程序传递四个状态创建请求，以及最多四个状态释放请求（后者是释放特定隔间中状态项占用的内存的请求）。当状态处理程序从UDVM接收到状态创建请求时，它将执行以下步骤：
1. The state handler MUST reject all state creation requests that are not accompanied by a valid compartment identifier, or if the compartment is allocated 0 bytes of state memory. Note that if a state creation request fails due to lack of state memory then it does not mean that the corresponding SigComp message is damaged; compressors will often make state creation requests in the first SigComp message of a compartment, before they have discovered the state_memory_size using the SigComp feedback mechanism.
1. 状态处理程序必须拒绝所有未附带有效分区标识符的状态创建请求，或者如果该分区分配了0字节的状态内存。请注意，如果状态创建请求因缺少状态内存而失败，则并不意味着相应的SigComp消息已损坏；压缩器通常会在使用SigComp反馈机制发现状态\内存\大小之前，在隔间的第一条SigComp消息中发出状态创建请求。
2. If the state creation request needs more state memory than the total state_memory_size for the compartment, the state handler deletes all but the first (state_memory_size - 64) bytes from the state_value. It sets the state_length to (state_memory_size - 64), and recalculates the state_identifier as defined in Section 9.4.9.
2. 如果状态创建请求需要的状态内存大于分区的总状态内存大小，则状态处理程序将从状态值中删除除第一个（状态内存大小-64）字节以外的所有字节。它将state_长度设置为（state_memory_size-64），并按照第9.4.9节中的定义重新计算state_标识符。
3. If the state creation request contains a state_identifier that already exists then the state handler checks whether the requested state item is identical to the established state item and counts the state creation request as successful if this is the case. If not then the state creation request is unsuccessful (although the probability that this will occur is vanishingly small).
3. 如果状态创建请求包含已存在的状态标识符，则状态处理程序将检查请求的状态项是否与已建立的状态项相同，如果是这种情况，则将状态创建请求计为成功。如果没有，则状态创建请求将不成功（尽管发生这种情况的概率非常小）。
4. If the state creation request exceeds the state memory allocated to the compartment, sufficient items of state created by the same compartment are freed until enough memory is available to accommodate the new state. When a state item is freed, it is removed from the list of states created by the compartment and the memory cost of the state item no longer counts towards the total cost for the compartment. Note, however, that identical state items may be created by several different compartments, so a state item must not be physically deleted unless the state handler determines that it is no longer required by any compartment.
4. 如果状态创建请求超过分配给该分区的状态内存，则会释放由同一分区创建的足够的状态项，直到有足够的内存来容纳新状态。释放状态项时，它将从隔室创建的状态列表中删除，并且状态项的内存成本不再计入隔室的总成本。但是，请注意，相同的状态项可能由几个不同的分区创建，因此状态项不能被物理删除，除非状态处理程序确定任何分区不再需要它。
5. The order in which the existing state items are freed is determined by the state_retention_priority, which is set when the state items are created. The state_retention_priority of 65535 is reserved for locally available states; these states must always be freed first. Apart from this special case, states with the lowest state_retention_priority are always freed first. In the event of a tie, then the state item created first in the compartment is also the first to be freed.
5. 现有状态项的释放顺序由创建状态项时设置的状态保留优先级决定。65535的状态保留优先级保留给本地可用状态；必须首先释放这些国家。除了这种特殊情况外，具有最低状态保留优先级的状态总是首先被释放。在平局的情况下，首先在隔间中创建的状态项也是第一个被释放的状态项。
The state_retention_priority is always stored on a per-compartment basis as part of the list of state items created by each compartment. In particular, the same state item might have several priority values if it has been created by several different compartments.
状态_保留_优先级始终以每个隔室为基础存储，作为每个隔室创建的状态项列表的一部分。特别是，如果同一状态项是由多个不同的分区创建的，则它可能具有多个优先级值。
Note that locally available state items (as described in Section 3.3.3) need not be mapped to any particular compartment. However, if they are created on a per-compartment basis, then they must not interfere with the state created at the request of the remote endpoint. The special state_retention_priority of 65535 is reserved for locally available state items to ensure that this is the case.
注意，本地可用状态项（如第3.3.3节所述）无需映射到任何特定隔间。但是，如果它们是基于每个隔室创建的，则它们不得干扰在远程端点请求时创建的状态。65535的特殊状态保留优先级是为本地可用的状态项保留的，以确保这种情况。
The UDVM may also explicitly request the state handler to free a specific state item in a compartment. In this case, the state handler deletes the state item from the list of state items created by the compartment (as before the state item itself must not be physically deleted unless the state handler determines that it is not longer required by any compartment).
UDVM还可以显式请求状态处理程序释放隔间中的特定状态项。在这种情况下，状态处理程序将从分区创建的状态项列表中删除状态项（与之前一样，状态项本身不能被物理删除，除非状态处理程序确定任何分区不再需要它）。
The application should indicate to the state handler when it wishes to close a particular compartment, so that the resources taken by the corresponding state can be reclaimed.
应用程序应该向状态处理程序指示何时希望关闭特定隔间，以便回收相应状态占用的资源。
The SigComp feedback mechanism allows feedback data to be received by a UDVM and forwarded via the state handler to the correct compressor.
SigComp反馈机制允许UDVM接收反馈数据，并通过状态处理程序转发到正确的压缩器。
Since this feedback data is retained between SigComp messages, it is considered to be part of the overall state and can only be forwarded if accompanied by a valid compartment identifier. If this is the case, then the state handler forwards the feedback data to the compressor responsible for sending messages that pertain to the peer compartment of the specified compartment.
由于此反馈数据保留在SigComp消息之间，因此它被视为整体状态的一部分，并且只有在带有有效隔室标识符的情况下才能转发。如果是这种情况，则状态处理程序将反馈数据转发给负责发送与指定隔室的对等隔室相关的消息的压缩器。
This chapter describes the format of the SigComp message and how the message is used to initialize the UDVM memory.
本章介绍SigComp消息的格式以及如何使用该消息初始化UDVM内存。
Note that the SigComp message is not copied into the UDVM memory as soon as it arrives; instead, the UDVM indicates when it requires compressed data using a specific instruction. It then pauses and waits for the information to be supplied before executing the next instruction. This means that the UDVM can begin to decompress a SigComp message before the entire message has been received.
注意，SigComp消息到达时不会立即复制到UDVM内存中；相反，UDVM使用特定指令指示何时需要压缩数据。然后，在执行下一条指令之前，它暂停并等待提供信息。这意味着UDVM可以在接收到整个消息之前开始解压缩SigComp消息。
A consequence of the above behavior is that when the UDVM is invoked, the size of the UDVM memory depends on whether the transport used to provide the SigComp message is stream-based or message-based. If the transport is message-based then sufficient memory must be available to buffer the entire SigComp message before it is passed to the UDVM. So if the message is n bytes long, then the UDVM memory size is set to (decompression_memory_size - n), up to a maximum of 65536 bytes.
上述行为的结果是，当调用UDVM时，UDVM内存的大小取决于用于提供SigComp消息的传输是基于流的还是基于消息的。如果传输是基于消息的，则必须有足够的内存来缓冲整个SigComp消息，然后再将其传递到UDVM。因此，如果消息长度为n字节，那么UDVM内存大小将设置为（decompression_memory_size-n），最大为65536字节。
If the transport is stream-based however, then a fixed-size input buffer is required to accommodate the stream, independently of the size of each SigComp message. So, for simplicity, the UDVM memory size is set to (decompression_memory_size / 2).
但是，如果传输是基于流的，则需要一个固定大小的输入缓冲区来容纳流，与每个SigComp消息的大小无关。因此，为了简单起见，将UDVM内存大小设置为（解压缩内存大小/2）。
As a separate instance of the UDVM is invoked on a per-message basis, each SigComp message must explicitly indicate its chosen decompression algorithm as well as any additional information that is needed to decompress the message (e.g., one or more previously received messages, a dictionary of common SIP phrases etc.). This information can either be uploaded as part of the SigComp message or retrieved from an item of state.
由于UDVM的一个单独实例是在每条消息的基础上调用的，因此每条SigComp消息必须明确指出其选择的解压缩算法以及解压缩该消息所需的任何附加信息（例如，一条或多条先前接收到的消息、通用SIP短语词典等）。此信息可以作为SigComp消息的一部分上载，也可以从状态项中检索。
A SigComp message takes one of two forms depending on whether it accesses a state item at the receiving endpoint. The two variants of a SigComp message are given in Figure 3. (The T-bit controls the format of the returned feedback item and is defined in Section 7.1.)
SigComp消息采用两种形式之一，具体取决于它是否在接收端点访问状态项。图3给出了SigComp消息的两种变体。（T位控制返回反馈项的格式，并在第7.1节中定义。）
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | len | | 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: returned feedback item : : returned feedback item :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | code_len |
: partial state identifier : +---+---+---+---+---+---+---+---+
| | | code_len | destination |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | len | | 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: returned feedback item : : returned feedback item :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | code_len |
: partial state identifier : +---+---+---+---+---+---+---+---+
| | | code_len | destination |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
Figure 3: Format of a SigComp message
图3:SigComp消息的格式
Decompression failure occurs if the SigComp message is too short to contain the expected fields (see Section 8.7 for further details).
如果SigComp消息太短，无法包含预期字段，则会发生解压缩失败（有关更多详细信息，请参阅第8.7节）。
The fields except for the "remaining SigComp message" are referred to as the "SigComp header" (note that this may include the uploaded UDVM bytecode).
除“剩余SigComp消息”之外的字段被称为“SigComp头”（注意，这可能包括上传的UDVM字节码）。
For both variants of the SigComp message, the T-bit is set to 1 whenever the SigComp message contains a returned feedback item. The format of the returned feedback item is illustrated in Figure 4.
对于SigComp消息的两种变体，每当SigComp消息包含返回的反馈项时，T位都设置为1。返回的反馈项的格式如图4所示。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | returned_feedback_field | | 1 | returned_feedback_length |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: returned_feedback_field :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | returned_feedback_field | | 1 | returned_feedback_length |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: returned_feedback_field :
| |
+---+---+---+---+---+---+---+---+
Figure 4: Format of returned feedback item
图4：返回的反馈项的格式
Note that the returned feedback length specifies the size of the returned feedback field (from 0 to 127 bytes). So the total size of the returned feedback item lies between 1 and 128 bytes.
请注意，返回的反馈长度指定了返回的反馈字段的大小（从0到127字节）。因此，返回的反馈项的总大小介于1到128字节之间。
The returned feedback item is not copied to the UDVM memory; instead, it is buffered until the UDVM has successfully decompressed the SigComp message. It is then forwarded to the state handler with the rest of the feedback data (see Section 9.4.9 for further details).
返回的反馈项未复制到UDVM内存中；相反，它被缓冲，直到UDVM成功解压缩SigComp消息。然后将其与其他反馈数据一起转发给状态处理程序（更多详细信息，请参见第9.4.9节）。
The len field of the SigComp message determines which fields follow the returned feedback item. If the len field is non-zero, then the SigComp message contains a state identifier to access a state item at the receiving endpoint. All state items include a 20-byte state identifier as per Section 3.3.3, but it is possible to transmit as few as 6 bytes from the identifier if the sender believes that this is sufficient to match a unique state item at the receiving endpoint.
SigComp消息的len字段确定返回的反馈项后面的字段。如果len字段为非零，则SigComp消息包含用于在接收端点访问状态项的状态标识符。根据第3.3.3节的规定，所有状态项都包括一个20字节的状态标识符，但如果发送方认为这足以匹配接收端点处的唯一状态项，则可以从该标识符发送至少6个字节。
The len field encodes the number of transmitted bytes as follows:
len字段对传输的字节数进行编码，如下所示：
Encoding: Length of partial state identifier
编码：部分状态标识符的长度
01 6 bytes 10 9 bytes 11 12 bytes
01 6字节10 9字节11 12字节
The partial state identifier is passed to the state handler, which compares it with the most significant bytes of the state_identifier in every currently stored state item. Decompression failure occurs if no state item is matched or if more than one state item is matched.
将部分状态标识符传递给状态处理程序，该处理程序将其与每个当前存储的状态项中的状态标识符的最高有效字节进行比较。如果没有匹配的状态项或匹配了多个状态项，则会发生解压缩失败。
Decompression failure also occurs if exactly one state item is matched but the state item contains a minimum_access_length greater than the length of the partial state identifier. This prevents especially sensitive state items from being accessed maliciously by brute force guessing of the state_identifier.
如果恰好匹配了一个状态项，但该状态项包含的最小访问长度大于部分状态标识符的长度，则也会发生解压缩失败。这可以防止通过强力猜测状态标识符恶意访问特别敏感的状态项。
If a state item is successfully accessed then the state_value byte string is copied into the UDVM memory beginning at state_address.
如果成功访问状态项，则状态值字节字符串将从状态地址开始复制到UDVM内存中。
The first 32 bytes of UDVM memory are then initialized to special values as illustrated in Figure 5.
然后将UDVM内存的前32个字节初始化为特殊值，如图5所示。
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_memory_size | 0 - 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit | 2 - 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SigComp_version | 4 - 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partial_state_ID_length | 6 - 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state_length | 8 - 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: reserved : 10 - 31
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_memory_size | 0 - 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit | 2 - 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SigComp_version | 4 - 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partial_state_ID_length | 6 - 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state_length | 8 - 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: reserved : 10 - 31
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Initializing Useful Values in UDVM memory
图5：初始化UDVM内存中的有用值
The first five 2-byte words are initialized to contain some values that might be useful to the UDVM bytecode (Useful Values). Note that these values are for information only and can be overwritten when executing the UDVM bytecode without any effect on the endpoint. The MSBs of each 2-byte word are stored preceding the LSBs.
前五个2字节字被初始化为包含一些可能对UDVM字节码有用的值（有用值）。请注意，这些值仅供参考，在执行UDVM字节码时可以覆盖，而不会对端点产生任何影响。每个2字节字的MSB存储在LSB之前。
Addresses 0 to 5 indicate the resources available to the receiving endpoint. The UDVM memory size is expressed in bytes modulo 2^16, so in particular, it is set to 0 if the UDVM memory size is 65536 bytes. The cycles_per_bit is expressed as a 2-byte integer taking the value 16, 32, 64 or 128. The SigComp_version is expressed as a 2-byte value as per Section 3.3.2.
地址0到5表示接收端点可用的资源。UDVM内存大小以字节模2^16表示，因此特别是，如果UDVM内存大小为65536字节，则将其设置为0。每_位的周期_表示为2字节整数，取值为16、32、64或128。根据第3.3.2节，SigComp_版本表示为2字节值。
Addresses 6 to 9 are initialized to the length of the partial state identifier, followed by the state_length from the retrieved state item. Both are expressed as 2-byte values.
地址6到9初始化为部分状态标识符的长度，后跟检索到的状态项的状态长度。两者都表示为2字节值。
Addresses 10 to 31 are reserved and are initialized to 0 for Version 0x01 of SigComp. Future versions of SigComp can use these locations for additional Useful Values, so a decompressor MUST NOT rely on these values being zero.
对于SigComp版本0x01，地址10到31是保留的，并初始化为0。未来版本的SigComp可以使用这些位置来获取其他有用的值，因此解压缩程序不能依赖这些值为零。
Any remaining addresses in the UDVM memory that have not yet been initialized MUST be set to 0.
UDVM内存中尚未初始化的任何剩余地址必须设置为0。
The UDVM then begins executing instructions at the memory address contained in state_instruction (which is part of the retrieved item of state). Note that the remaining SigComp message is held by the decompressor dispatcher until requested by the UDVM.
然后，UDVM开始在state_指令中包含的内存地址执行指令（它是检索到的状态项的一部分）。请注意，在UDVM请求之前，其余的SigComp消息由解压缩程序调度器保存。
(Note that the Useful Values are only set at UDVM startup; there is no special significance to this memory area afterwards. This means that the UDVM bytecode is free to use these locations for any other purpose a memory location might be used for; it just has to be aware they are not necessarily initialized to zero.)
（请注意，有用的值仅在UDVM启动时设置；之后对该内存区域没有特殊意义。这意味着UDVM字节码可以自由地将这些位置用于内存位置可能用于的任何其他用途；只需注意它们不必初始化为零。）
If the len field is set to 0 then the bytecode needed to decompress the SigComp message is supplied as part of the message itself. The 12-bit code_len field specifies the size of the uploaded UDVM bytecode (from 0 to 4095 bytes inclusive); eight most significant bits are in the first byte, followed by the four least significant bits in the most significant bits in the second byte. The remaining bits in the second byte are interpreted as a 4-bit destination field that specifies the starting memory address to which the bytecode is copied. The destination field is encoded as follows:
如果len字段设置为0，则将作为消息本身的一部分提供解压缩SigComp消息所需的字节码。12位代码_len字段指定上载的UDVM字节码的大小（从0到4095字节不等）；第一个字节中有八个最高有效位，第二个字节中最高有效位中有四个最低有效位。第二个字节中的剩余位被解释为4位目标字段，该字段指定字节码复制到的起始内存地址。目标字段编码如下：
Encoding: Destination address:
编码：目标地址：
0000 reserved
0001 2 * 64 = 128
0010 3 * 64 = 196
0011 4 * 64 = 256
: :
1111 16 * 64 = 1024
0000 reserved
0001 2 * 64 = 128
0010 3 * 64 = 196
0011 4 * 64 = 256
: :
1111 16 * 64 = 1024
Note that the encoding 0000 is reserved for future SigComp versions, and causes a decompression failure in Version 0x01.
请注意，编码0000保留用于将来的SigComp版本，并导致版本0x01中的解压缩失败。
The UDVM memory is initialized as per Figure 5, except that addresses 6 to 9 inclusive are set to 0 because no state item has been accessed. The UDVM then begins executing instructions at the memory address specified by the destination field. As above, the remaining SigComp message is held by the decompressor dispatcher until needed by the UDVM.
UDVM内存按照图5进行初始化，除了地址6到9（含6到9）被设置为0，因为没有访问状态项。然后，UDVM开始在目标字段指定的内存地址执行指令。如上所述，剩余的SigComp消息由解压器调度器保存，直到UDVM需要为止。
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM). The UDVM is a virtual machine much like the Java Virtual Machine but with a key difference: it is designed solely for the purpose of running decompression algorithms.
SigComp的解压功能由通用解压器虚拟机（UDVM）提供。UDVM是一个与Java虚拟机非常相似的虚拟机，但有一个关键区别：它的设计完全是为了运行解压缩算法。
The motivation for creating the UDVM is to provide flexibility when choosing how to compress a given application message. Rather than picking one of a small number of pre-negotiated algorithms, the compressor implementer has the freedom to select an algorithm of their choice. The compressed data is then combined with a set of UDVM instructions that allow the original data to be extracted, and the result is outputted as a SigComp message. Since the UDVM is optimized specifically for running decompression algorithms, the code size of a typical algorithm is small (often sub 100 bytes). Moreover, the UDVM approach does not add significant extra processing or memory requirements compared to running a fixed preprogrammed decompression algorithm.
创建UDVM的动机是在选择如何压缩给定的应用程序消息时提供灵活性。压缩器实现者可以自由选择自己选择的算法，而不是从少数预先协商的算法中选择一个。然后将压缩数据与一组UDVM指令组合，这些指令允许提取原始数据，并将结果作为SigComp消息输出。由于UDVM是专门为运行解压缩算法而优化的，因此典型算法的代码大小很小（通常小于100字节）。此外，与运行固定的预编程解压缩算法相比，UDVM方法不会增加显著的额外处理或内存需求。
Figure 6 gives a detailed view of the interfaces between the UDVM and its environment.
图6给出了UDVM及其环境之间接口的详细视图。
+----------------+ +----------------+
| | Request compressed data | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide compressed data | |
| | | |
| | Output decompressed data | Decompressor |
| |-------------------------------->| dispatcher |
| | | |
| | Indicate end of message | |
| |-------------------------------->| |
| |<--------------------------------| |
| UDVM | Provide compartment identifier | |
| | +----------------+
| |
| | +----------------+
| | Request state information | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide state information | State |
| | | handler |
| | Make state creation request | |
| |-------------------------------->| |
| | Forward feedback information | |
+----------------+ +----------------+
+----------------+ +----------------+
| | Request compressed data | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide compressed data | |
| | | |
| | Output decompressed data | Decompressor |
| |-------------------------------->| dispatcher |
| | | |
| | Indicate end of message | |
| |-------------------------------->| |
| |<--------------------------------| |
| UDVM | Provide compartment identifier | |
| | +----------------+
| |
| | +----------------+
| | Request state information | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide state information | State |
| | | handler |
| | Make state creation request | |
| |-------------------------------->| |
| | Forward feedback information | |
+----------------+ +----------------+
Figure 6: Interfaces between the UDVM and its environment
图6:UDVM与其环境之间的接口
Note that once the UDVM has been initialized, additional compressed data and state information are only provided at the request of a specific UDVM instruction.
注意，一旦UDVM被初始化，额外的压缩数据和状态信息只在特定UDVM指令的请求下提供。
This chapter describes the basic features of the UDVM including the UDVM registers and the format of UDVM bytecode.
本章介绍UDVM的基本功能，包括UDVM寄存器和UDVM字节码的格式。
The UDVM registers are 2-byte words in the UDVM memory that have special tasks, for example specifying the location of the stack used by the CALL and RETURN instructions.
UDVM寄存器是UDVM内存中具有特殊任务的2字节字，例如指定调用和返回指令使用的堆栈位置。
The UDVM registers are illustrated in Figure 7.
UDVM寄存器如图7所示。
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_left | 64 - 65
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_right | 66 - 67
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| input_bit_order | 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stack_location | 70 - 71
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_left | 64 - 65
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_right | 66 - 67
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| input_bit_order | 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stack_location | 70 - 71
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Memory addresses of the UDVM registers
图7:UDVM寄存器的内存地址
The MSBs of each register are always stored before the LSBs. So, for example, the MSBs of byte_copy_left are stored at Address 64 whilst the LSBs are stored at Address 65.
每个寄存器的MSB始终存储在LSB之前。因此，例如，字节_copy_left的MSB存储在地址64，而LSB存储在地址65。
The use of each UDVM register is defined in the following sections.
每个UDVM寄存器的使用在以下部分中定义。
(Note that the UDVM registers start at Address 64, that is 32 bytes after the area reserved for Useful Values. The intention is that the gap, i.e., the area between Address 32 and Address 63, will often be used as scratch-pad memory that is guaranteed to be zero at UDVM startup and is efficiently addressable in operand types reference ($) and multitype (%).)
（请注意，UDVM寄存器从地址64开始，即在为有用值保留的区域后32个字节。其目的是，间隙，即地址32和地址63之间的区域，通常将用作暂存板内存，保证在UDVM启动时为零，并在操作数类型引用（$）中有效寻址。）和多类型（%））
The decompressor dispatcher stores the compressed data from the SigComp message before it is requested by the UDVM via one of the INPUT instructions. When the UDVM bytecode is first executed, the dispatcher contains the remaining SigComp message after the header has been used to initialize the UDVM as per Chapter 7.
在UDVM通过输入指令之一请求压缩数据之前，解压缩程序调度器存储来自SigComp消息的压缩数据。当第一次执行UDVM字节码时，调度器将在根据第7章使用头初始化UDVM后包含剩余的SigComp消息。
Note that the INPUT-BITS and INPUT-HUFFMAN instructions retrieve a stream of individual compressed bits from the dispatcher. To provide bitwise compatibility with various well-known compression algorithms, the input_bit_order register can modify the order in which individual bits are passed within a byte.
请注意，INPUT-BITS和INPUT-HUFFMAN指令从dispatcher检索单个压缩位流。为了提供与各种众所周知的压缩算法的逐位兼容性，输入位顺序寄存器可以修改单个位在一个字节内的传递顺序。
The input_bit_order register contains the following three flags:
输入位顺序寄存器包含以下三个标志：
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |F|H|P| 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |F|H|P| 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The P-bit controls the order in which bits are passed from the dispatcher to the INPUT instructions. If set to 0, it indicates that the bits within an individual byte are passed to the INPUT instructions in MSB to LSB order. If it is set to 1, the bits are passed in LSB to MSB order.
P位控制位从调度程序传递到输入指令的顺序。如果设置为0，则表示单个字节内的位按MSB到LSB顺序传递给输入指令。如果设置为1，则位按LSB到MSB的顺序传递。
Note that the input_bit_order register cannot change the order in which the bytes themselves are passed to the INPUT instructions (bytes are always passed in the same order as they occur in the SigComp message).
请注意，输入位顺序寄存器无法更改字节本身传递给输入指令的顺序（字节的传递顺序始终与SigComp消息中出现的顺序相同）。
The following diagram illustrates the order in which bits are passed to the INPUT instructions for both cases:
下图说明了两种情况下向输入指令传递位的顺序：
MSB LSB MSB LSB MSB LSB MSB LSB
MSB LSB MSB LSB MSB LSB MSB LSB LSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 2 3 4 5 6 7|8 9 ... | |7 6 5 4 3 2 1 0| ... 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 2 3 4 5 6 7|8 9 ... | |7 6 5 4 3 2 1 0| ... 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Byte 0 Byte 1 Byte 0 Byte 1
字节0字节1字节0字节1
P = 0 P = 1
P=0 P=1
Note that after one or more INPUT instructions the dispatcher may hold a fraction of a byte (what used to be the LSBs if P = 0, or, the MSBs, if P = 1). If an INPUT instruction is encountered and the P-bit has changed since the last INPUT instruction, any fraction of a byte still held by the dispatcher MUST be discarded (even if the INPUT instruction requests zero bits). The first bit passed to the INPUT instruction is taken from the subsequent byte.
请注意，在一条或多条输入指令之后，调度程序可能会保留一小部分字节（如果P=0，则为LSB；如果P=1，则为MSB）。如果遇到一条输入指令，并且P位自上一条输入指令以来发生了更改，则必须丢弃调度程序仍保留的字节的任何部分（即使输入指令请求零位）。传递到输入指令的第一位取自后续字节。
When an INPUT instruction requests n bits of compressed data, it interprets the received bits as an integer between 0 and 2^n - 1. The F-bit and the H-bit specify whether the bits in these integers are considered to arrive in MSB to LSB order (bit set to 0) or in LSB to MSB order (bit set to 1).
当输入指令请求n位压缩数据时，它将接收的位解释为0到2^n-1之间的整数。F位和H位指定这些整数中的位是按MSB到LSB顺序（位设置为0）还是按LSB到MSB顺序（位设置为1）到达。
If the F-bit is set to 0, the INPUT-BITS instruction interprets the received bits as arriving MSBs first, and if it is set to 1, it interprets the bits as arriving LSBs first. The H-bit performs the same function for the INPUT-HUFFMAN instruction. Note that it is possible to set these two bits to different values in order to use different bit orders for the two instructions (certain algorithms actually require this, e.g., DEFLATE [RFC-1951]). (Note that there are no special considerations for changing the F- or H-bit between INPUT instructions, unlike the discard rule for the P-bit described above.)
如果F位设置为0，则输入位指令将接收的位解释为首先到达的MSB，如果设置为1，则将位解释为首先到达的LSB。H位对INPUT-HUFFMAN指令执行相同的功能。注意，可以将这两个位设置为不同的值，以便对这两条指令使用不同的位顺序（某些算法实际上需要这样做，例如，DEFLATE[RFC-1951]）。（请注意，与上述P位的丢弃规则不同，在输入指令之间更改F位或H位没有特殊考虑。）
Decompression failure occurs if an INPUT-BITS or an INPUT-HUFFMAN instruction is encountered and the input_bit_order register does not lie between 0 and 7 inclusive.
如果遇到输入位或输入哈夫曼指令且输入位顺序寄存器不在0和7之间（包括0和7），则会发生解压缩失败。
Certain UDVM instructions make use of a stack of 2-byte words stored at the memory address specified by the 2-byte word stack_location. The stack contains the following words:
某些UDVM指令使用存储在2字节字堆栈位置指定的内存地址处的2字节字堆栈。堆栈包含以下单词：
Name: Starting memory address:
名称：起始内存地址：
stack_fill stack_location stack[0] stack_location + 2 stack[1] stack_location + 4 stack[2] stack_location + 6 : :
堆栈填充堆栈位置堆栈[0]堆栈位置+2堆栈[1]堆栈位置+4堆栈[2]堆栈位置+6:：
The notation stack_location is an abbreviation for the contents of the stack_location register, i.e., the 2-byte word at locations 70 and 71. The notation stack_fill is an abbreviation for the 2-byte word at stack_location and stack_location+1. Similarly, the notation stack[n] is an abbreviation for the 2-byte word at stack_location+2*n+2 and stack_location+2*n+3. (As always, the arithmetic is modulo 2^16.)
符号stack_location是stack_location寄存器内容的缩写，即位置70和71处的2字节字。符号stack_fill是stack_位置和stack_位置+1处2字节字的缩写。类似地，表示法stack[n]是stack_位置+2*n+2和stack_位置+2*n+3处的2字节字的缩写。（和往常一样，算术是模2^16。）
The stack is used by the CALL, RETURN, PUSH and POP instructions.
堆栈由调用、返回、推送和弹出指令使用。
"Pushing" a value on the stack is an abbreviation for copying the value to stack[stack_fill] and then increasing stack_fill by 1. CALL and PUSH push values on the stack.
“推送”堆栈上的值是将值复制到堆栈[stack_fill]，然后将stack_fill增加1的缩写。在堆栈上调用和推送值。
"Popping" a value from the stack is an abbreviation for decreasing stack_fill by 1, and then using the value stored in stack[stack_fill]. Decompression failure occurs if stack_fill is zero at the commencement of a popping operation. POP and RETURN pop values from the stack.
“弹出”堆栈中的值是将堆栈填充减少1，然后使用存储在堆栈中的值[stack_fill]的缩写。如果在弹出操作开始时堆栈填充为零，则会发生解压缩失败。弹出并从堆栈返回弹出值。
For both of these abstract operations, the UDVM first takes note of the current value of stack_location and uses this value for both sub-operations (accessing the stack and manipulating stack_fill), i.e., overwriting stack_location in the course of the operation is inconsequential for the operation.
对于这两个抽象操作，UDVM首先注意到stack_location的当前值，并将该值用于两个子操作（访问堆栈和操作堆栈_填充），即，在操作过程中覆盖堆栈_位置对操作来说无关紧要。
A number of UDVM instructions require a string of bytes to be copied to and from areas of the UDVM memory. This section defines how the byte copying operation should be performed.
许多UDVM指令需要在UDVM内存区域中复制一个字节字符串。本节定义应如何执行字节复制操作。
The string of bytes is copied in ascending order of memory address, respecting the bounds set by byte_copy_left and byte_copy_right. More precisely, if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows:
字节串按照内存地址的升序进行复制，与byte_copy_left和byte_copy_right设置的边界有关。更准确地说，如果一个字节从地址m复制/复制到地址m，则下一个字节从地址n复制/复制到地址n，其中n的计算如下：
Set k := m + 1 (modulo 2^16)
If k = byte_copy_right then set n := byte_copy_left, else set n := k
Set k := m + 1 (modulo 2^16)
If k = byte_copy_right then set n := byte_copy_left, else set n := k
Decompression failure occurs if a byte is copied from/to an address beyond the UDVM memory.
如果将字节从UDVM内存之外的地址复制/复制到UDVM内存之外的地址，则会发生解压缩失败。
Note that the string of bytes is copied one byte at a time. In particular, some of the later bytes to be copied may themselves have been written into the UDVM memory by the byte copying operation currently being performed.
请注意，字节字符串一次复制一个字节。特别是，稍后要复制的一些字节本身可能已通过当前正在执行的字节复制操作写入UDVM内存。
Equally, it is possible for a byte copying operation to overwrite the instruction that invoked the byte copy. If this occurs, then the byte copying operation MUST be completed as if the original instruction were still in place in the UDVM memory (this also applies if byte_copy_left or byte_copy_right are overwritten).
同样，字节复制操作也可能覆盖调用字节复制的指令。如果发生这种情况，则必须完成字节复制操作，就像原始指令仍在UDVM内存中一样（如果字节左复制或字节右复制被覆盖，这也适用）。
Byte copying is used by the following UDVM instructions:
字节复制由以下UDVM指令使用：
SHA-1, COPY, COPY-LITERAL, COPY-OFFSET, MEMSET, INPUT-BYTES, STATE-ACCESS, OUTPUT, END-MESSAGE
SHA-1、复制、复制文字、复制偏移量、MEMSET、输入字节、状态访问、输出、结束消息
Each of the UDVM instructions in a piece of UDVM bytecode is represented by a single byte, followed by 0 or more bytes containing the operands required by the instruction.
一段UDVM字节码中的每个UDVM指令都由一个字节表示，后跟0个或更多包含指令所需操作数的字节。
During instruction execution, conceptually the UDVM first fetches the first byte of the instruction, determines the number and types of operands required for this instruction, and then decodes all the operands in sequence before starting to act on the instruction. (Note that the UDVM instructions have been designed in such a way that this sequence remains conceptual in those cases where it would result in an unreasonable burden on the implementation.)
在指令执行过程中，从概念上讲，UDVM首先获取指令的第一个字节，确定此指令所需的操作数和类型，然后在开始对指令执行操作之前按顺序解码所有操作数。（请注意，UDVM指令的设计方式是，在可能对实现造成不合理负担的情况下，此序列仍然是概念性的。）
To reduce the size of typical UDVM bytecode, each operand for a UDVM instruction is compressed using variable-length encoding. The aim is to store more common operand values using fewer bytes than rarely occurring values.
为了减小典型UDVM字节码的大小，UDVM指令的每个操作数都使用可变长度编码进行压缩。其目的是使用比很少出现的值更少的字节来存储更常见的操作数值。
Four different types of operand are available: the literal, the reference, the multitype and the address. Chapter 9 gives a complete list of UDVM instructions and the operand types that follow each instruction.
有四种不同类型的操作数可用：文字、引用、多类型和地址。第9章给出了UDVM指令的完整列表以及每条指令后面的操作数类型。
The UDVM bytecode for each operand type is illustrated in Figure 8 to Figure 10, together with the integer values represented by the bytecode.
图8至图10显示了每种操作数类型的UDVM字节码以及字节码表示的整数值。
Note that the MSBs in the bytecode are illustrated as preceding the LSBs. Also, any string of bits marked with k consecutive "n"s is to be interpreted as an integer N from 0 to 2^k - 1 inclusive (with the MSBs of n illustrated as preceding the LSBs).
请注意，字节码中的MSB如LSB前面所示。此外，任何标有k个连续“n”的位串都将被解释为从0到2^k-1（包括2^k-1）之间的整数n（在LSB之前说明的MSB为n）。
The decoded integer value of the bytecode can be interpreted in two ways. In some cases it is taken to be the actual value of the operand. In other cases it is taken to be a memory address at which the 2-byte operand value can be found (MSBs found at the specified address, LSBs found at the following address). The latter cases are denoted by memory[X] where X is the address and memory[X] is the 2- byte value starting at Address X.
字节码的解码整数值可以用两种方式解释。在某些情况下，它被视为操作数的实际值。在其他情况下，它被视为可以找到2字节操作数值的内存地址（在指定地址找到MSB，在以下地址找到LSB）。后一种情况由memory[X]表示，其中X是地址，memory[X]是从地址X开始的2字节值。
The simplest operand type is the literal (#), which encodes a constant integer from 0 to 65535 inclusive. A literal operand may require between 1 and 3 bytes depending on its value.
最简单的操作数类型是literal（#），它对0到65535（含0到65535）之间的常量整数进行编码。文字操作数可能需要1到3个字节，具体取决于其值。
Bytecode: Operand value: Range:
字节码：操作数值：范围：
0nnnnnnn N 0 - 127 10nnnnnn nnnnnnnn N 0 - 16383 11000000 nnnnnnnn nnnnnnnn N 0 - 65535
0-127 10nnnnnnnnnnnnnnnnnnnnnn 0-16383 11000000 nnnnnnnnnnnnnnnnnn 0-65535
Figure 8: Bytecode for a literal (#) operand
图8：文字（#）操作数的字节码
The second operand type is the reference ($), which is always used to access a 2-byte value located elsewhere in the UDVM memory. The bytecode for a reference operand is decoded to be a constant integer from 0 to 65535 inclusive, which is interpreted as the memory address containing the actual value of the operand.
第二种操作数类型是引用（$），它始终用于访问UDVM内存中其他位置的2字节值。参考操作数的字节码被解码为0到65535（含0到65535）之间的常量整数，它被解释为包含操作数实际值的内存地址。
Bytecode: Operand value: Range:
字节码：操作数值：范围：
0nnnnnnn memory[2 * N] 0 - 65535
10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535
11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
0nnnnnnn memory[2 * N] 0 - 65535
10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535
11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
Figure 9: Bytecode for a reference ($) operand
图9：引用（$）操作数的字节码
Note that the range of a reference operand is always 0 - 65535 independently of how many bits are used to encode the reference, because the operand always references a 2-byte value in the memory.
请注意，引用操作数的范围始终为0-65535，与用于对引用进行编码的位数无关，因为操作数始终引用内存中的2字节值。
The third kind of operand is the multitype (%), which can be used to encode both actual values and memory addresses. The multitype operand also offers efficient encoding for small integer values (both positive and negative) and for powers of 2.
第三种操作数是multitype（%），可用于对实际值和内存地址进行编码。多类型操作数还为小整数值（正数和负数）和2的幂提供高效编码。
Bytecode: Operand value: Range:
字节码：操作数值：范围：
00nnnnnn N 0 - 63
01nnnnnn memory[2 * N] 0 - 65535
1000011n 2 ^ (N + 6) 64 , 128
10001nnn 2 ^ (N + 8) 256 , ... , 32768
111nnnnn N + 65504 65504 - 65535
1001nnnn nnnnnnnn N + 61440 61440 - 65535
101nnnnn nnnnnnnn N 0 - 8191
110nnnnn nnnnnnnn memory[N] 0 - 65535
10000000 nnnnnnnn nnnnnnnn N 0 - 65535
10000001 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
00nnnnnn N 0 - 63
01nnnnnn memory[2 * N] 0 - 65535
1000011n 2 ^ (N + 6) 64 , 128
10001nnn 2 ^ (N + 8) 256 , ... , 32768
111nnnnn N + 65504 65504 - 65535
1001nnnn nnnnnnnn N + 61440 61440 - 65535
101nnnnn nnnnnnnn N 0 - 8191
110nnnnn nnnnnnnn memory[N] 0 - 65535
10000000 nnnnnnnn nnnnnnnn N 0 - 65535
10000001 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
Figure 10: Bytecode for a multitype (%) operand
图10：多类型（%）操作数的字节码
The fourth operand type is the address (@). This operand is decoded as a multitype operand followed by a further step: the memory address of the UDVM instruction containing the address operand is added to obtain the correct operand value. So if the operand value from Figure 10 is D then the actual operand value of an address is calculated as follows:
第四个操作数类型是地址（@）。此操作数被解码为多类型操作数，然后执行下一步：添加包含地址操作数的UDVM指令的内存地址以获得正确的操作数值。因此，如果图10中的操作数值为D，则地址的实际操作数值计算如下：
operand_value = (memory_address_of_instruction + D) modulo 2^16
operand_value = (memory_address_of_instruction + D) modulo 2^16
Address operands are always used in instructions that control program flow, because they ensure that the UDVM bytecode is position-independent code (i.e., it will run independently of where it is placed in the UDVM memory).
地址操作数始终用于控制程序流的指令中，因为它们确保UDVM字节码是位置独立的代码（即，它将独立于它在UDVM内存中的位置运行）。
Once the UDVM has been invoked it executes the instructions contained in its memory consecutively unless otherwise indicated (for example when the UDVM encounters a JUMP instruction). If the next instruction to be executed lies outside the available memory then decompression failure occurs (see Section 8.7).
调用UDVM后，除非另有指示，否则它将连续执行其内存中包含的指令（例如，当UDVM遇到跳转指令时）。如果要执行的下一条指令位于可用内存之外，则会发生解压缩失败（参见第8.7节）。
To ensure that a SigComp message cannot consume excessive processing resources, SigComp limits the number of "UDVM cycles" allocated to each message. The number of available UDVM cycles is initialized to 1000 plus the number of bits in the SigComp header (as described in Section 7); this sum is then multiplied by cycles_per_bit. Each time an instruction is executed the number of available UDVM cycles is decreased by the amount specified in Chapter 9. Additionally, if the UDVM successfully requests n bits of compressed data using one of the INPUT instructions then the number of available UDVM cycles is increased by n * cycles_per_bit once the instruction has been executed.
为确保SigComp消息不会消耗过多的处理资源，SigComp限制分配给每条消息的“UDVM周期”数。可用UDVM周期数初始化为1000加上SigComp头中的位数（如第7节所述）；然后将该总和乘以每个位的循环数。每次执行指令时，可用的UDVM周期数都会减少第9章中指定的数量。此外，如果UDVM使用其中一条输入指令成功请求n位压缩数据，则一旦指令被执行，可用UDVM周期数将增加n*cycles\u/位。
This means that the maximum number of UDVM cycles available for processing an n-byte SigComp message is given by the formula:
这意味着可用于处理n字节SigComp消息的最大UDVM周期数由以下公式给出：
maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
The reason that this total is not allocated to the UDVM when it is invoked is that the UDVM can begin to decompress a message that has only been partially received. So the total message size may not be known when the UDVM is initialized.
调用UDVM时未将此总数分配给UDVM的原因是UDVM可以开始解压缩仅部分接收到的消息。因此，在初始化UDVM时，可能不知道消息的总大小。
Note that the number of UDVM cycles MUST NOT be increased if a request for additional compressed data fails.
请注意，如果请求其他压缩数据失败，则不得增加UDVM周期数。
The UDVM stops executing instructions when it encounters an END-MESSAGE instruction or if decompression failure occurs (see Section 8.7 for further details).
UDVM在遇到结束消息指令或发生解压缩失败时停止执行指令（有关更多详细信息，请参阅第8.7节）。
If a compressed message given to the UDVM is corrupted (either accidentally or maliciously), then the UDVM may terminate with a decompression failure.
如果提供给UDVM的压缩消息已损坏（意外或恶意），则UDVM可能会因解压缩失败而终止。
Reasons for decompression failure include the following:
减压失败的原因包括：
1. A SigComp message contains an invalid header as per Chapter 7.
1. 根据第7章，SigComp消息包含无效标头。
2. A SigComp message is larger than the decompression_memory_size.
2. SigComp消息大于解压缩内存大小。
3. An instruction costs more than the number of remaining UDVM cycles.
3. 一条指令的成本高于剩余UDVM周期的数量。
4. The UDVM attempts to read from or write to a memory address beyond its memory size.
4. UDVM尝试读取或写入超出其内存大小的内存地址。
5. An unknown instruction is encountered.
5. 遇到未知指令。
6. An unknown operand is encountered.
6. 遇到未知操作数。
7. An instruction is encountered that cannot be processed successfully by the UDVM (for example a RETURN instruction when no CALL instruction has previously been encountered).
7. 遇到UDVM无法成功处理的指令（例如，以前未遇到调用指令时的返回指令）。
8. A request to access some state information fails.
8. 访问某些状态信息的请求失败。
9. A manual decompression failure is triggered using the DECOMPRESSION-FAILURE instruction.
9. 使用解压缩失败指令触发手动解压缩失败。
If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application.
如果在解压缩消息时发生解压缩失败，UDVM将通知调度程序，并且不采取进一步的操作。调度员有责任决定如何处理减压故障。通常，调度器应该丢弃压缩消息（如果传输是基于流的，则丢弃压缩流）和任何已输出但尚未传递到应用程序的解压缩数据。
The UDVM currently understands 36 instructions, chosen to support the widest possible range of compression algorithms with the minimum possible overhead.
UDVM目前可以理解36条指令，选择这些指令是为了以最小的开销支持尽可能广泛的压缩算法。
Figure 11 lists the different instructions and the bytecode values used to encode the instructions. The cost of each instruction in UDVM cycles is also given:
图11列出了不同的指令以及用于编码指令的字节码值。还给出了UDVM周期中每条指令的成本：
Instruction: Bytecode value: Cost in UDVM cycles:
说明：字节码值：UDVM周期中的成本：
DECOMPRESSION-FAILURE 0 1 AND 1 1 OR 2 1 NOT 3 1 LSHIFT 4 1 RSHIFT 5 1 ADD 6 1 SUBTRACT 7 1 MULTIPLY 8 1 DIVIDE 9 1 REMAINDER 10 1 SORT-ASCENDING 11 1 + k * (ceiling(log2(k)) + n) SORT-DESCENDING 12 1 + k * (ceiling(log2(k)) + n) SHA-1 13 1 + length LOAD 14 1 MULTILOAD 15 1 + n PUSH 16 1 POP 17 1 COPY 18 1 + length COPY-LITERAL 19 1 + length COPY-OFFSET 20 1 + length MEMSET 21 1 + length JUMP 22 1 COMPARE 23 1 CALL 24 1 RETURN 25 1 SWITCH 26 1 + n CRC 27 1 + length INPUT-BYTES 28 1 + length INPUT-BITS 29 1 INPUT-HUFFMAN 30 1 + n STATE-ACCESS 31 1 + state_length STATE-CREATE 32 1 + state_length STATE-FREE 33 1 OUTPUT 34 1 + output_length END-MESSAGE 35 1 + state_length
减压失败01和11或21不3 1升4升5加6减7乘8除9 1余数10 1排序升序11+k*（上限（log2（k））+n排序降序12 1+k*（上限（log2（k））+n）SHA-1+长度加载14+多加载15+n推送16+POP 17 1+长度复制文字19+长度复制偏移量20 1+长度内存集21+长度跳转22 1比较23 1调用24 1返回25 1开关26 1+n CRC 27 1+长度输入字节28 1+长度输入位29 1输入哈夫曼30 1+n状态访问31+状态长度状态创建32 1+状态长度状态自由33 1输出34 1+输出长度结束消息35 1+状态长度
Figure 11: UDVM instructions and corresponding bytecode values
图11:UDVM指令和相应的字节码值
Each UDVM instruction costs a minimum of 1 UDVM cycle. Certain instructions may cost additional cycles depending on the values of the instruction operands. Named variables in the cost expressions refer to the values of the instruction operands with these names.
每个UDVM指令至少花费1个UDVM周期。某些指令可能需要额外的周期，具体取决于指令操作数的值。代价表达式中的命名变量引用具有这些名称的指令操作数的值。
Note that for the SORT instructions, the formula ceiling(log2(k)) calculates the smallest value i such that k <= 2^i.
注意，对于排序指令，公式上限（log2（k））计算最小值i，使得k<=2^i。
The UDVM instruction set offers a mix of low-level and high-level instructions. The high-level instructions can all be emulated using combinations of low-level instructions, but given a choice it is generally preferable to use a single instruction rather than a large number of general-purpose instructions. The resulting bytecode will be more compact (leading to a higher overall compression ratio) and decompression will typically be faster because the implementation of the high-level instructions can be more easily optimized.
UDVM指令集提供低级和高级指令的混合。高级指令都可以使用低级指令的组合进行仿真，但如果有选择，通常最好使用单个指令，而不是大量通用指令。生成的字节码将更加紧凑（导致更高的整体压缩比），而解压通常会更快，因为高级指令的实现可以更容易地优化。
All instructions are encoded as a single byte to indicate the instruction type, followed by 0 or more bytes containing the operands required by the instruction. The instruction specifies which of the four operand types of Section 8.5 is used in each case. For example the ADD instruction is followed by two operands:
所有指令都编码为单个字节，以指示指令类型，后跟0个或更多字节，其中包含指令所需的操作数。该指令指定在每种情况下使用第8.5节中四种操作数类型中的哪一种。例如，ADD指令后跟两个操作数：
ADD ($operand_1, %operand_2)
加法（$Operator\u 1，%Operator\u 2）
When converted into bytecode the number of bytes required by the ADD instruction depends on the value of each operand, and whether the multitype operand contains the operand value itself or a memory address where the actual value of the operand can be found.
转换为字节码时，ADD指令所需的字节数取决于每个操作数的值，以及多类型操作数是包含操作数值本身还是包含可以找到操作数实际值的内存地址。
Each instruction is explained in more detail below.
下面将对每个说明进行更详细的解释。
Whenever the description of an instruction uses the expression "and then", the intended semantics is that the effect explained before "and then" is completed before work on the effect explained after the "and then" is commenced.
每当指令的描述使用“and then”表达式时，预期的语义是“and then”之前解释的效果在“and then”之后解释的效果工作开始之前完成。
The following instructions provide a number of mathematical operations including bit manipulation, arithmetic and sorting.
以下说明提供了许多数学运算，包括位操作、算术和排序。
The AND, OR, NOT, LSHIFT and RSHIFT instructions provide simple bit manipulation on 2-byte words.
AND、OR、NOT、LSHIFT和RSHIFT指令提供对2字节字的简单位操作。
AND ($operand_1, %operand_2) OR ($operand_1, %operand_2) NOT ($operand_1) LSHIFT ($operand_1, %operand_2) RSHIFT ($operand_1, %operand_2)
和（$Operator_1，%Operator_2）或（$Operator_1，%Operator_2）非（$Operator_1）LSHIFT（$Operator_1，%Operator_2）RSHIFT（$Operator_1，%Operator_2）
After the operation is complete, the value of the first operand is overwritten with the result. (Note that since this operand is a reference, it is the 2-byte word at the memory address specified by the operand that is overwritten.)
操作完成后，第一个操作数的值将被结果覆盖。（请注意，由于此操作数是引用，因此被覆盖的是操作数指定的内存地址处的2字节字。）
The precise definitions of LSHIFT and RSHIFT are given below. Note that m and n are the 2-byte values encoded by the operands, and that floor(x) calculates the largest integer not greater than x:
下面给出了升档和升档的精确定义。请注意，m和n是由操作数编码的2字节值，下限（x）计算不大于x的最大整数：
LSHIFT (m, n) := m * 2^n (modulo 2^16)
RSHIFT (m, n) := floor(m / 2^n)
LSHIFT (m, n) := m * 2^n (modulo 2^16)
RSHIFT (m, n) := floor(m / 2^n)
The ADD, SUBTRACT, MULTIPLY, DIVIDE and REMAINDER instructions perform arithmetic on 2-byte words.
加法、减法、乘法、除法和余数指令对2字节字执行算术运算。
ADD ($operand_1, %operand_2) SUBTRACT ($operand_1, %operand_2) MULTIPLY ($operand_1, %operand_2) DIVIDE ($operand_1, %operand_2) REMAINDER ($operand_1, %operand_2)
加（$Operator_1，%Operator_2）减（$Operator_1，%Operator_2）乘（$Operator_1，%Operator_2）除（$Operator_1，%Operator_2）余数（$Operator_1，%Operator_2）
After the operation is complete, the value of the first operand is overwritten with the result.
操作完成后，第一个操作数的值将被结果覆盖。
The precise definition of each instruction is given below:
每个指令的精确定义如下所示：
ADD (m, n) := m + n (modulo 2^16)
SUBTRACT (m, n) := m - n (modulo 2^16)
MULTIPLY (m, n) := m * n (modulo 2^16)
DIVIDE (m, n) := floor(m / n)
REMAINDER (m, n) := m - n * floor(m / n)
ADD (m, n) := m + n (modulo 2^16)
SUBTRACT (m, n) := m - n (modulo 2^16)
MULTIPLY (m, n) := m * n (modulo 2^16)
DIVIDE (m, n) := floor(m / n)
REMAINDER (m, n) := m - n * floor(m / n)
Decompression failure occurs if a DIVIDE or REMAINDER instruction encounters an operand_2 that is zero.
如果除法或余数指令遇到的操作数_2为零，则会发生解压缩失败。
The SORT-ASCENDING and SORT-DESCENDING instructions sort lists of 2- byte words.
升序排序和降序排序指令对2字节字的列表进行排序。
SORT-ASCENDING (%start, %n, %k) SORT-DESCENDING (%start, %n, %k)
升序排序（%start，%n，%k）降序排序（%start，%n，%k）
The start operand specifies the starting memory address of the block of data to be sorted.
起始操作数指定要排序的数据块的起始内存地址。
The block of data itself is divided into n lists each containing k 2-byte words. The SORT-ASCENDING instruction applies a certain permutation to the lists, such that the first list is sorted into ascending order (treating each 2-byte word as an unsigned integer). The same permutation is applied to all n lists, so lists other than the first will not necessarily be sorted into order.
数据块本身被分成n个列表，每个列表包含k个2字节的字。SORT-ASCENDING指令对列表应用某种排列，以便将第一个列表按升序排序（将每个2字节字视为无符号整数）。相同的排列适用于所有n个列表，因此除第一个列表之外的列表不一定按顺序排序。
In the case that two words have the same value, the original ordering of the list is preserved.
如果两个单词具有相同的值，则保留列表的原始顺序。
For example, the first list might contain a set of integers to be sorted whilst the second list might be used to keep track of where the integers appear in the sorted list:
例如，第一个列表可能包含一组要排序的整数，而第二个列表可能用于跟踪整数在排序列表中出现的位置：
Before sorting After sorting
排序前排序后
List 1 List 2 List 1 List 2
列表1列表2列表1列表2
8 1 1 2 1 2 1 3 1 3 3 4 3 4 8 1
8 1 1 2 1 2 1 3 1 3 3 4 3 4 8 1
The SORT-DESCENDING instruction behaves as above, except that the first list is sorted into descending order.
除第一个列表按降序排序外，SORT-DESCENDING指令的行为如上所述。
The SHA-1 instruction calculates a 20-byte SHA-1 hash [RFC-3174] over the specified area of UDVM memory.
SHA-1指令计算UDVM内存指定区域上的20字节SHA-1哈希[RFC-3174]。
SHA-1 (%position, %length, %destination)
SHA-1（%位置，%长度，%destination）
The position and length operands specify the starting memory address and the length of the byte string over which the SHA-1 hash is calculated. Byte copying rules are enforced as per Section 8.4.
位置和长度操作数指定起始内存地址和计算SHA-1哈希的字节字符串的长度。字节复制规则按照第8.4节执行。
The destination operand gives the starting address to which the resulting 20-byte hash will be copied. Byte copying rules are enforced as above.
目标操作数给出将生成的20字节哈希复制到的起始地址。字节复制规则如上所述。
The following instructions are used to set up the UDVM memory, and to copy byte strings from one memory location to another.
以下说明用于设置UDVM内存，并将字节字符串从一个内存位置复制到另一个内存位置。
The LOAD instruction sets a 2-byte word to a certain specified value. The format of a LOAD instruction is as follows:
LOAD指令将2字节字设置为特定的指定值。加载指令的格式如下所示：
LOAD (%address, %value)
加载（%address，%value）
The first operand specifies the starting address of a 2-byte word, whilst the second operand specifies the value to be loaded into this word. As usual, MSBs are stored before LSBs in the UDVM memory.
第一个操作数指定2字节字的起始地址，而第二个操作数指定要加载到此字中的值。通常，MSB存储在UDVM内存中LSB之前。
The MULTILOAD instruction sets a contiguous block of 2-byte words in the UDVM memory to specified values.
MULTILOAD指令将UDVM内存中的连续2字节字块设置为指定值。
MULTILOAD (%address, #n, %value_0, ..., %value_n-1)
多重加载（%address，#n，%value_0，，%value_n-1）
The first operand specifies the starting address of the contiguous 2-byte words, whilst the operands value_0 through to value_n-1 specify the values to load into these words (in the same order as they appear in the instruction).
第一个操作数指定连续2字节字的起始地址，而操作数值_0到值_n-1指定要加载到这些字中的值（与它们在指令中出现的顺序相同）。
Decompression failure occurs if the set of 2-byte words set by the instruction would overlap the memory locations held by the instruction (including its operands) itself, i.e., if the instruction would be self-modifying. (This restriction makes it simpler to implement MULTILOAD step-by-step instead of having to decode all operands before being able to copy data, as is implied by the conceptual model of instruction execution.)
如果指令设置的2字节字集与指令（包括其操作数）本身持有的内存位置重叠，即，如果指令是自修改的，则会发生解压缩失败。（这一限制使逐步实现多重加载变得更简单，而不必像指令执行的概念模型所暗示的那样，在能够复制数据之前解码所有操作数。）
The PUSH and POP instructions read from and write to the UDVM stack (as defined in Section 8.3).
从UDVM堆栈读取和写入的PUSH和POP指令（定义见第8.3节）。
PUSH (%value) POP (%address)
推送（%value）弹出（%address）
The PUSH instruction pushes the value specified by its operand on the stack.
PUSH指令将其操作数指定的值推送到堆栈上。
The POP instruction pops a value from the stack and then copies the value to the specified memory address. (Note that the expression "and then" implies that the copying of the value is inconsequential for the stack operation itself, which happens beforehand.)
POP指令从堆栈中弹出一个值，然后将该值复制到指定的内存地址。（请注意，表达式“and then”意味着值的复制对于堆栈操作本身是无关紧要的，而堆栈操作本身是事先发生的。）
See Section 8.3 for possible error conditions.
有关可能的错误情况，请参见第8.3节。
The COPY instruction is used to copy a string of bytes from one part of the UDVM memory to another.
COPY指令用于将字节字符串从UDVM内存的一部分复制到另一部分。
COPY (%position, %length, %destination)
复制（%位置，%长度，%destination）
The position operand specifies the memory address of the first byte in the string to be copied, and the length operand specifies the number of bytes to be copied.
位置操作数指定要复制的字符串中第一个字节的内存地址，长度操作数指定要复制的字节数。
The destination operand gives the address to which the first byte in the string will be copied.
目标操作数给出字符串中第一个字节将被复制到的地址。
Byte copying is performed as per the rules of Section 8.4.
字节复制按照第8.4节的规则执行。
A modified version of the COPY instruction is given below:
复制说明的修改版本如下所示：
COPY-LITERAL (%position, %length, $destination)
复制文字（%position，%length，$destination）
The COPY-LITERAL instruction behaves as a COPY instruction except that after copying is completed, the value of the destination operand is replaced by the address to which the next byte of data would be copied. More precisely it is replaced by the value n, derived as per Section 8.4 with m set to the destination address of the last byte to be copied, if any (i.e., if the value of the length operand is zero, the value of the destination operand is not changed).
复制文字指令的行为与复制指令相同，只是复制完成后，目标操作数的值将替换为下一字节数据将复制到的地址。更准确地说，它被值n替换，n根据第8.4节导出，m设置为要复制的最后一个字节的目标地址（如果有）（即，如果长度操作数的值为零，则目标操作数的值不变）。
A further version of the COPY-LITERAL instruction is given below:
下面给出了复制文字指令的进一步版本：
COPY-OFFSET (%offset, %length, $destination)
复制偏移量（%OFFSET，%length，$destination）
The COPY-OFFSET instruction behaves as a COPY-LITERAL instruction except that an offset operand is given instead of a position operand.
复制偏移量指令的行为类似于复制文字指令，但给出的是偏移操作数而不是位置操作数。
To derive the value of the position operand, starting at the memory address specified by destination, the UDVM counts backwards a total of offset memory addresses.
要派生位置操作数的值，从目标指定的内存地址开始，UDVM向后计算偏移内存地址的总数。
If the memory address specified in byte_copy_left is reached, the next memory address is taken to be (byte_copy_right - 1) modulo 2^16.
如果达到字节\u copy\u left中指定的内存地址，则下一个内存地址取（字节\u copy\u right-1）模2^16。
The COPY-OFFSET instruction then behaves as a COPY-LITERAL instruction, taking the value of the position operand to be the last memory address reached in the above step.
然后，复制偏移量指令的行为类似于复制文字指令，将位置操作数的值作为在上述步骤中达到的最后一个内存地址。
The MEMSET instruction initializes an area of UDVM memory to a specified sequence of values. The format of a MEMSET instruction is as follows:
MEMSET指令将UDVM内存区域初始化为指定的值序列。MEMSET指令的格式如下所示：
MEMSET (%address, %length, %start_value, %offset)
MEMSET（%address，%length，%start\u值，%offset）
The sequence of values used by the MEMSET instruction is specified by the following formula:
MEMSET指令使用的值序列由以下公式指定：
Seq[n] := (start_value + n * offset) modulo 256
Seq[n] := (start_value + n * offset) modulo 256
The values Seq[0] to Seq[length - 1] inclusive are each interpreted as a single byte, and then concatenated to form a byte string where the first byte has value Seq[0], the second byte has value Seq[1] and so on up to the last byte which has value Seq[length - 1].
Seq[0]到Seq[length-1]的值（包括Seq[0]到Seq[length-1]）都被解释为一个单字节，然后连接起来形成一个字节字符串，其中第一个字节的值为Seq[0]，第二个字节的值为Seq[1]，依此类推，直到最后一个字节的值为Seq[length-1]。
The string is then byte copied into the UDVM memory beginning at the memory address specified as an operand to the MEMSET instruction, obeying the rules of Section 8.4. (Note that the byte string may overwrite the MEMSET instruction or its operands; as explained in Section 8.5, the MEMSET instruction must be executed as if the original operands were still in place in the UDVM memory.)
然后，按照第8.4节的规则，从指定为MEMSET指令操作数的内存地址开始，将字符串字节复制到UDVM内存中。（请注意，字节字符串可能会覆盖MEMSET指令或其操作数；如第8.5节所述，执行MEMSET指令时必须将原始操作数仍保留在UDVM内存中。）
The following instructions alter the flow of UDVM code. Each instruction jumps to one of a number of memory addresses based on a certain specified criterion.
以下说明改变了UDVM代码的流程。每个指令根据特定的标准跳转到多个内存地址中的一个。
Note that certain I/O instructions (see Section 9.4) can also alter program flow.
请注意，某些I/O指令（见第9.4节）也可以改变程序流。
The JUMP instruction moves program execution to the specified memory address.
跳转指令将程序执行移动到指定的内存地址。
JUMP (@address)
跳转（@address）
Decompression failure occurs if the value of the address operand lies beyond the overall UDVM memory size.
如果地址操作数的值超出整个UDVM内存大小，则会发生解压缩失败。
The COMPARE instruction compares two operands and then jumps to one of three specified memory addresses depending on the result.
COMPARE指令比较两个操作数，然后根据结果跳转到三个指定内存地址之一。
COMPARE (%value_1, %value_2, @address_1, @address_2, @address_3)
COMPARE (%value_1, %value_2, @address_1, @address_2, @address_3)
If value_1 < value_2 then the UDVM continues instruction execution at the memory address specified by address 1. If value_1 = value_2 then it jumps to the address specified by address_2. If value_1 > value_2 then it jumps to the address specified by address_3.
如果值_1<值_2，则UDVM将在地址1指定的内存地址继续执行指令。如果value_1=value_2，则跳转到由address_2指定的地址。如果值_1>值_2，则跳转到地址_3指定的地址。
The CALL and RETURN instructions provide support for compression algorithms with a nested structure.
调用和返回指令支持嵌套结构的压缩算法。
CALL (@address) RETURN
呼叫（@address）返回
Both instructions use the UDVM stack of Section 8.3. When the UDVM reaches a CALL instruction, it finds the memory address of the instruction immediately following the CALL instruction and pushes this 2-byte value on the stack, ready for later retrieval. It then continues instruction execution at the memory address specified by the address operand.
这两条指令都使用第8.3节中的UDVM堆栈。当UDVM到达一条CALL指令时，它会立即在CALL指令之后找到该指令的内存地址，并将该2字节值推送到堆栈上，以备以后检索。然后，它在地址操作数指定的内存地址继续执行指令。
When the UDVM reaches a RETURN instruction it pops a value from the stack and then continues instruction execution at the memory address just popped.
当UDVM到达返回指令时，它会从堆栈中弹出一个值，然后在刚刚弹出的内存地址继续执行指令。
See Section 8.3 for error conditions.
错误条件见第8.3节。
The SWITCH instruction performs a conditional jump based on the value of one of its operands.
SWITCH指令根据其一个操作数的值执行条件跳转。
SWITCH (#n, %j, @address_0, @address_1, ... , @address_n-1)
SWITCH (#n, %j, @address_0, @address_1, ... , @address_n-1)
When a SWITCH instruction is encountered the UDVM reads the value of j. It then continues instruction execution at the address specified by address j.
当遇到开关指令时，UDVM读取j的值。然后，它在地址j指定的地址继续执行指令。
Decompression failure occurs if j specifies a value of n or more, or if the address lies beyond the overall UDVM memory size.
如果j指定的值为n或更大，或者地址超出整个UDVM内存大小，则会发生解压缩失败。
The CRC instruction verifies a string of bytes using a 2-byte CRC.
CRC指令使用2字节CRC验证字节串。
CRC (%value, %position, %length, @address)
CRC（%值，%位置，%长度，@地址）
The actual CRC calculation is performed using the generator polynomial x^16 + x^12 + x^5 + 1, which coincides with the 2-byte Frame Check Sequence (FCS) of PPP [RFC-1662].
使用生成器多项式x^16+x^12+x^5+1执行实际CRC计算，该多项式与PPP[RFC-1662]的2字节帧检查序列（FCS）一致。
The position and length operands define the string of bytes over which the CRC is evaluated. Byte copying rules are enforced as per Section 8.4.
位置和长度操作数定义计算CRC的字节字符串。字节复制规则按照第8.4节执行。
The CRC value is computed exactly as defined for the 16-bit FCS calculation in [RFC-1662].
CRC值的计算与[RFC-1662]中16位FCS计算的定义完全相同。
The value operand contains the expected integer value of the 2-byte CRC. If the calculated CRC matches the expected value then the UDVM continues instruction execution at the following instruction. Otherwise the UDVM jumps to the memory address specified by the address operand.
值操作数包含2字节CRC的预期整数值。如果计算出的CRC与预期值匹配，则UDVM将继续执行以下指令。否则，UDVM跳转到地址操作数指定的内存地址。
The following instructions allow the UDVM to interface with its environment. Note that in the overall SigComp architecture all of these interfaces pass to the decompressor dispatcher or to the state handler.
以下说明允许UDVM与其环境交互。请注意，在整个SigComp体系结构中，所有这些接口都传递给解压缩程序调度器或状态处理程序。
The DECOMPRESSION-FAILURE instruction triggers a manual decompression failure. This is useful if the UDVM bytecode discovers that it cannot successfully decompress the message (e.g., by using the CRC instruction).
解压失败指令触发手动解压失败。如果UDVM字节码发现它无法成功解压缩消息（例如，通过使用CRC指令），这将非常有用。
This instruction has no operands.
此指令没有操作数。
The INPUT-BYTES instruction requests a certain number of bytes of compressed data from the decompressor dispatcher.
INPUT-BYTES指令从解压缩程序调度器请求一定数量的压缩数据字节。
INPUT-BYTES (%length, %destination, @address)
输入字节（%长度，%destination，@地址）
The length operand indicates the requested number of bytes of compressed data, and the destination operand specifies the starting memory address to which they should be copied. Byte copying is performed as per the rules of Section 8.4.
长度操作数表示请求的压缩数据字节数，目标操作数指定压缩数据应复制到的起始内存地址。字节复制按照第8.4节的规则执行。
If the instruction requests data that lies beyond the end of the SigComp message, no data is returned. Instead the UDVM moves program execution to the address specified by the address operand.
如果指令请求的数据超出SigComp消息的末尾，则不会返回任何数据。相反，UDVM将程序执行移动到地址操作数指定的地址。
If the INPUT-BYTES is encountered after an INPUT-BITS or an INPUT-HUFFMAN instruction has been used, and the dispatcher currently holds a fraction of a byte, then the fraction MUST be discarded before any data is passed to the UDVM. The first byte to be passed is the byte immediately following the discarded data.
如果在使用INPUT-BITS或INPUT-HUFFMAN指令后遇到INPUT-BYTES，并且dispatcher当前持有字节的一小部分，则必须在将任何数据传递到UDVM之前丢弃该小部分。要传递的第一个字节是丢弃数据后面的字节。
The INPUT-BITS instruction requests a certain number of bits of compressed data from the decompressor dispatcher.
INPUT-BITS指令从解压缩程序调度器请求一定数量的压缩数据位。
INPUT-BITS (%length, %destination, @address)
输入位（%长度，%destination，@地址）
The length operand indicates the requested number of bits. Decompression failure occurs if this operand does not lie between 0 and 16 inclusive.
长度操作数表示请求的位数。如果此操作数不在0和16之间（含0和16），则会发生解压缩失败。
The destination operand specifies the memory address to which the compressed data should be copied. Note that the requested bits are interpreted as a 2-byte integer ranging from 0 to 2^length - 1, as explained in Section 8.2.
目标操作数指定压缩数据应复制到的内存地址。请注意，如第8.2节所述，所请求的位被解释为范围为0到2^长度-1的2字节整数。
If the instruction requests data that lies beyond the end of the SigComp message, no data is returned. Instead the UDVM moves program execution to the address specified by the address operand.
如果指令请求的数据超出SigComp消息的末尾，则不会返回任何数据。相反，UDVM将程序执行移动到地址操作数指定的地址。
The INPUT-HUFFMAN instruction requests a variable number of bits of compressed data from the decompressor dispatcher. The instruction initially requests a small number of bits and compares the result against a certain criterion; if the criterion is not met, then additional bits are requested until the criterion is achieved.
INPUT-HUFFMAN指令从解压器调度器请求可变位数的压缩数据。指令最初请求少量位，并将结果与某个标准进行比较；如果不满足该标准，则请求额外的位，直到达到该标准。
The INPUT-HUFFMAN instruction is followed by three mandatory operands plus n additional sets of operands. Every additional set contains four operands as shown below:
INPUT-HUFFMAN指令后跟三个必需的操作数加上n组额外的操作数。每个附加集包含四个操作数，如下所示：
INPUT-HUFFMAN (%destination, @address, #n, %bits_1, %lower_bound_1, %upper_bound_1, %uncompressed_1, ... , %bits_n, %lower_bound_n, %upper_bound_n, %uncompressed_n)
INPUT-HUFFMAN（%destination，@address，#n，%bits#u 1，%lower_bound_1，%upper_bound_1，%uncompressed_1，…，%bits_n，%lower_bound_n，%upper_bound_n，%uncompressed_n）
Note that if n = 0 then the INPUT-HUFFMAN instruction is ignored and program execution resumes at the following instruction. Decompression failure occurs if (bits_1 + ... + bits_n) > 16.
请注意，如果n=0，则忽略INPUT-HUFFMAN指令，并在以下指令处恢复程序执行。如果（位1+…+位n）>16，则会发生解压缩失败。
In all other cases, the behavior of the INPUT-HUFFMAN instruction is defined below:
在所有其他情况下，INPUT-HUFFMAN指令的行为定义如下：
1. Set j := 1 and set H := 0.
1. 设置j:=1，设置H:=0。
2. Request bits_j compressed bits. Interpret the returned bits as an integer k from 0 to 2^bits_j - 1, as explained in Section 8.2.
2. 请求位\压缩位。如第8.2节所述，将返回的位解释为0到2^bits_j-1之间的整数k。
3. Set H := H * 2^bits_j + k.
3. 设置H:=H*2^bits\u j+k。
4. If data is requested that lies beyond the end of the SigComp message, terminate the INPUT-HUFFMAN instruction and move program execution to the memory address specified by the address operand.
4. 如果请求的数据超出SigComp消息的结尾，请终止INPUT-HUFFMAN指令，并将程序执行移到地址操作数指定的内存地址。
5. If (H < lower_bound_j) or (H > upper_bound_j) then set j := j + 1. Then go back to Step 2, unless j > n in which case decompression failure occurs.
5. 如果（H<下限值_j）或（H>上限值_j），则设置j:=j+1。然后返回到步骤2，除非j>n，在这种情况下发生解压缩失败。
6. Copy (H + uncompressed_j - lower_bound_j) modulo 2^16 to the memory address specified by the destination operand.
6. 将（H+未压缩_j-下限_j）模2^16复制到目标操作数指定的内存地址。
The STATE-ACCESS instruction retrieves some previously stored state information.
STATE-ACCESS指令检索一些以前存储的状态信息。
STATE-ACCESS (%partial_identifier_start, %partial_identifier_length, %state_begin, %state_length, %state_address, %state_instruction)
状态访问（%partial\u identifier\u start、%partial\u identifier\u length、%STATE\u begin、%STATE\u length、%STATE\u address、%STATE\u指令）
The partial_identifier_start and partial_identifier_length operands specify the location of the partial state identifier used to retrieve the state information. This identifier has the same function as the partial state identifier transmitted in the SigComp message as per Section 7.2.
部分_标识符_start和部分_标识符_length操作数指定用于检索状态信息的部分状态标识符的位置。根据第7.2节，该标识符与SigComp消息中传输的部分状态标识符具有相同的功能。
Decompression failure occurs if partial_identifier_length does not lie between 6 and 20 inclusive. Decompression failure also occurs if no state item matching the partial state identifier can be found, if
如果部分_标识符_长度不在6和20之间（含6和20），则会发生解压缩失败。如果找不到与部分状态标识符匹配的状态项，则也会发生解压缩失败，如果
more than one state item matches the partial identifier, or if partial_identifier_length is less than the minimum_access_length of the matched state item. Otherwise, a state item is returned from the state handler.
多个状态项与部分标识符匹配，或者如果部分标识符长度小于匹配状态项的最小访问长度。否则，将从状态处理程序返回状态项。
If any of the operands state_address, state_instruction or state_length is set to 0 then its value is taken from the returned item of state instead.
如果任何操作数state_address、state_指令或state_length设置为0，则其值取自返回的state项。
Note that when calculating the number of UDVM cycles the STATE-ACCESS instruction costs (1 + state_length) cycles. The value of state_length MUST be taken from the returned item of state in the case that the state_length operand is set to 0.
请注意，在计算UDVM周期数时，状态访问指令开销（1+状态长度）周期。如果state_length操作数设置为0，则state_length的值必须取自返回的state项。
The state_begin and state_length operands define the starting byte and number of bytes to copy from the state_value contained in the returned item of state. Decompression failure occurs if bytes are copied from beyond the end of the state_value. Note that decompression failure will always occur if the state_length operand is set to 0 but the state_begin operand is non-zero.
state_begin和state_length操作数定义从返回的state项中包含的state_值复制的起始字节和字节数。如果从超出状态值结尾的位置复制字节，则会发生解压缩失败。请注意，如果state_length操作数设置为0，但state_begin操作数为非零，则解压总是会失败。
The state_address operand contains a UDVM memory address. The requested portion of the state_value is byte copied to this memory address using the rules of Section 8.4.
state_地址操作数包含UDVM内存地址。使用第8.4节的规则，将状态_值的请求部分字节复制到此内存地址。
Program execution then resumes at the memory address specified by state_instruction, unless this address is 0 in which case program execution resumes at the next instruction following the STATE-ACCESS instruction. Note that the latter case only occurs if both the state_instruction operand and the state_instruction value from the requested state are set to 0.
然后，程序执行将在state_指令指定的内存地址恢复，除非该地址为0，在这种情况下，程序执行将在state-ACCESS指令之后的下一条指令恢复。请注意，后一种情况仅在state_指令操作数和请求状态的state_指令值都设置为0时发生。
The STATE-CREATE instruction requests the creation of a state item at the receiving endpoint.
STATE-CREATE指令请求在接收端点创建状态项。
STATE-CREATE (%state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
状态创建（%STATE\u length、%STATE\u address、%STATE\u指令、%minimum\u access\u length、%STATE\u retention\u priority）
Note that the new state item cannot be created until a valid compartment identifier has been returned by the application. Consequently, when a STATE-CREATE instruction is encountered the UDVM simply buffers the five supplied operands until the END-MESSAGE instruction is reached. The steps taken at this point are described in Section 9.4.9.
请注意，在应用程序返回有效的隔间标识符之前，无法创建新的状态项。因此，当遇到状态创建指令时，UDVM只需缓冲提供的五个操作数，直到到达结束消息指令。第9.4.9节描述了此时采取的步骤。
Decompression failure MUST occur if more than four state creation requests are made before the END-MESSAGE instruction is encountered. Decompression failure also occurs if the minimum_access_length does not lie between 6 and 20 inclusive, or if the state_retention_priority is 65535.
如果在遇到结束消息指令之前发出了四个以上的状态创建请求，则必须发生解压缩失败。如果最小访问长度不在6和20之间（含6和20），或者状态保留优先级为65535，则也会发生解压缩失败。
The STATE-FREE instruction informs the receiving endpoint that the sender no longer wishes to use a particular state item.
无状态指令通知接收端点发送方不再希望使用特定状态项。
STATE-FREE (%partial_identifier_start, %partial_identifier_length)
无状态（%partial\u identifier\u start，%partial\u identifier\u length）
Note that the STATE-FREE instruction does not automatically delete a state item, but instead reclaims the memory taken by the state item within a certain compartment, which is generally not known before the END-MESSAGE instruction is reached. So just as for the STATE-CREATE instruction, when a STATE-FREE instruction is encountered the UDVM simply buffers the two supplied operands until the END-MESSAGE instruction is reached. The steps taken at this point are described in Section 9.4.9.
请注意，无状态指令不会自动删除状态项，而是回收特定隔室内状态项占用的内存，这在到达结束消息指令之前通常是未知的。因此，就像STATE-CREATE指令一样，当遇到无状态指令时，UDVM只需缓冲提供的两个操作数，直到到达结束消息指令。第9.4.9节描述了此时采取的步骤。
Decompression failure MUST occur if more than four state free requests are made before the END-MESSAGE instruction is encountered. Decompression failure also occurs if partial_identifier_length does not lie between 6 and 20 inclusive.
如果在遇到结束消息指令之前发出了四个以上的无状态请求，则必须发生解压缩失败。如果部分_标识符_长度不在6和20之间（含6和20），也会发生解压缩失败。
The OUTPUT instruction provides successfully decompressed data to the dispatcher.
输出指令向调度程序提供成功解压缩的数据。
OUTPUT (%output_start, %output_length)
输出（%OUTPUT\u start，%OUTPUT\u length）
The operands define the starting memory address and length of the byte string to be provided to the dispatcher. Note that the OUTPUT instruction can be used to output a partially decompressed message; each time the instruction is encountered it provides a new byte string that the dispatcher appends to the end of any bytes previously passed to the dispatcher via the OUTPUT instruction.
操作数定义要提供给调度程序的字节字符串的起始内存地址和长度。注意，输出指令可用于输出部分解压缩的消息；每次遇到指令时，它都会提供一个新的字节字符串，分派器会将该字符串附加到以前通过输出指令传递给分派器的任何字节的末尾。
The string of data is byte copied from the UDVM memory obeying the rules of Section 8.4.
根据第8.4节的规则，从UDVM内存中复制数据字符串。
Decompression failure occurs if the cumulative number of bytes provided to the dispatcher exceeds 65536 bytes.
如果提供给dispatcher的累积字节数超过65536字节，则会发生解压缩失败。
Since there is technically a difference between outputting a 0-byte decompressed message, and not outputting a decompressed message at all, the OUTPUT instruction needs to distinguish between the two cases. Thus, if the UDVM terminates before encountering an OUTPUT instruction it is considered not to have outputted a decompressed message. If it encounters one or more OUTPUT instructions, each of which provides 0 bytes of data to the dispatcher, then it is considered to have outputted a 0-byte decompressed message.
由于从技术上讲，输出0字节解压缩消息与根本不输出解压缩消息之间存在差异，因此输出指令需要区分这两种情况。因此，如果UDVM在遇到输出指令之前终止，则认为它没有输出解压缩消息。如果它遇到一个或多个输出指令，其中每个指令向调度器提供0字节的数据，则认为它已输出0字节的解压缩消息。
The END-MESSAGE instruction successfully terminates the UDVM and forwards the state creation and state free requests to the state handler together with any supplied feedback data.
结束消息指令成功终止UDVM，并将状态创建和无状态请求连同任何提供的反馈数据一起转发给状态处理程序。
END-MESSAGE (%requested_feedback_location, %returned_parameters_location, %state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
结束消息（%requested\u feedback\u location、%returned\u parameters\u location、%state\u length、%state\u address、%state\u instruction、%minimum\u access\u length、%state\u retention\u priority）
When the END-MESSAGE instruction is encountered, the decompressor dispatcher indicates to the application that a complete message has been decompressed. The application may return a compartment identifier, which the UDVM forwards to the state handler together with the state creation and state free requests and any supplied feedback data.
当遇到结束消息指令时，解压器分派器向应用程序指示已解压完整消息。应用程序可能返回一个隔间标识符，UDVM将其与状态创建和无状态请求以及任何提供的反馈数据一起转发给状态处理程序。
The actual decompressed message is outputted separately using the OUTPUT instruction; this conserves memory at the UDVM because there is no need to buffer an entire decompressed message before it can be passed to the dispatcher.
使用输出指令分别输出实际解压缩的消息；这节省了UDVM上的内存，因为在将整个解压缩消息传递给dispatcher之前，不需要对其进行缓冲。
The END-MESSAGE instruction may pass up to four state creation requests and up to four state free requests to the state handler. The requests are passed to the state handler in the same order as they are made; in particular it is possible for the state creation requests and the state free requests to be interleaved.
结束消息指令最多可以向状态处理程序传递四个状态创建请求和四个无状态请求。请求以与发出请求相同的顺序传递给状态处理程序；特别地，状态创建请求和状态自由请求可以交错。
The state creation requests are made by the STATE-CREATE instruction. Note however that the END-MESSAGE can make one state creation request itself using the supplied operands. If the specified minimum_access_length does not lie between 6 and 20 inclusive, or if the state_retention_priority is 65535 then the END-MESSAGE instruction fails to make a state creation request of its own (however decompression failure does not occur and the state creation requests made by the STATE-CREATE instruction are still valid).
状态创建请求由state-CREATE指令发出。但是请注意，结束消息本身可以使用提供的操作数发出一个状态创建请求。如果指定的最小访问长度不在6和20之间（包括6和20），或者状态保留优先级为65535，则结束消息指令无法发出其自身的状态创建请求（但是不会发生解压缩失败，并且状态创建指令发出的状态创建请求仍然有效）。
Note that there is a maximum limit of four state creation requests per instance of the UDVM. Therefore, decompression failure occurs if the END-MESSAGE instruction makes a state creation request and four instances of the STATE-CREATE instruction have already been encountered.
请注意，每个UDVM实例最多有四个状态创建请求。因此，如果结束消息指令发出状态创建请求，并且已经遇到状态创建指令的四个实例，则会发生解压缩失败。
When creating a state item it is necessary to give the state_length, state address, state_instruction and minimum_access_length; these are supplied as operands in the STATE-CREATE instruction (or the END-MESSAGE instruction). A complete item of state also requires a state_value and a state_identifier, which are derived as follows:
创建状态项时，必须给出状态长度、状态地址、状态指令和最小访问长度；它们在状态创建指令（或结束消息指令）中作为操作数提供。一个完整的状态项还需要一个状态值和一个状态标识符，其派生如下：
The UDVM byte copies a string of state_length bytes from the UDVM memory beginning at state_address (obeying the rules of Section 8.4). This is the state_value.
UDVM字节从UDVM内存中复制一个从state_地址开始的state_长度字节字符串（遵守第8.4节的规则）。这是state_值。
The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the byte string formed by concatenating the state_length, state_address, state_instruction, minimum_access_length and state_value (in the order given). This is the state_identifier.
然后，UDVM在通过连接状态_长度、状态_地址、状态_指令、最小访问_长度和状态_值（按给定顺序）形成的字节字符串上计算一个20字节的SHA-1哈希[RFC-3174]。这是状态标识符。
The state_retention_priority is not part of the state item itself, but instead determines the order in which state will be deleted when the compartment exceeds its allocated state memory. The state_retention_priority is supplied as an operand in the STATE-CREATE or END-MESSAGE instruction and is passed to the state handler as part of each state creation request.
state_retention_优先级不是state项本身的一部分，而是确定当隔间超过其分配的状态内存时删除状态的顺序。state_retention_优先级在state-CREATE或END-MESSAGE指令中作为操作数提供，并作为每个状态创建请求的一部分传递给状态处理程序。
The state free requests are made by the STATE-FREE instruction. Each STATE-FREE instruction supplies the values partial_identifier_start and partial_identifier_length; upon reaching the END-MESSAGE instruction these values are used to byte copy a partial state identifier from the UDVM memory. If no state item matching the partial state identifier can be found or if more than one state item in the compartment matches the partial state identifier, then the state free request is ignored (this does not cause decompression failure to occur). Otherwise, the state handler frees the matched state item as specified in Section 6.2.
无状态请求由无状态指令发出。每个无状态指令提供值partial_identifier_start和partial_identifier_length；到达结束消息指令后，这些值用于从UDVM内存中字节复制部分状态标识符。如果找不到与部分状态标识符匹配的状态项，或者如果隔室中有多个状态项与部分状态标识符匹配，则忽略无状态请求（这不会导致解压缩失败）。否则，状态处理程序将按照第6.2节的规定释放匹配的状态项。
As well as forwarding the state creation and state free requests, the END-MESSAGE instruction may also pass feedback data to the state handler. Feedback data is used to inform the receiving endpoint about the capabilities of the sending endpoint, which can help to improve the overall compression ratio and to reduce the working memory requirements of the endpoints.
除了转发状态创建和无状态请求外，结束消息指令还可以将反馈数据传递给状态处理程序。反馈数据用于通知接收端点发送端点的功能，这有助于提高总体压缩比并降低端点的工作内存需求。
Two types of feedback data are available: requested feedback and returned feedback. The format of the requested feedback data is given in Figure 12. As outlined in Section 3.2, the requested feedback data can be used to influence the contents of the returned feedback data in the reverse direction.
有两种类型的反馈数据可用：请求的反馈和返回的反馈。请求的反馈数据的格式如图12所示。如第3.2节所述，请求的反馈数据可用于反向影响返回反馈数据的内容。
The returned feedback data is itself subdivided into a returned feedback item and a list of returned SigComp parameters. The returned feedback item is of sufficient importance to warrant its own field in the SigComp header as described in Section 7.1. The returned SigComp parameters are illustrated in Figure 13.
返回的反馈数据本身被细分为返回的反馈项和返回的SigComp参数列表。如第7.1节所述，返回的反馈项的重要性足以保证其在SigComp标题中的字段。返回的SigComp参数如图13所示。
Note that the formats of Figure 12 and Figure 13 are only for local presentation of the feedback data on the interface between the UDVM and state handler. The formats do not mandate any bits on the wire; the compressor can transmit the data in any form provided that it is loaded into the UDVM memory at the correct addresses.
注意，图12和图13的格式仅用于UDVM和状态处理程序之间接口上反馈数据的本地表示。这些格式不要求导线上有任何位；只要数据以正确的地址加载到UDVM内存中，压缩器就可以以任何形式传输数据。
Moreover, the responsibility for ensuring that feedback data arrives successfully over an unreliable transport lies with the sender. The receiving endpoint always uses the last received value for each field in the feedback data, even if the values are out of date due to packet loss or misordering.
此外，确保反馈数据通过不可靠的传输成功到达的责任在于发送方。接收端点始终为反馈数据中的每个字段使用最后接收的值，即使这些值由于数据包丢失或排序错误而过期。
If the requested_feedback_location operand is set to 0, then no feedback request is made; otherwise, it points to the starting memory address of the requested feedback data as shown in Figure 12.
如果请求的\u反馈\u位置操作数设置为0，则不进行反馈请求；否则，它将指向请求的反馈数据的起始内存地址，如图12所示。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| |
: requested feedback item : if Q = 1
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| |
: requested feedback item : if Q = 1
| |
+---+---+---+---+---+---+---+---+
Figure 12: Format of requested feedback data
图12：请求的反馈数据格式
The reserved bits may be used in future versions of SigComp, and are set to 0 in Version 0x01. Non-zero values should be ignored by the receiving endpoint.
保留位可在未来版本的SigComp中使用，并在版本0x01中设置为0。接收端点应忽略非零值。
The Q-bit indicates whether a requested feedback item is present or not. The compressor can set the requested feedback item to an arbitrary value, which will then be transmitted unmodified in the reverse direction as a returned feedback item. See Chapter 5 for further details of how the requested feedback item is returned.
Q位表示请求的反馈项是否存在。压缩器可以将请求的反馈项设置为任意值，然后作为返回的反馈项以未经修改的反向传输。有关如何返回请求的反馈项的更多详细信息，请参见第5章。
The format of the requested feedback item is identical to the format of the returned feedback item illustrated in Figure 4.
请求的反馈项的格式与图4所示的返回反馈项的格式相同。
The compressor sets the S-bit to 1 if it does not wish (or no longer wishes) to save state information at the receiving endpoint and also does not wish to access state information that it has previously saved. Consequently, if the S-bit is set to 1 then the receiving endpoint can reclaim the state memory allocated to the remote compressor and set the state_memory_size for the compartment to 0.
如果压缩器不希望（或不再希望）在接收端点保存状态信息，也不希望访问其先前保存的状态信息，则将S位设置为1。因此，如果S位设置为1，则接收端点可以回收分配给远程压缩器的状态内存，并将腔室的状态内存大小设置为0。
The compressor may change its mind and switch the S-bit back to 0 in a later message. However, the receiving endpoint is under no obligation to use the original state_memory_size for the compartment; it may choose to allocate less memory to the compartment or possibly none at all.
压缩机可能会改变主意，并在稍后的消息中将S位切换回0。然而，接收端点没有义务为隔室使用原始状态存储器大小；它可能会选择分配更少的内存给隔间，或者根本不分配内存。
Similarly the compressor sets the I-bit to 1 if it does not wish (or no longer wishes) to access any of the locally available state items offered by the receiving endpoint. This can help to conserve bandwidth because the list of locally available state items no longer needs to be returned in the reverse direction. It may also conserve memory at the receiving endpoint, as the state handler can delete any locally available state items that it determines are no longer required by any remote endpoint. Note that the compressor can set the I-bit back to 0 in a later message, but it cannot access any locally available state items that were previously offered by the receiving endpoint unless they are subsequently re-announced.
类似地，如果压缩器不希望（或不再希望）访问接收端点提供的任何本地可用状态项，则压缩器将I位设置为1。这有助于节省带宽，因为本地可用状态项的列表不再需要反向返回。它还可以在接收端点保存内存，因为状态处理程序可以删除它确定任何远程端点不再需要的任何本地可用状态项。请注意，压缩器可以在稍后的消息中将I位设置回0，但它无法访问接收端点先前提供的任何本地可用状态项，除非随后重新宣布它们。
If the returned_parameters_location operand is set to 0, then no SigComp parameters are returned; otherwise, it points to the starting memory address of the returned parameters as shown in Figure 13.
如果返回的\u参数\u位置操作数设置为0，则不返回SigComp参数；否则，它将指向返回参数的起始内存地址，如图13所示。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
Figure 13: Format of returned SigComp parameters
图13：返回的SigComp参数的格式
The first byte encodes the SigComp parameters cycles_per_bit, decompression_memory_size and state_memory_size as per Section 3.3.1. The byte can be set to 0 if the three parameters are not included in the feedback data. (This may be useful to save bits in the compressed message if the remote endpoint is already satisfied all necessary information has reached the endpoint receiving the message.)
根据第3.3.1节，第一个字节对SigComp参数周期、解压内存大小和状态内存大小进行编码。如果反馈数据中未包含这三个参数，则可将字节设置为0。（如果远程端点已经满足所有必要的信息已到达接收消息的端点，则这可能有助于在压缩消息中保存位。）
The second byte encodes the SigComp_version as per Section 3.3.2. Similar to the first byte, the second byte can be set to 0 if the parameter is not included in the feedback data.
第二个字节根据第3.3.2节对SigComp_版本进行编码。与第一个字节类似，如果反馈数据中不包含参数，则第二个字节可以设置为0。
The remaining bytes encode a list of partial state identifiers for the locally available state items offered by the sending endpoint. Each state item is encoded as a 1-byte length field, followed by a partial state identifier containing as many bytes as indicated in the length field. The sender can choose to send as few as 6 bytes if it believes that this is sufficient for the receiver to determine which state item is being offered.
其余字节对发送端点提供的本地可用状态项的部分状态标识符列表进行编码。每个状态项编码为一个1字节的长度字段，后跟一个部分状态标识符，该标识符包含长度字段中指示的字节数。如果发送方认为这足以让接收方确定提供了哪个状态项，则发送方可以选择只发送6个字节。
The list of state identifiers is terminated by a byte in the position where the next length field would be expected that is set to a value below 6 or above 20. Note that upgraded SigComp versions may append additional items of data after the final length field.
状态标识符列表由一个字节终止，该字节位于预期下一个长度字段设置为低于6或高于20的值的位置。请注意，升级后的SigComp版本可能会在最终长度字段后附加额外的数据项。
The overall security goal of the SigComp architecture is to not create risks that are in addition to those already present in the application protocols. There is no intention for SigComp to enhance the security of the application, as it always can be circumvented by not using compression. More specifically, the high-level security goals can be described as:
SigComp体系结构的总体安全目标是不产生应用程序协议中已经存在的风险之外的风险。SigComp无意增强应用程序的安全性，因为不使用压缩总是可以避免这种情况。更具体地说，高级安全目标可以描述为：
1. Do not worsen security of existing application protocol
1. 不要恶化现有应用程序协议的安全性
2. Do not create any new security issues
2. 不要产生任何新的安全问题
3. Do not hinder deployment of application security.
3. 不要妨碍应用程序安全性的部署。
This section identifies the potential security risks associated with SigComp, and explains how each risk is minimized by the scheme.
本节确定了与SigComp相关的潜在安全风险，并解释了如何通过该方案将每个风险降至最低。
- Attacking SigComp by snooping into state of other users:
- 通过窥探其他用户的状态来攻击SigComp：
State is accessed by supplying a state identifier, which is a cryptographic hash of the state being referenced. This implies that the referencing message already needs knowledge about the state. To enforce this, a state item cannot be accessed without supplying a minimum of 48 bits from the hash. This also minimizes the probability of an accidental state collision. A compressor can, using the minimum_access_length operand of the STATE-CREATE and END-MESSAGE instructions, increase the number of bits that need to be supplied to access the state, increasing the protection against attacks.
通过提供状态标识符来访问状态，状态标识符是被引用状态的加密散列。这意味着引用消息已经需要关于状态的知识。为了实现这一点，如果不从散列中提供至少48位，则无法访问状态项。这也将意外状态碰撞的概率降至最低。压缩器可以使用状态创建指令和结束消息指令的最小访问长度操作数，增加访问状态所需的位数，从而增强对攻击的保护。
Generally, ways to obtain knowledge about the state identifier (e.g., passive attacks) will also easily provide knowledge about the referenced state, so no new vulnerability results.
通常，获取状态标识符相关知识的方法（例如，被动攻击）也很容易提供有关引用状态的知识，因此不会产生新的漏洞。
An endpoint needs to handle state identifiers with the same care it would handle the state itself.
端点需要像处理状态本身一样小心地处理状态标识符。
The SigComp approach assumes that there is appropriate integrity protection below and/or above the SigComp layer. The state creation mechanism provides some additional potential to compromise the integrity of the messages; however, this would most likely be detectable at the application layer.
SigComp方法假设在SigComp层下方和/或上方有适当的完整性保护。状态创建机制提供了损害消息完整性的额外可能性；然而，这很可能在应用层被检测到。
- Attacking SigComp by faking state or making unauthorized changes to state:
- 通过伪造状态或对状态进行未经授权的更改来攻击SigComp：
State cannot be destroyed by a malicious sender unless it can send messages that the application identifies as belonging to the same compartment the state was created under; this adds additional security risks only when the application allows the installation of SigComp state from a message where it would not have installed state itself.
恶意发送方无法销毁状态，除非它可以发送应用程序标识为属于创建状态的同一分区的消息；只有当应用程序允许从消息中安装SigComp state时，这才会增加额外的安全风险，而该消息本身不会安装state。
Faking or changing state is only possible if the hash allows intentional collision.
只有当哈希允许故意冲突时，才可能伪造或更改状态。
- Use of SigComp as a tool in a DoS attack to another target:
- 将SigComp用作DoS攻击另一目标的工具：
SigComp cannot easily be used as an amplifier in a reflection attack, as it only generates one decompressed message per incoming compressed message. This message is then handed to the application; the utility as a reflection amplifier is therefore limited by the utility of the application for this purpose.
SigComp不能轻易地用作反射攻击中的放大器，因为每个传入的压缩消息只生成一条解压缩消息。然后将此消息传递给应用程序；因此，作为反射放大器的实用性受到用于此目的的应用的实用性的限制。
However, it must be noted that SigComp can be used to generate larger messages as input to the application than have to be sent from the malicious sender; this therefore can send smaller messages (at a lower bandwidth) than are delivered to the application. Depending on the reflection characteristics of the application, this can be considered a mild form of amplification. The application MUST limit the number of packets reflected to a potential target - even if SigComp is used to generate a large amount of information from a small incoming attack packet.
但是，必须注意的是，SigComp可用于生成比恶意发送方发送的消息更大的消息作为应用程序的输入；因此，这可以发送比发送到应用程序的消息更小的消息（带宽更低）。根据应用的反射特性，可以认为这是一种温和的放大形式。应用程序必须限制反射到潜在目标的数据包数量——即使SigComp用于从一个小的传入攻击数据包生成大量信息。
- Attacking SigComp as the DoS target by filling it with state:
- 将SigComp作为DoS目标进行攻击，方法是将其填充状态：
Excessive state can only be installed by a malicious sender (or a set of malicious senders) with the consent of the application. The system consisting of SigComp and application is thus approximately as vulnerable as the application itself, unless it allows the installation of SigComp state from a message where it would not have installed application state itself.
过度状态只能由恶意发件人（或一组恶意发件人）在应用程序同意的情况下安装。因此，由SigComp和应用程序组成的系统与应用程序本身一样容易受到攻击，除非它允许从消息中安装SigComp状态，而该消息本身不会安装应用程序状态。
If this is desirable to increase the compression ratio, the effect can be mitigated by making use of feedback at the application level that indicates whether the state requested was actually installed - this allows a system under attack to gracefully degrade by no longer installing compressor state that is not matched by application state.
如果这有助于提高压缩比，则可以通过在应用程序级别使用反馈来减轻影响，该反馈指示是否实际安装了请求的状态-这允许受攻击的系统通过不再安装与应用程序状态不匹配的压缩器状态来正常降级。
Obviously, if a stream-based transport is used, the streams themselves constitute state that has to be handled in the same way that the application itself would handle a stream-based transport; if an application is not equipped for stream-based transport, it should not allow SigComp connections on a stream-based transport. For the alternative SigComp usage described as "continuous mode" in Section 4.2.1, an attacker could create any number of active UDVMs unless there is some DoS protection at a lower level (e.g., by using TLS in appropriate configurations).
显然，如果使用基于流的传输，则流本身构成必须以与应用程序本身处理基于流的传输相同的方式处理的状态；如果应用程序未配备基于流的传输，则不应允许在基于流的传输上进行SigComp连接。对于第4.2.1节中描述为“连续模式”的替代SigComp使用，攻击者可以创建任意数量的活动UDVM，除非在较低级别上有一些DoS保护（例如，通过在适当配置中使用TLS）。
- Attacking the UDVM by faking state or making unauthorized changes to state:
- 通过伪造状态或对状态进行未经授权的更改来攻击UDVM：
This is covered in Section 10.2.2.
第10.2.2节对此进行了说明。
- Attacking the UDVM by sending it looping code:
- 通过发送循环代码攻击UDVM：
The application sets an upper limit to the number of "UDVM cycles" that can be used per compressed message and per input bit in the compressed message. The damage inflicted by sending packets with looping code is therefore limited, although this may still be substantial if a large number of UDVM cycles are offered by the UDVM. However, this would be true for any decompressor that can receive packets over an unsecured transport.
应用程序为每个压缩消息和压缩消息中的每个输入位可以使用的“UDVM周期”数量设置上限。因此，使用循环代码发送数据包所造成的损害是有限的，尽管如果UDVM提供了大量UDVM周期，这可能仍然是巨大的。然而，对于任何可以通过不安全传输接收数据包的解压器来说都是如此。
SigComp requires a 1-byte name space, the SigComp_version, which has been created by the IANA. Upgraded versions of SigComp must be backwards-compatible with Version 0x01, described in this document. Adding additional UDVM instructions and assigning values to the reserved UDVM memory addresses are two possible upgrades for which this is the case.
SigComp需要一个1字节的名称空间，即由IANA创建的SigComp_版本。SigComp的升级版本必须与本文档中描述的版本0x01向后兼容。添加额外的UDVM指令和为保留的UDVM内存地址分配值是两种可能的升级，情况就是这样。
Following the policies outlined in [RFC-2434], the IANA policy for assigning a new value for the SigComp_version shall require a Standards Action. Values are thus assigned only for Standards Track RFCs approved by the IESG.
按照[RFC-2434]中概述的政策，为SigComp_版本分配新值的IANA政策应要求采取标准措施。因此，仅为IESG批准的标准轨道RFC分配值。
Thanks to
幸亏
Abigail Surtees Mark A West Lawrence Conroy Christian Schmidt Max Riegel Lars-Erik Jonsson Stefan Forsgren Krister Svanbro Miguel Garcia Christopher Clanton Khiem Le Ka Cheong Leung Robert Sugar
阿比盖尔·萨提斯·马克·A西部劳伦斯·康罗伊·克里斯蒂安·施密特·马克斯·里格尔·拉尔斯·埃里克·琼森·斯特凡·福斯格伦·克里斯特尔·斯文布罗·米格尔·加西亚·克里斯托弗·克兰顿·凯姆·勒·卡昌梁·罗伯特·苏格
for valuable input and review.
提供有价值的意见和审查。
[RFC-1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC-1662]辛普森，W，“HDLC类框架中的PPP”，STD 51，RFC 1662，1994年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC-3174]Eastlake，3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC-1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC-1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC 1951，1996年5月。
[RFC-2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026]Bradner，S.，“互联网标准过程-第3版”，BCP 9，RFC 2026，1996年10月。
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC-2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC-2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC-2326]Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，1998年4月。
[RFC-2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-2434]Alvestrand，H.和T.Narten，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC-2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwartzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC-2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwartzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 2960，2000年10月。
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC-3261]罗森伯格，J.，舒尔兹林内，H.，卡马里洛，G.，约翰斯顿，A.，彼得森，J.，斯帕克斯，R.，汉德利，M.和E.斯库勒，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC-3321] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu, Z. and R. Price, "Signaling Compression (SigComp) - Extended Operations", RFC 3321, January 2003.
[RFC-3321]Hannu，H.，Christofferson，J.，Forsgren，S.，Leung，K-C.，Liu，Z.和R.Price，“信号压缩（SigComp）-扩展操作”，RFC 33212003年1月。
Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
Richard Price Roke Manor研究有限公司罗姆西，汉斯，英国
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28334
Phone: +49 421 218 7024
EMail: cabo@tzi.org
Phone: +49 421 218 7024
EMail: cabo@tzi.org
Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Jan Christofferson信箱920爱立信AB SE-971 28瑞典卢利亚
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Hans Hannu信箱920爱立信AB SE-971 28瑞典卢利亚
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039
德克萨斯州欧文市刘志刚诺基亚研究中心6000连接路75039
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。