Network Working Group A. Surtees
Request for Comments: 4896 M. West
Updates: 3320, 3321, 3485 Siemens/Roke Manor Research
Category: Standards Track A.B. Roach
Estacado Systems
June 2007
Network Working Group A. Surtees
Request for Comments: 4896 M. West
Updates: 3320, 3321, 3485 Siemens/Roke Manor Research
Category: Standards Track A.B. Roach
Estacado Systems
June 2007
Signaling Compression (SigComp) Corrections and Clarifications
信号压缩（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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485.
本文档描述了信令压缩协议（SigComp）中常见的误解和一些歧义，并为开发人员解决任何由此产生的问题提供了指导。SigComp定义了一种用于压缩应用程序协议（如会话启动协议（SIP））生成的消息的方案。本文档更新了以下RFC:RFC 3320、RFC 3321和RFC 3485。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Decompression Memory Size . . . . . . . . . . . . . . . . . . 3
2.1. Bytecode within Decompression Memory Size . . . . . . . . 3
2.2. Default Decompression Memory Size . . . . . . . . . . . . 4
3. UDVM Instructions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Data Input Instructions . . . . . . . . . . . . . . . . . 5
3.2. MULTILOAD . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Using the Stack . . . . . . . . . . . . . . . . . . . . . 6
4. Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Instructions That Use Byte Copying Rules . . . . . . . . . 9
5. State Retention Priority . . . . . . . . . . . . . . . . . . . 9
5.1. Priority Values . . . . . . . . . . . . . . . . . . . . . 9
5.2. Multiple State Retention Priorities . . . . . . . . . . . 10
5.3. Retention Priority 65535 (or -1) . . . . . . . . . . . . . 10
6. Duplicate State . . . . . . . . . . . . . . . . . . . . . . . 14
7. State Identifier Clashes . . . . . . . . . . . . . . . . . . . 14
8. Message Misordering . . . . . . . . . . . . . . . . . . . . . 15
9. Requested Feedback . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Feedback When SMS Is Zero . . . . . . . . . . . . . . . . 15
9.2. Updating Feedback Requests . . . . . . . . . . . . . . . . 16
10. Advertising Resources . . . . . . . . . . . . . . . . . . . . 16
10.1. The I-bit and Local State Items . . . . . . . . . . . . . 16
10.2. Dynamic Update of Resources . . . . . . . . . . . . . . . 17
10.3. Advertisement of Locally Available State Items . . . . . . 17
10.3.1. Basic SigComp . . . . . . . . . . . . . . . . . . . . 18
10.3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . 18
10.3.3. SigComp Extended Mechanisms . . . . . . . . . . . . . 19
11. Uncompressed Bytecode . . . . . . . . . . . . . . . . . . . . 19
12. RFC 3485 SIP/SDP Static Dictionary . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
16.1. Normative References . . . . . . . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Dummy Application Protocol (DAP) . . . . . . . . . . 24
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24
A.2. Processing a DAP Message . . . . . . . . . . . . . . . . . 24
A.3. DAP Message Format in ABNF . . . . . . . . . . . . . . . . 26
A.4. An Example of a DAP Message . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Decompression Memory Size . . . . . . . . . . . . . . . . . . 3
2.1. Bytecode within Decompression Memory Size . . . . . . . . 3
2.2. Default Decompression Memory Size . . . . . . . . . . . . 4
3. UDVM Instructions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Data Input Instructions . . . . . . . . . . . . . . . . . 5
3.2. MULTILOAD . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Using the Stack . . . . . . . . . . . . . . . . . . . . . 6
4. Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Instructions That Use Byte Copying Rules . . . . . . . . . 9
5. State Retention Priority . . . . . . . . . . . . . . . . . . . 9
5.1. Priority Values . . . . . . . . . . . . . . . . . . . . . 9
5.2. Multiple State Retention Priorities . . . . . . . . . . . 10
5.3. Retention Priority 65535 (or -1) . . . . . . . . . . . . . 10
6. Duplicate State . . . . . . . . . . . . . . . . . . . . . . . 14
7. State Identifier Clashes . . . . . . . . . . . . . . . . . . . 14
8. Message Misordering . . . . . . . . . . . . . . . . . . . . . 15
9. Requested Feedback . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Feedback When SMS Is Zero . . . . . . . . . . . . . . . . 15
9.2. Updating Feedback Requests . . . . . . . . . . . . . . . . 16
10. Advertising Resources . . . . . . . . . . . . . . . . . . . . 16
10.1. The I-bit and Local State Items . . . . . . . . . . . . . 16
10.2. Dynamic Update of Resources . . . . . . . . . . . . . . . 17
10.3. Advertisement of Locally Available State Items . . . . . . 17
10.3.1. Basic SigComp . . . . . . . . . . . . . . . . . . . . 18
10.3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . 18
10.3.3. SigComp Extended Mechanisms . . . . . . . . . . . . . 19
11. Uncompressed Bytecode . . . . . . . . . . . . . . . . . . . . 19
12. RFC 3485 SIP/SDP Static Dictionary . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
16.1. Normative References . . . . . . . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Dummy Application Protocol (DAP) . . . . . . . . . . 24
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24
A.2. Processing a DAP Message . . . . . . . . . . . . . . . . . 24
A.3. DAP Message Format in ABNF . . . . . . . . . . . . . . . . 26
A.4. An Example of a DAP Message . . . . . . . . . . . . . . . 26
SigComp [1] defines the Universal Decompressor Virtual Machine (UDVM) for decompressing messages sent by a compliant compressor. SigComp further describes mechanisms to deal with state handling, message structure, and other details. While the behavior of the decompressor is specified in great detail, the behavior of the compressor is left as a choice for the implementer. During implementation and interoperability tests, some areas of SigComp that need clarification have been identified. The sections that follow enumerate the problem areas identified in the specification, and attempt to provide clarification.
SigComp[1]定义了通用解压器虚拟机（UDVM），用于解压兼容压缩器发送的消息。SigComp进一步描述了处理状态处理、消息结构和其他细节的机制。虽然解压器的行为是非常详细的，但是压缩器的行为留给实现者选择。在实施和互操作性测试期间，已经确定了需要澄清的SigComp的一些领域。以下章节列举了规范中确定的问题区域，并试图提供澄清。
Note that, as this document refers to sections in several other documents, the following notation is applied:
请注意，由于本文件引用了其他几个文件中的章节，因此采用了以下符号：
"in Section 3.4" refers to Section 3.4 of this document "in RFC 3320-Section 3.4" refers to Section 3.4 of RFC 3320 [1]
“第3.4节中”指本文件第3.4节“RFC 3320第3.4节中”指RFC 3320第3.4节[1]
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 RFC 2119 [5].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[5]中所述进行解释。
SigComp [1] states that the default Decompression Memory Size (DMS) is 2K. The UDVM memory size is defined in RFC 3320-Section 7 to be (DMS - n), where n is the size of the SigComp message, for messages transported over UDP and (DMS / 2) for those transported over TCP. This means that when the message contains the bytecode (as it will for at least the first message) there will actually be two copies of the bytecode within the decompressor memory (see Figure 1). The presence of the second copy of bytecode in decompressor memory is correct in this case.
SigComp[1]声明默认解压缩内存大小（DMS）为2K。RFC 3320第7节将UDVM内存大小定义为（DMS-n），其中n是通过UDP传输的消息的SigComp消息大小，对于通过TCP传输的消息，为（DMS/2）。这意味着，当消息包含字节码时（至少第一条消息是这样），解压器内存中实际上会有两个字节码副本（见图1）。在这种情况下，解压器内存中存在字节码的第二个副本是正确的。
|<----------------------------DMS--------------------------------->|
|<-----SigComp message---->|<------------UDVM memory size--------->|
+-+----------+-------------+-----+----------+----------------------+
| | bytecode | comp msg | | bytecode | circular buffer |
+-+----------+-------------+-----+----------+----------------------+
^ ^
| |
SigComp header Low bytes of UDVM
|<----------------------------DMS--------------------------------->|
|<-----SigComp message---->|<------------UDVM memory size--------->|
+-+----------+-------------+-----+----------+----------------------+
| | bytecode | comp msg | | bytecode | circular buffer |
+-+----------+-------------+-----+----------+----------------------+
^ ^
| |
SigComp header Low bytes of UDVM
Figure 1: Bytecode and UDVM memory size within DMS
图1:DMS中的字节码和UDVM内存大小
For many implementations, the length of decompression bytecode sent is in the range of three to four hundred bytes. Because SigComp specifies a default DMS of 2K, the described scheme seriously restricts the size of the circular buffer, and of the compressed message itself. In some cases, this set of circumstances has a damaging effect on the compression ratio; for others, it makes it completely impossible to send certain messages compressed.
对于许多实现，发送的解压缩字节码的长度在300到400字节之间。因为SigComp指定了默认的DMS为2K，所以所描述的方案严重限制了循环缓冲区和压缩消息本身的大小。在某些情况下，这组情况会对压缩比产生破坏性影响；对于其他人来说，它完全不可能发送某些压缩的消息。
To address this problem, those mandating the use of SigComp need to also provide further specification for their application that mandates the use of an appropriately sized DMS. Sizing of such a DMS should take into account (1) the size of bytecode for algorithms likely to be employed in compressing the application messages, (2) the size of any buffers or structures necessary to execute such algorithms, (3) the size of application messages, and (4) the average entropy present within a single application message.
为了解决这个问题，那些要求使用SigComp的人还需要为他们的应用程序提供进一步的规范，要求使用适当大小的DMS。此类DMS的大小应考虑（1）可能用于压缩应用程序消息的算法的字节码大小，（2）执行此类算法所需的任何缓冲区或结构的大小，（3）应用程序消息的大小，以及（4）单个应用程序消息中存在的平均熵。
For example, assume a typical compression algorithm requiring approximately 400 bytes of bytecode, plus about 2432 bytes of data structures. The required UDVM memory size is 400 + 2432 = 2832. For a TCP-based protocol, this means the DMS must be at least 5664 (2832 * 2) bytes, which is rounded up to 8k. For a UDP-based protocol, one must take into account the size of the SigComp messages themselves. Assuming a text-based protocol with sufficient average entropy to compress a single message by 50% (without any previous message history), and messages that are not expected to exceed 8192 bytes in size, the protocol message itself will add 4096 bytes to the SigComp message size (on top of the 400 bytes of bytecode plus a 3-byte header), or 4096 + 400 + 3 = 4499. To calculate the DMS, one must add this to the required UDVM memory size: 2832 + 4499 = 6531, which is again rounded up to 8k of DMS.
例如，假设一个典型的压缩算法需要大约400字节的字节码，加上大约2432字节的数据结构。所需的UDVM内存大小为400+2432=2832。对于基于TCP的协议，这意味着DMS必须至少为5664（2832*2）字节，四舍五入为8k。对于基于UDP的协议，必须考虑SigComp消息本身的大小。假设基于文本的协议具有足够的平均熵，可以将单个消息压缩50%（没有任何以前的消息历史记录），并且消息的大小预计不会超过8192字节，则协议消息本身将向SigComp消息大小添加4096字节（在400字节字节字节字节的字节码加上3字节的报头之上），或4096+400+3=4499。要计算DMS，必须将其添加到所需的UDVM内存大小中：2832+4499=6531，再次四舍五入到8k DMS。
When inputting data from the compressed message, the INPUT-BYTES (RFC 3320-Section 9.4.2) and INPUT-BITS (RFC 3320-Section 9.4.3) instructions both have the paragraph:
从压缩信息输入数据时，输入字节（RFC 3320第9.4.2节）和输入位（RFC 3320第9.4.3节）指令都有以下段落：
"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 intent is that if n bytes/bits are requested, but only m are left in the message (where m < n), then the decompression dispatcher MUST NOT return any bytes/bits to the UDVM, and the m bytes/bits that are there MUST remain in the message unchanged.
其目的是，如果请求了n个字节/位，但消息中只剩下m个字节/位（其中m<n），则解压缩调度器不得将任何字节/位返回到UDVM，并且消息中的m个字节/位必须保持不变。
For example, if the remaining bytes of a message are: 0x01 0x02 0x03 and the UDVM encounters an INPUT-BYTES (6, a, b) instruction. Then the decompressor dispatcher returns no bytes and jumps to the instruction specified by b. This contains an INPUT-BYTES (2, c, d) instruction so the decompressor dispatcher successfully returns the bytes 0x01 and 0x02.
例如，如果消息的剩余字节为：0x01 0x02 0x03，并且UDVM遇到输入字节（6，a，b）指令。然后，解压器分派器不返回任何字节，而是跳转到b指定的指令。这包含一条输入字节（2，c，d）指令，因此解压缩程序调度器将成功返回字节0x01和0x02。
In the case where an INPUT-BYTES instruction follows an INPUT-BITS instruction that has left a partial byte in the message, the partial byte should still be thrown away even if there are not enough bytes to input.
如果在消息中留下部分字节的INPUT-BYTES指令之后是INPUT-BITS指令，则即使没有足够的字节输入，也应丢弃部分字节。
INPUT-BYTES (0, a, b) can be used to flush out a partial byte.
输入字节（0、a、b）可用于清除部分字节。
In order to make step-by-step implementation simpler, the MULTILOAD instruction is explicitly not allowed to write into any memory positions occupied by the MULTILOAD opcode or any of its parameters. Additionally, if there is any indirection of parameters, the indirection MUST be done at execution time.
为了简化分步实现，明确不允许MULTILOAD指令写入MULTILOAD操作码或其任何参数占用的任何内存位置。此外，如果存在任何参数间接寻址，则必须在执行时执行间接寻址。
Any implementation technique other than a step-by-step implementation (e.g., decode all operands then execute, which is the model of all other instructions) MUST yield the same result as a step-by-step implementation would.
除分步实现以外的任何实现技术（例如，解码所有操作数然后执行，这是所有其他指令的模型）必须产生与分步实现相同的结果。
For example:
例如：
at (64)
at（64）
:location_a pad (2)
:location_b pad (2)
:location_c pad (2)
pad (30)
:udvm_memory_size pad (2)
:circular_buffer pad (2)
:location_a pad (2)
:location_b pad (2)
:location_c pad (2)
pad (30)
:udvm_memory_size pad (2)
:circular_buffer pad (2)
align (64)
对齐（64）
MULTILOAD (location_a, 3, circular_buffer, udvm_memory_size, $location_a)
多重加载（位置a，3，循环缓冲区，udvm内存大小，$location a）
The step-by-step implementation would: write the address of circular_buffer into location_a (memory address 64); write the address of udvm_memory_size into location_a + 2 (memory address 66); write the value stored in location_a (accessed using indirection - that is now the address of circular_buffer) into location_a + 4 (memory address 68). Therefore, at the end of the execution by a correct implementation, location_c will contain the address of circular_buffer.
分步实现是：将循环_缓冲区的地址写入位置_a（内存地址64）；将udvm_memory_size的地址写入位置_a+2（内存地址66）；将存储在位置_a（使用间接寻址访问-即现在的循环_缓冲区地址）中的值写入位置_a+4（内存地址68）。因此，在正确实现的执行结束时，位置c将包含循环缓冲区的地址。
The STATE-FREE instruction does not check the minimum_access_length. This is correct because the state cannot be freed until the application has authenticated the message. The lack of checking does not pose a security risk because if the sender has enough information to create authenticated messages, then sending messages that save state can push previous state out of storage anyway.
无状态指令不检查最小访问长度。这是正确的，因为在应用程序对消息进行身份验证之前，无法释放状态。缺少检查不会带来安全风险，因为如果发送方有足够的信息来创建经过身份验证的消息，那么发送保存状态的消息可能会将以前的状态从存储中推出。
The STATE-FREE instruction can only free state in the compartment that corresponds to the message being decompressed. Attempting to free state that is either from another compartment, or that is not associated with any compartment, has no effect.
STATE-FREE指令只能释放与正在解压缩的消息对应的隔间中的状态。尝试从另一个隔室释放状态，或者尝试释放与任何隔室都不关联的状态，都不会产生任何效果。
The instructions PUSH, POP, CALL, and RETURN make use of a stack that is set up using the well-known memory address stack_location to define where in memory the stack is located. Use of the stack is defined in RFC 3320-Section 8.3, which states: '"Pushing" a value on the stack is an abbreviation for copying the value to
PUSH、POP、CALL和RETURN指令使用使用已知内存地址stack_位置设置的堆栈来定义堆栈在内存中的位置。RFC 3320第8.3节对堆栈的使用进行了定义，其中规定：“‘推’堆栈上的值是将值复制到的缩写
stack[stack_fill] and then increasing stack_fill by 1.' and 'stack_fill is an abbreviation for the 2-byte word at stack_location and stack_location + 1'.
stack[stack_fill]，然后将stack_fill增加1。'和'stack_fill是stack_位置和stack_位置+1'处2字节字的缩写。
In the very rare case that the value of stack_fill is 0xFFFF when a value is pushed onto the stack, then the original stack_fill value MUST be increased by 1 to 0x0000 and written back to stack_location and stack_location + 1 (which will overwrite the value that has been pushed onto the stack).
在非常罕见的情况下，当将值推送到堆栈上时，堆栈_fill的值为0xFFFF，则原始堆栈_fill值必须增加1到0x0000，并写回堆栈_位置和堆栈_位置+1（这将覆盖推送到堆栈上的值）。
The new value pushed onto the stack has, in theory, been written to stack [0xFFFF] = stack_location. Stack_fill would then be increased by 1; however, the value at stack_location and stack_location + 1 has just been updated. To maintain the integrity of the stack with regard to over and underflow, stack_fill cannot be re-read at this point, and the pushed value is overwritten.
理论上，推送到堆栈上的新值已写入堆栈[0xFFFF]=堆栈位置。然后，堆栈填充将增加1；但是，stack_位置和stack_位置+1处的值刚刚更新。为了保持堆栈在溢出和下溢方面的完整性，此时无法重新读取堆栈填充，并覆盖推送的值。
RFC 3320-Section 8.4 states that "The string of bytes is copied in ascending order of memory address, respecting the bounds set by byte_copy_left and byte_copy_right." This is misleading in that it is perfectly legitimate to copy bytes outside of the bounds set by byte_copy_left and byte_copy_right. Byte_copy_left and byte_copy_right provide the ability to maintain a circular buffer as follows:
RFC 3320第8.4节指出，“字节串按照内存地址的升序复制，遵守字节左和字节右设置的边界。”这是一种误导，因为在字节左和字节右设置的边界之外复制字节是完全合法的。Byte_copy_left和Byte_copy_right提供了维护循环缓冲区的能力，如下所示：
For moving to the right
向右移
if current_byte == ((byte_copy_right - 1) mod 2 ^ 16):
next_byte = byte_copy_left
else:
next_byte = (current_byte + 1) mod 2 ^ 16
if current_byte == ((byte_copy_right - 1) mod 2 ^ 16):
next_byte = byte_copy_left
else:
next_byte = (current_byte + 1) mod 2 ^ 16
which is equivalent to the algorithm given in RFC 3320-Section 8.4.
这相当于RFC 3320第8.4节中给出的算法。
For moving to the left
向左移动
if current_byte == byte_copy_left:
previous_byte = (byte_copy_right - 1) mod 2 ^ 16
else:
previous_byte = (current_byte - 1) mod 2 ^ 16
if current_byte == byte_copy_left:
previous_byte = (byte_copy_right - 1) mod 2 ^ 16
else:
previous_byte = (current_byte - 1) mod 2 ^ 16
Moving to the left is only used for COPY_OFFSET.
向左移动仅用于复制偏移。
Consequently, copying could begin to the left of byte_copy_left and continue across it (and jump back to it according to the given
因此，复制可以从字节_copy _left的左边开始，并在其上继续（并根据给定的
algorithm if necessary) and could begin at or to the right of byte_copy_right (though care must be taken to prevent decompression failure due to writing to / reading from beyond the UDVM memory).
如有必要，可从字节\复制\右侧开始（但必须注意防止由于写入UDVM内存或从UDVM内存读取而导致解压缩失败）。
For further clarity: consider the UDVM memory laid out as follows, with byte_copy_left and byte_copy_right in the locations indicated by "BCL" and "BCR", respectively:
为了进一步的清晰：考虑UDVM内存设置如下，在BCL和BCR所指示的位置分别使用ByTeTopCopyLead和ByTeaScript。
+----------------------------------------+
| |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+
| |
+----------^------------^----------------+
BCL BCR
If an opcode read or wrote bytes starting to the left of byte_copy_left, it would do so in the following order:
如果操作码从byte_copy_left的左边开始读取或写入字节，它将按照以下顺序执行：
+----------------------------------------+
| abcdefghijkl |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+
| abcdefghijkl |
+----------^------------^----------------+
BCL BCR
If the opcode continues to read or write until it reaches byte_copy_right, it would then wrap around to byte_copy_left and continue (letters after the wrap are capitalized for clarity):
如果操作码继续读或写，直到它到达byte_copy_right，它将环绕到byte_copy_left并继续（为了清晰起见，环绕后的字母大写）：
+----------------------------------------+
| abcQRSTUVjklmnop |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+
| abcQRSTUVjklmnop |
+----------^------------^----------------+
BCL BCR
Similarly, writing to the right of byte_copy_right is a perfectly valid operation for opcodes that honor byte copying rules:
类似地，写入byte_copy_right的右侧对于遵守字节复制规则的操作码来说是完全有效的操作：
+----------------------------------------+
| abcdefg |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+
| abcdefg |
+----------^------------^----------------+
BCL BCR
A final, somewhat odd relic of the foregoing rules occurs when byte_copy_right is actually less than byte_copy_left. In this case, reads and writes will skip the memory between the pointers:
当byte_copy_right实际上小于byte_copy_left时，就会出现上述规则的最后一个有点奇怪的遗迹。在这种情况下，读取和写入将跳过指针之间的内存：
+----------------------------------------+
| abcde fghijkl |
+----------^------------^----------------+
BCR BCL
+----------------------------------------+
| abcde fghijkl |
+----------^------------^----------------+
BCR BCL
This document amends the list of instructions that obey byte copying rules in RFC 3320-Section 8.4 to include STATE-CREATE and CRC.
本文件修改了RFC 3320第8.4节中遵守字节复制规则的指令列表，包括状态创建和CRC。
RFC 3320-Section 8.4 specifies the byte copying rules and includes a list of the instructions that obey them. STATE-CREATE is not in this list but END-MESSAGE is. This caused confusion due to the fact that neither instruction actually does any byte copying; rather, both instructions give information to the state-handler to create state. Logically, both instructions should have the same information about byte copying.
RFC3320第8.4节规定了字节复制规则，并包括遵守规则的指令列表。状态创建不在此列表中，但结束消息不在此列表中。这导致了混淆，因为两条指令实际上都没有进行任何字节复制；相反，这两条指令都向状态处理程序提供信息以创建状态。从逻辑上讲，两条指令应该具有相同的字节复制信息。
When state is created by the state-handler (whether from an END-MESSAGE or a STATE-CREATE instruction), the byte copying rules of RFC 3320-Section 8.4 apply.
当状态处理程序（无论是从结束消息还是状态创建指令）创建状态时，RFC 3320第8.4节的字节复制规则适用。
Note that, if the contents of the UDVM changes between the occurrence of the STATE-CREATE instruction and the state being created, the bytes that are stored are those in the buffer at the time of creation (i.e., when the message has been decompressed and authenticated).
注意，如果UDVM的内容在STATE-CREATE指令的出现和正在创建的状态之间发生变化，则存储的字节是在创建时（即，当消息已被解压缩和认证时）缓冲区中的字节。
CRC is not mentioned in RFC 3320-Section 8.4 in the list of instructions that obey byte copying rules, but its description in RFC 3320-Section 9.3.5 states that these rules are to be obeyed. When reading data over which to perform the CRC check, byte copying rules apply as specified in RFC 3320-Section 8.4.
RFC 3320第8.4节中未提及遵守字节复制规则的指令列表中的CRC，但RFC 3320第9.3.5节中的描述说明应遵守这些规则。读取要执行CRC检查的数据时，字节复制规则适用于RFC 3320第8.4节的规定。
When the partial identifier for a STATE-FREE instruction is read, (during the execution of END-MESSAGE) byte copying rules as per RFC 3320-Section 8.4 apply.
当读取无状态指令的部分标识符时，（在执行结束消息期间），根据RFC 3320第8.4节的字节复制规则适用。
Given that reading the buffer for creating and freeing state within the END-MESSAGE instruction obeys byte copying rules, there may be some confusion as to whether reading feedback items should also obey byte copying rules. Byte copying rules do not apply for reading feedback items.
鉴于读取缓冲区以在结束消息指令中创建和释放状态遵守字节复制规则，可能会对读取反馈项是否也应遵守字节复制规则产生一些混淆。字节复制规则不适用于读取反馈项。
For state_retention_priority, 65535 < 0 < 1 < ... < 65534. This is slightly counter intuitive, but is correct.
对于状态保留优先级，65535<0<1<…<65534这有点违反直觉，但却是正确的。
There may be confusion when the same piece of state is created at two different retention priorities. The following clarifies this:
当以两种不同的保留优先级创建相同的状态时，可能会出现混淆。以下澄清了这一点：
The retention priority MUST be associated with the compartment and not with the piece of state. For example, if endpoint A creates a piece of state with retention priority 1 and endpoint B creates exactly the same state with retention priority 2, there should be one copy (assuming the model of state management suggested in SigComp [1]) of the actual state, but each compartment should keep a record of this piece of state with its own priority. (If this does not happen then the state could be kept for longer than A anticipated or less time than B anticipated, depending on which priority is used. This could cause Decompression Failure to occur.)
保留优先级必须与隔间相关联，而不是与状态块相关联。例如，如果端点A创建了一个保留优先级为1的状态，而端点B创建的状态与保留优先级为2的状态完全相同，则实际状态应该有一个副本（假设SigComp[1]中建议的状态管理模型），但是，每个隔间都应该保留一份记录，记录这种状态，并有自己的优先级。（如果未发生这种情况，则状态的保持时间可能比预期的时间长，或比预期的时间短，具体取决于使用的优先级。这可能会导致解压缩失败。）
If the same piece of state is created within a compartment with a different priority, then one copy of it should be stored with the new priority and it MUST count only once against SMS. That is, the state creation updates the priority rather than creates a new piece of state.
如果在具有不同优先级的隔间内创建了相同的状态，则应以新优先级存储该状态的一个副本，并且该状态只能在SMS中计数一次。也就是说，状态创建会更新优先级，而不是创建新的状态。
There is potentially a problem with storing multiple pieces of state with the minimum retention priority (65535) as defined in SigComp [1]. This can be shown by considering the following examples that are of shared mode, which is documented in SigComp Extended [2]. The key thing about state with retention priority 65535 is that it can be created by an endpoint in the decompressor compartment without the knowledge of the remote compressor (which controls state creation in the decompressor compartment).
存储具有SigComp[1]中定义的最低保留优先级（65535）的多个状态可能存在问题。这可以通过考虑以下共享模式的示例来说明，这些示例记录在SigComp Extended[2]中。保留优先级为65535的状态的关键在于，它可以由解压室中的端点创建，而不需要远程压缩器（远程压缩器控制解压室中的状态创建）。
Example 1:
例1：
[SMn state is shared mode state (priority 65535), BC is bytecode state (priority 1), BFn is buffer state (priority 0)]
[SMn状态为共享模式状态（优先级65535），BC为字节码状态（优先级1），BFn为缓冲区状态（优先级0）]
Endpoint A Endpoint B [decomp cpt] [comp cpt]
端点A端点B[反编译cpt][comp cpt]
[SM1]
------------------------------->
[SM1]
[SM1]
------------------------------->
[SM1]
[SM1, SM2]
--------------------X (message lost)
[SM1, SM2]
--------------------X (message lost)
[SM1, BC, BF1]
<------------ref SM1------------
[SM2, BC, BF1]
endpoint B still believes SM1
is at endpoint A
[SM1, BC, BF1]
<------------ref SM1------------
[SM2, BC, BF1]
endpoint B still believes SM1
is at endpoint A
[BC, BF1, BF2]
<------------ref SM1------------
[BC, BF1, BF2]
<------------ref SM1------------
decompression failure at A because SM1 has already been deleted
由于SM1已被删除，在上的解压缩失败
Example 2:
例2：
Endpoint A Endpoint B [decomp cpt] [comp cpt]
端点A端点B[反编译cpt][comp cpt]
[SM1]
------------------------------->
[SM1]
[SM1]
------------------------------->
[SM1]
[SM1, BC, BF1]
(message lost)X------ref SM1-----
[SM1, BC, BF1]
(message lost)X------ref SM1-----
[SM1, SM2]
------------------------------->
endpoint B does not create SM2
because there is no space
[SM1, BC, BF1]
[SM1, SM2]
------------------------------->
endpoint B does not create SM2
because there is no space
[SM1, BC, BF1]
[SM1, BC, BF1, BF2]
<------------ref SM1------------
[SM2, BC, BF2]
endpoint B still believes SM1
is at endpoint A
[SM1, BC, BF1, BF2]
<------------ref SM1------------
[SM2, BC, BF2]
endpoint B still believes SM1
is at endpoint A
[BC, BF1, BF2, BF3]
<------------ref SM1------------
[BC, BF1, BF2, BF3]
<------------ref SM1------------
decompression failure at A because SM1 has already been deleted
由于SM1已被删除，在上的解压缩失败
Figure 2: Retention priority 65535 examples
图2：保留优先级65535示例
Once there is more than one piece of minimum priority state created in a decompressor compartment, the corresponding compressor cannot be certain about which pieces of state are present in that (decompressor) compartment. If there is only one piece of state, then no such ambiguity exists.
一旦在减压室中创建了多个最低优先级状态，相应的压缩机就无法确定该（减压）室中存在哪些状态。如果只有一个状态，那么就不存在这种模糊性。
The problem is a consequence of the different rules for the creation of minimum priority state. In particular, the creation of the second piece of state without the knowledge of the compressor could mean that the first piece is pushed out earlier than the compressor expects (despite the fact that the state processing rules from SigComp [1] are being implemented correctly).
这个问题是最低优先权状态创建规则不同的结果。特别是，在压缩器不知情的情况下创建第二个状态可能意味着第一个状态比压缩器预期的更早推出（尽管SigComp[1]中的状态处理规则得到了正确实施）。
SigComp [1] also states that a compressor MUST be certain that all of the data needed to decompress a SigComp message is available at the receiving endpoint. Thus, it SHOULD NOT reference any state unless it can be sure that the state exists. The fact that the compressor at B has no way of knowing how much state has been created at A can lead to a loss of synchronization between the endpoints, which is not acceptable.
SigComp[1]还指出，压缩器必须确保在接收端点处可以使用解压缩SigComp消息所需的所有数据。因此，它不应该引用任何状态，除非它可以确定该状态存在。B处的压缩器无法知道A处创建了多少状态这一事实可能导致端点之间的同步丢失，这是不可接受的。
One observation is that it is always safe to reference a piece of minimum priority state following receipt of the advertisement of the state.
一种意见是，在收到一个最低优先权国家的公告后，引用该国的一项公告总是安全的。
If it is known that both endpoints are running SigComp version 2, as defined in NACK [3], then an endpoint MAY assume that the likelihood of a loss of synchronization is very small, and rely on the NACK mechanism for recovery.
如果已知两个端点都在运行NACK[3]中定义的SigComp版本2，则端点可以假设同步丢失的可能性非常小，并依赖NACK机制进行恢复。
However, for a compressor to try and avoid causing the generation of NACKs, it has to be able to make some assumptions about the behavior of the peer compressor. Also, if one of the endpoints does not support NACK, then some other solution is needed.
然而，为了使压缩器尝试避免产生NACK，它必须能够对对等压缩器的行为做出一些假设。此外，如果其中一个端点不支持NACK，则需要其他解决方案。
Consequently, where NACK is not supported or for NACK averse compressors, the recommendation is that only one piece of minimum priority state SHOULD be present in a compartment at any one time. If both endpoints support NACK [3], then this recommendation MAY be relaxed, but implementers need to think carefully about the consequences of creating multiple pieces of minimum priority state. In either case, if the behavior of the application restricts the message flow, this fact could be exploited to allow safe creation of multiple minimum priority states; however, care must still be taken.
因此，如果不支持NACK，或者对于NACK厌恶型压缩机，建议在任何时间间隔内仅存在一个最低优先级状态。如果两个端点都支持NACK[3]，那么这个建议可能会放宽，但是实现者需要仔细考虑创建多个最小优先级状态的后果。在这两种情况下，如果应用程序的行为限制了消息流，则可以利用这一事实来安全创建多个最低优先级状态；然而，仍然必须小心。
Note that if a compressor wishes the remote endpoint to be able to create a new piece of minimum priority state, it can use the STATE-FREE instruction to remove the existing piece of state.
请注意，如果压缩器希望远程端点能够创建一个新的最低优先级状态，它可以使用无状态指令删除现有的状态。
If a piece of state is created in a compartment in which it already exists, the time of its creation SHOULD be updated as if it had just been created, irrespective of whether or not there is a new state retention priority.
如果某个状态是在其已存在的隔室中创建的，则无论是否存在新的状态保留优先级，其创建时间都应像刚创建时一样进行更新。
RFC 3320-Section 6.2 states that when creating a piece of state, the full 20-byte hash should be checked to see whether or not another piece of state with this identifier exists. If it does, and the state item is not identical, then the new creation MUST fail. It is stated that the probability of this occurring is vanishingly small (and so it is, see below).
RFC 3320第6.2节规定，当创建一段状态时，应检查完整的20字节散列，以查看是否存在具有此标识符的另一段状态。如果是，并且状态项不相同，则新创建必须失败。据说发生这种情况的概率非常小（事实就是如此，见下文）。
However, when state is accessed, only the first n bytes of the state identifier are used, where n could be as low as 6. At this point, if there are two pieces of state with the same first n bytes of state identifier, the STATE-ACCESS instruction will cause decompression failure. The compressor referencing the state will not expect this failure mode because the state creation succeeded without a clash. At a server endpoint where there could be thousands or millions of pieces of state, how likely is this to actually happen?
然而，当访问状态时，只使用状态标识符的前n个字节，其中n可以低至6。此时，如果有两个状态具有相同的状态标识符的前n个字节，则state-ACCESS指令将导致解压缩失败。引用状态的压缩器不会期望出现此故障模式，因为状态创建成功，但没有发生冲突。在一个可能有数千或数百万条状态的服务器端点上，这种情况实际发生的可能性有多大？
Consider the birthday paradox (where there only have to be 23 people in a room to have a greater than 50% chance that two of them will have the same birthday (Birthday [8])).
考虑一下生日悖论（其中只有23个人在一个房间里有50%以上的机会，其中两个人会有同样的生日（生日（8）））。
The naive calculation using factorials gives:
使用阶乘的朴素计算得出：
N!
Pd(N,s) = 1 - -------------
(N - s)! N^s
N!
Pd(N,s) = 1 - -------------
(N - s)! N^s
where N is the number of possible values and s is the sample size.
其中N是可能值的数量，s是样本大小。
However, due to dealing with large numbers, an approximation is needed:
但是，由于要处理大量数据，需要一个近似值：
Pd(N,s) = 1 - e^( LnFact(N) - LnFact(N-s) - s Ln(N) )
Pd(N,s) = 1 - e^( LnFact(N) - LnFact(N-s) - s Ln(N) )
where LnFact (x) is the log of x!, which can be approximated by:
其中LnFact（x）是x的对数！，可近似为：
LnFact(x) ~ (x + 1/2) Ln(x) - x + Ln(2*Pi)/2 +
LnFact(x) ~ (x + 1/2) Ln(x) - x + Ln(2*Pi)/2 +
1 1 1 1
--- - ------- + -------- - --------
12x 360 x^3 1260 x^5 1680 x^7
1 1 1 1
--- - ------- + -------- - --------
12x 360 x^3 1260 x^5 1680 x^7
which using N = 2^48 [6 octet partial state identifier] gives:
使用N=2^48[6个八位组部分状态标识符]给出：
s = 1 000 000: Pd (N,s) = 0.018%
s = 10 000 000: Pd (N,s) = 16.28%
s = 100 000 000: Pd (N,s) = 100.00%
s = 1 000 000: Pd (N,s) = 0.018%
s = 10 000 000: Pd (N,s) = 16.28%
s = 100 000 000: Pd (N,s) = 100.00%
so when implementing, thought should be given as to whether or not 6 octets of state identifier is enough to ensure that state access will be successful (particularly at a server).
因此，在实现时，应该考虑6个八位字节的状态标识符是否足以确保状态访问成功（特别是在服务器上）。
The likelihood of a clash when using the full 20 octets of state identifier, does indeed have a vanishingly small probability: using N = 2^160 [full 20 octet state identifier] gives:
使用完整的20个八位组状态标识符时发生冲突的可能性确实非常小：使用N=2^160[完整的20个八位组状态标识符]给出：
s = 1 000 000: Pd (N,s) = 3.42E-35%
s = 10 000 000: Pd (N,s) = 3.42E-33%
s = 100 000 000: Pd (N,s) = 3.42E-31%
s = 1 000 000: Pd (N,s) = 3.42E-35%
s = 10 000 000: Pd (N,s) = 3.42E-33%
s = 100 000 000: Pd (N,s) = 3.42E-31%
Consequently, care must be taken when deciding how many octets of state identifier to use to access state at the server.
因此，在决定使用多少个八位字节的状态标识符来访问服务器上的状态时，必须小心。
SigComp [1] makes only one reference to the possibility of misordered messages. However, the statement that the 'compressor MUST ensure that the message can be decompressed using the resources available at the remote endpoint' puts the onus on the compressor to take account of the possibility of misordering occurring.
SigComp[1]只提到了错误排列消息的可能性。但是，“压缩器必须确保可以使用远程端点上可用的资源对消息进行解压缩”这一说法让压缩器承担了考虑到发生错误排序的可能性的责任。
Whether misordering can occur and whether that would have an impact depends on the compartment definition and the transport protocol in use. Therefore, it is up to the implementer of the compressor to take these factors into account.
是否会发生误序以及是否会产生影响取决于车厢定义和使用的传输协议。因此，压缩机的实施者需要考虑这些因素。
If an endpoint receives a request for feedback, then it SHOULD return the feedback even if its SMS is zero. The storage overhead of the requested feedback is NOT part of the SMS.
如果端点接收到反馈请求，则即使其SMS为零，也应返回反馈。请求反馈的存储开销不是SMS的一部分。
When an endpoint receives a valid message it updates the requested feedback data for that compartment. RFC 3320-Section 5 states that there is no need to transmit any requested feedback item more than once. However, there are cases where it would be beneficial for the feedback to be sent more than once (e.g., a retransmitted 200 OK SIP message [9] to an INVITE SIP message implies that the original 200 OK, and the feedback it carried, might not have reached the remote endpoint). Therefore, an endpoint SHOULD transmit feedback repeatedly until it receives another valid message that updates the feedback.
当端点接收到有效消息时，它会更新该分区请求的反馈数据。RFC 3320第5节规定，无需多次发送任何请求的反馈项。然而，在某些情况下，将反馈发送不止一次将是有益的（例如，将200ok SIP消息[9]重新传输到INVITE SIP消息意味着原始200ok及其携带的反馈可能尚未到达远程端点）。因此，端点应该重复传输反馈，直到它收到另一条更新反馈的有效消息为止。
RFC 3320-Section 9.4.9 states that when requested_feedback_location equals zero, no feedback request is made. However, there is no indication of whether this means that the existing feedback data is left untouched or if this means that the existing feedback data SHOULD be overwritten to be 'no feedback data'. If requested_feedback_location equals zero, the existing feedback data SHOULD be left untouched and returned in any subsequent messages as before.
RFC 3320第9.4.9节规定，当请求的反馈位置等于零时，不提出反馈请求。但是，没有迹象表明这是否意味着现有反馈数据保持不变，或者这是否意味着现有反馈数据应被覆盖为“无反馈数据”。如果请求的\u反馈\u位置等于零，则现有反馈数据应保持不变，并像以前一样在任何后续消息中返回。
RFC 3320-Section 9.4.9 also makes no statement about what happens to existing feedback data when requested_feedback_location does not equal zero but the Q flag indicating the presence/absence of a requested_feedback_item is zero. In this case, the existing feedback data SHOULD be overwritten to be 'no feedback data'.
RFC 3320第9.4.9节也没有说明当请求的反馈位置不等于零时，现有反馈数据会发生什么情况，但表示请求的反馈项存在/不存在的Q标志为零。在这种情况下，现有反馈数据应覆盖为“无反馈数据”。
The I-bit in requested feedback is a mechanism by which a compressor can tell a remote endpoint that it is not going to access any local state items. By doing so, it gives the remote endpoint the option of not advertising them in subsequent messages. Setting the I-bit does not obligate the remote endpoint to cease sending advertisements.
请求反馈中的I位是一种机制，通过该机制，压缩器可以告诉远程端点它将不访问任何本地状态项。这样，远程端点就可以选择不在后续消息中公布它们。设置I位不会强制远程端点停止发送播发。
The remote endpoint SHOULD still advertise its parameters such as DMS and state memory size (SMS). (This is particularly important; if the sender of the first message sets the I-bit, it will still want the advertisement of parameters from the receiver. If it doesn't receive these, it has to assume the default parameters which will affect compression efficiency.)
远程端点仍应公布其参数，如DMS和状态内存大小（SMS）。（这一点特别重要；如果第一条消息的发送方设置了I位，它仍然需要从接收方公布参数。如果它没有收到这些参数，它必须假定默认参数，这将影响压缩效率。）
The endpoint receiving an I-bit of 1 can reclaim the memory used to store the locally available state items. However, this has NO impact
接收I位为1的端点可以回收用于存储本地可用状态项的内存。然而，这没有影响
on any state that has been created by the sender using END-MESSAGE or STATE-CREATE instructions.
发送方使用结束消息或状态创建指令创建的任何状态。
Decompressor resources such as SMS and DMS can be dynamically updated at the compressor by use of the SMS and DMS bits in returned parameters feedback (see RFC 3320-Section 9.4.9). Changing resources dynamically (apart from initial advertisements for each compartment) is not expected to happen very often.
通过使用返回参数反馈中的SMS和DMS位，可以在压缩机上动态更新SMS和DMS等解压缩器资源（参见RFC 3320第9.4.9节）。动态地改变资源（除了每个隔间的初始广告）预计不会经常发生。
If additional resources are advertised to a compressor, then it is up to the implementation at the compressor whether or not to make use of these resources. For example, if the decompressor advertises 8k SMS but the compressor only has 4k SMS, then the compressor MAY choose not to use the extra 4k (e.g., in order to monitor state saved at the decompressor). In this case, there is no synchronization problem. The compressor MUST NOT use more than the most recently advertised resources. Note that the compressor SMS is unofficial (it enables the compressor to monitor decompressor state) and is separate from the SMS advertised by the decompressor.
如果向压缩器通告了额外的资源，那么是否使用这些资源取决于压缩器的实现。例如，如果解压器播发8k SMS，但压缩器只有4k SMS，则压缩器可以选择不使用额外的4k（例如，为了监控解压器保存的状态）。在这种情况下，不存在同步问题。压缩机使用的资源不得超过最近公布的资源。请注意，压缩机SMS是非官方的（它使压缩机能够监控减压器状态），并且与减压器发布的SMS分开。
Reducing the resources has potential synchronization issues and so SHOULD NOT be done unless absolutely necessary. If this is the case then the memory MUST NOT be reclaimed until the remote endpoint has acknowledged the message sent with the advertisement. If state is to be deleted to accommodate a reduction in SMS then both endpoints MUST delete it according to the state retention priority (see RFC 3320- Section 6.2). The compressor MUST NOT then use more than the amount of resources most recently advertised.
减少资源有潜在的同步问题，因此除非绝对必要，否则不应这样做。如果是这种情况，则在远程端点确认与播发一起发送的消息之前，不得回收内存。如果要删除状态以适应SMS的减少，则两个端点必须根据状态保留优先级将其删除（请参阅RFC 3320-第6.2节）。压缩机使用的资源量不得超过最近公布的资源量。
RFC 3320-Section 3.3.3 defines locally available state items to be the pieces of state that an endpoint has available but that have not been uploaded by the SigComp message. The examples given are dictionaries and well known pieces of bytecode; and the advertisement mechanism discussed in RFC 3320-Section 9.4.9 provides a way for the endpoint to advertise the pieces of locally available state that it has.
RFC 3320第3.3.3节将本地可用状态项定义为端点可用但未通过SigComp消息上载的状态片段。给出的例子是字典和众所周知的字节码；RFC 3320第9.4.9节中讨论的播发机制为端点提供了一种方法，用于播发其具有的本地可用状态。
However, SigComp [1] does not (nor was it ever intended to) fully define the use of locally available state items, in particular, the length of time for which they will be available. The use of locally available state items is left for definition in other documents. However, this fact, coupled with the fact that SigComp does contain some hooks for uses of locally available state items and the fact that some of the definitions of such uses (in SigComp Extended [2])
然而，SigComp[1]并未（也从未打算）完全定义本地可用状态项的使用，特别是它们可用的时间长度。本地可用状态项的使用留待其他文档定义。然而，这一事实，加上SigComp确实包含一些用于本地可用状态项的钩子，以及这些使用的一些定义（在SigComp扩展[2]中）的事实
are incomplete has caused some confusion. Therefore, this section clarifies the situation.
这些文件不完整造成了一些混乱。因此，本节澄清了这种情况。
Note that any definitions of uses of locally available state items MUST NOT conflict with any other uses.
请注意，本地可用状态项的任何使用定义不得与任何其他使用冲突。
SigComp provides a mechanism for an endpoint to advertise locally available state (RFC 3320-Section 9.4.9). If the endpoint receiving the advertisement does not 'recognize' it and therefore know the properties of the state e.g., its length and lifetime, the compressor needs to consider very carefully whether or not to access the state; especially if NACK [3] is not available.
SigComp为端点提供了一种公布本地可用状态的机制（RFC 3320第9.4.9节）。如果接收到广告的端点不识别它，因此知道该状态的属性，例如它的长度和寿命，则压缩机需要非常仔细地考虑是否访问该状态；尤其是当NACK[3]不可用时。
SigComp provides the following hooks for use in conjunction with locally available state items. Without further definition, locally available state SHOULD NOT be used.
SigComp提供以下钩子，与本地可用的状态项一起使用。如果没有进一步的定义，则不应使用本地可用状态。
RFC 3320-Section 6.2 allows for the possibility to map locally available state items to a compartment and states that, if this is done, the state items MUST have state retention priority 65535 in order to not interfere with state created at the request of the remote compressor. Note that Section 5.3 also recommends that only one such piece of state SHOULD be created per compartment.
RFC 3320第6.2节允许将本地可用状态项映射到隔间，并规定，如果这样做，状态项必须具有状态保留优先级65535，以便不干扰远程压缩机请求时创建的状态。注意，第5.3节还建议每个隔间仅创建一个这样的状态。
The I-bit in the requested_feedback_location (see RFC 3320-Section 9.4.9) allows a compressor to indicate to the remote endpoint that it will not reference any of the previously advertised locally available state. Depending on the implementation model for state handling at the remote endpoint, this could allow the remote endpoint to reclaim the memory being used by such state items.
请求的_反馈_位置中的I位（参见RFC 3320第9.4.9节）允许压缩器向远程端点指示它不会引用任何先前公布的本地可用状态。根据远程端点状态处理的实现模型，这可能允许远程端点回收这些状态项所使用的内存。
The most basic use of the local state advertisement is the advertisement of a dictionary (e.g., the dictionary specified by SIP/ SDP Static Dictionary [4]) or a piece of bytecode. In general, these pieces of state:
本地状态公告的最基本用途是公告字典（例如，SIP/SDP静态字典[4]指定的字典）或字节码。一般来说，这些状态：
o are not mapped to compartments o are local to the endpoint o are available for at least the duration of the compartment o do not have any impact on the compartment SMS
o 未映射到隔室o，在端点o本地，至少在隔室o的持续时间内可用，对隔室SMS没有任何影响
However, for a given piece of state the exact lifetime needs to be defined e.g., in public specifications such as SigComp for SIP [7] or
然而，对于给定的一段状态，需要定义确切的寿命，例如，在公共规范中，如SigComp for SIP[7]或
the 3GPP IMS specification [10]. Such a specification should also indicate whether or not advertisement of the state is needed.
3GPP IMS规范[10]。这种说明还应说明是否需要国家广告。
SigComp Extended [2] defines some uses of local state advertisements for which additional clarification is provided here.
SigComp Extended[2]定义了一些地方州广告的用途，此处对此进行了补充说明。
Shared-mode (see RFC 3321-Section 5.2) is well-defined (when combined with the clarification in Section 5.3). In particular, the states that are created and advertised are mapped into the compartment, have the minimum retention priority and persist only until they are deleted by the creation of new (non-minimum retention priority) state or use of a STATE-FREE instruction.
共享模式（见RFC 3321第5.2节）定义明确（与第5.3节中的说明相结合时）。特别是，创建和播发的状态映射到隔离舱中，具有最低保留优先级，并且仅在通过创建新（非最低保留优先级）状态或使用无状态指令将其删除之前保持不变。
The definition of endpoint initiated acknowledgments (RFC 3321- Section 5.1.2) requires clarification in order to ensure that the definition does not preclude advertisements being used to indicate that state will be kept beyond the lifetime of the compartment (as discussed in SigComp for SIP [7]). Thus the clarification is:
端点启动确认的定义（RFC 3321-第5.1.2节）需要澄清，以确保该定义不排除用于指示状态将保持在隔室寿命之外的广告（如SigComp中针对SIP[7]所述）。因此，澄清如下：
Where Endpoint A requests state creation at Endpoint B, Endpoint B MAY subsequently advertise the hash of the created state item to Endpoint A. This conveys to Endpoint A (i) that the state has been successfully created within the compartment; and (ii) that the state will be available for at least the lifetime of the state as defined by the state deletion rules according to age and retention priority of SigComp [1]. If the state is available at Endpoint B after it would be deleted from the compartment according to [1], then the state no longer counts towards the SMS of the compartment. Since there is no guarantee of such state being available beyond its normally defined lifetime, endpoints SHOULD only attempt to access the state after this time where it is known that NACK [3] is available.
当端点A请求在端点B处创建状态时，端点B可随后向端点A公布所创建状态项的散列。这向端点A（i）传达状态已在隔间内成功创建；以及（ii）根据SigComp的年龄和保留优先级，该州将至少在州删除规则定义的州的生存期内可用[1]。如果在根据[1]将其从隔室中删除之后，该状态在端点B处可用，则该状态不再计入隔室的SMS。由于无法保证此类状态在其正常定义的生存期之后可用，因此端点应仅在已知NACK[3]可用的时间之后尝试访问该状态。
It is possible to write bytecode that simply instructs the decompressor to output the entire message (effectively sending it uncompressed, but within a SigComp message). This is particularly useful if the bytecode is well-known (so that decompressors can recognize and output the bytes without running a VM if they wish); therefore, it is documented here.
可以编写字节码，简单地指示解压器输出整个消息（有效地将其未压缩发送，但在SigComp消息中）。如果字节码是众所周知的，这尤其有用（这样解压器可以在不运行VM的情况下识别和输出字节，如果他们愿意的话）；因此，本文对此进行了记录。
The mnemonic code is:
助记码是：
at (0)
:udvm_memory_size pad (2)
:cycles_per_bit pad (2)
:sigcomp_version pad (2)
:partial_state_id_length pad (2)
:state_length pad (2)
:reserved pad (2)
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:stack_location pad (2)
at (0)
:udvm_memory_size pad (2)
:cycles_per_bit pad (2)
:sigcomp_version pad (2)
:partial_state_id_length pad (2)
:state_length pad (2)
:reserved pad (2)
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:stack_location pad (2)
; Simple loop
; Read a byte
; Output a byte
; Until there are no more bytes!
; Simple loop
; Read a byte
; Output a byte
; Until there are no more bytes!
at (128) :start INPUT-BYTES (1, byte_copy_left, end) OUTPUT (byte_copy_left, 1) JUMP (start)
在（128）：开始输入字节（1，字节左，结束）输出字节左，1）跳转（开始）
:end END-MESSAGE (0,0,0,0,0,0,0)
：结束结束消息（0,0,0,0,0,0）
which translates to give the following SigComp message:
这将产生以下SigComp信息：
0xf8, 0x00, 0xa1, 0x1c, 0x01, 0x86, 0x09, 0x22, 0x86, 0x01, 0x16, 0xf9, 0x23
0xf8、0x00、0xa1、0x1c、0x01、0x86、0x09、0x22、0x86、0x01、0x16、0xf9、0x23
SIP/SDP Static Dictionary [4] provides a dictionary of strings frequently used in SIP and SDP messages. The format of the dictionary is the list of strings followed by a table of offset references to the strings so that a compressor can choose to reference the address of the string or the entry in the table. Both parts of the dictionary are divided into 5 prioritized sections to allow compressors to choose how much of it they use (which is particularly useful in the case where it has to be downloaded). If only part of the dictionary is used, then the corresponding sections of both parts (strings and offset table) are used.
SIP/SDP静态字典[4]提供了SIP和SDP消息中经常使用的字符串字典。字典的格式是字符串列表，后跟字符串的偏移量引用表，以便压缩器可以选择引用字符串的地址或表中的条目。字典的两个部分都分为5个优先部分，以允许压缩器选择使用多少（这在必须下载的情况下特别有用）。如果只使用字典的一部分，则使用两部分（字符串和偏移量表）的相应部分。
However, there are some minor bugs in the dictionary. In a number of places, the entry in the offset table refers to an address that is not in the corresponding priority section in the list of strings. Consequently, if the bytecode uses the offset table and limits use of the dictionary to priorities less than 4, then care must be taken not to use the following strings in the dictionary:
然而，字典中有一些小错误。在许多地方，偏移表中的条目指的是字符串列表中不在相应优先级部分的地址。因此，如果字节码使用偏移表并将字典的使用限制为优先级小于4，则必须注意不要在字典中使用以下字符串：
'application' at 0x0334 is not at priority 2 (it's priority 4) 'sdp' at 0x064b is not at priority 2 (it's priority 4) 'send' at 0x089d is not at priority 2 (it's priority 3) 'recv' at 0x0553 is not at priority 2 (it's priority 4) 'phone' at 0x00f2 is not at priority 3 (it's priority 4)
0x0334处的“应用程序”不在优先级2（它的优先级4）处的“sdp”不在优先级2（它的优先级4）处的“发送”不在优先级2（它的优先级3）处的“接收”不在优先级2（它的优先级4）处的“电话”不在优先级3（它的优先级4）
This document does not correct the dictionary, as any changes to the dictionary itself would be non-backwards-compatible, and require all implementations to maintain two different copies of the dictionary. Such a cost is far too high for a bug that is trivial to work around and has a negligible effect on compression ratios. Instead, the flaw is pointed out to allow implementers to avoid any consequent problems. Specifically, if the bytecode sent to a remote endpoint contains instructions that load only a sub-portion of the SIP/SDP dictionary, then the input stream provided to that bytecode cannot reference any of these five offsets in the offset table, unless the corresponding string portion of the dictionary has also been loaded. For example, if bytecode loads only the first three priorities of the dictionary (both string and offset table), use of the offset for "send" (at 0x089d) would be valid; however, use of the offset for "phone" (at 0x00f2) would not.
本文档不更正字典，因为对字典本身的任何更改都是不向后兼容的，并且要求所有实现维护字典的两个不同副本。对于一个微不足道的bug来说，这样的代价太高了，它对压缩比的影响可以忽略不计。相反，指出该缺陷是为了允许实现者避免任何后续问题。具体地说，如果发送到远程端点的字节码包含仅加载SIP/SDP字典的一个子部分的指令，则提供给该字节码的输入流不能引用偏移量表中这五个偏移量中的任何一个，除非字典的相应字符串部分也已加载。例如，如果字节码只加载字典的前三个优先级（字符串和偏移量表），则使用偏移量作为“发送”（0x089d）是有效的；但是，使用“phone”（在0x00f2处）的偏移量将不起作用。
This document updates SigComp [1], SigComp Extended [2], and the SigComp Static Dictionary [4]. The security considerations for [2] and [4] are the same as for [1]; therefore, this section discusses only how the security considerations for [1] are affected by the updates.
本文档更新了SigComp[1]、SigComp扩展[2]和SigComp静态字典[4]。[2]和[4]的安全考虑与[1]相同；因此，本节仅讨论更新如何影响[1]的安全注意事项。
Several security risks are discussed in [1]. These are discussed briefly here; however, this update does not change the security considerations of SigComp:
[1]中讨论了几种安全风险。这里简要地讨论了这些问题；但是，此更新不会更改SigComp的安全注意事项：
Snooping into state of other users - this is mitigated by using at least 48 bits from the hash. This update does not reduce the minimum and recommends use of more bits under certain circumstances.
窥探其他用户的状态-这可以通过使用散列中至少48位来缓解。此更新不会降低最小值，并建议在某些情况下使用更多位。
Faking state or making unauthorized changes - this is mitigated by the fact that the application layer has to authorize state manipulation. This update does not change that mechanism.
伪造状态或进行未经授权的更改—应用程序层必须授权状态操纵这一事实缓解了这种情况。此更新不会更改该机制。
Use of SigComp as a tool in a Denial of Service (DoS) attack - this is mitigated by the fact that SigComp only generates one decompressed message per incoming compressed message. That is not changed by this update.
在拒绝服务（DoS）攻击中使用SigComp作为工具-SigComp仅为每个传入的压缩消息生成一条解压缩消息，这一事实缓解了这种情况。此更新不会更改。
Attacking SigComp as the DoS target by filling with state - this is mitigated by the fact that the application layer has to authorize state manipulation. This update does not change that mechanism.
通过填充状态攻击SigComp作为DoS目标-应用层必须授权状态操作这一事实缓解了这种攻击。此更新不会更改该机制。
Attacking the UDVM by sending it looping code - this is mitigated by the upper limit of "UDVM cycles", which is unchanged by this update.
通过发送循环代码来攻击UDVM-这通过“UDVM周期”的上限得到缓解，该上限在此次更新中保持不变。
This document updates SigComp [1], but does not change the version. Consequently, the IANA considerations are the same as those for [1].
本文档更新了SigComp[1]，但未更改版本。因此，IANA考虑因素与[1]相同。
This document updates SigComp Extended [2], but does not change the version. Consequently, the IANA considerations are the same as those for [2].
本文档更新了SigComp Extended[2]，但未更改版本。因此，IANA考虑因素与[2]相同。
This document updates Static Dictionary [4], but does not change the version. Consequently, the IANA considerations are the same as those for [4].
本文档更新静态字典[4]，但不更改版本。因此，IANA考虑因素与[4]相同。
We would like to thank the following people who, largely through being foolish enough to be authors or implementors of SigComp, have provided us their confusion, suggestions, and comments:
我们要感谢以下人员，他们主要是由于愚蠢到成为SigComp的作者或实现者，向我们提供了他们的困惑、建议和意见：
Richard Price Lajos Zaccomer Timo Forsman Tor-Erik Malen Jan Christoffersson Kwang Mien Chan William Kembery Pekka Pessi
Richard Price Lajos Zaccomer Timo Forsman Tor Erik Malen Jan Christofferson Kwang Mien Chan William Kembery Pekka Pessi
[1] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[1] Price，R.，Borman，C.，Christofferson，J.，Hannu，H.，Liu，Z.，和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu, Z., and R. Price, "Signaling Compression (SigComp) - Extended Operations", RFC 3321, January 2003.
[2] Hannu，H.，Christofferson，J.，Forsgren，S.，Leung，K.，Liu，Z.，和R.Price，“信号压缩（SigComp）-扩展操作”，RFC 33212003年1月。
[3] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression)", RFC 4077, October 2004.
[3] Roach，A.，“信号压缩的否定确认机制”，RFC4077，2004年10月。
[4] Garcia-Martin, M., Borman, C., Ott, J., Price, R., and A. Roach, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003.
[4] Garcia Martin，M.，Borman，C.，Ott，J.，Price，R.，和A.Roach，“会话启动协议（SIP）和会话描述协议（SDP）信令压缩静态字典（SigComp）”，RFC 3485，2003年2月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications (ABNF)", RFC 2234, November 1997.
[6] Crocker，D.和P.Overell，“语法规范的扩充BNF（ABNF）”，RFC 2234，1997年11月。
[7] Borman, C., Liu, Z., Price, R., and G. Camarillo, "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)", Work in Progress, November 2006.
[7] 《将信号传输应用于通信协议》（2006年11月，Sig，Borlo，C.）和《将信号传输应用于通信协议》（2006年11月）。
[8] Ritter, T., "Estimating Population from Repetitions in Accumulated Random Samples", 1994, <http://www.ciphersbyritter.com/ARTS/BIRTHDAY.HTM>.
[8] Ritter，T.“根据累积随机样本中的重复估计总体”，1994年<http://www.ciphersbyritter.com/ARTS/BIRTHDAY.HTM>.
[9] 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.
[9] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[10] "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP)", October 2006.
[10] “基于会话启动协议（SIP）的IP多媒体呼叫控制协议”，2006年10月。
Appendix A. Dummy Application Protocol (DAP)
附录A.虚拟应用协议（DAP）
This appendix defines a simple dummy application protocol (DAP) that can be used for SigComp interoperability testing. This is handy for SigComp implementations that are not integrated with a SIP stack. It also provides some features that facilitate the testing of SigComp internal operations.
本附录定义了可用于SigComp互操作性测试的简单虚拟应用程序协议（DAP）。这对于未与SIP堆栈集成的SigComp实现非常方便。它还提供了一些有助于测试SigComp内部操作的功能。
The message format is quite simple. Each message consists of a 8-line message-header, an empty line, and an OPTIONAL message-body. The style resembles that of SIP and HTTP.
消息格式非常简单。每条消息由8行消息头、空行和可选消息正文组成。该样式类似于SIP和HTTP。
The exact message format is given later in augmented Backus-Naur Form (ABNF) [6]. Here are a few notes:
确切的消息格式在后面的增广巴科斯诺尔格式（ABNF）[6]中给出。以下是一些注意事项：
Each line of message-header MUST be terminated with CRLF.
每行消息头必须以CRLF终止。
The empty line MUST be present even if the message-body is not.
即使消息正文不存在，空行也必须存在。
Body-length is the length of the message-body, excluding the CRLF that separates the message-body from the message-header.
Body length是消息正文的长度，不包括将消息正文与消息头分开的CRLF。
All strings in the message-header are case-insensitive.
消息头中的所有字符串都不区分大小写。
For implementation according to this appendix, the DAP-version MUST be set to 1.
为了根据本附录实施，DAP版本必须设置为1。
A message with an invalid format will be discarded by a DAP receiver
DAP接收器将丢弃格式无效的消息
For testing purposes, a message with a valid format will be returned to the original sender (IP address, port number) in clear text, i.e., without compression. This is the case even if the sender requests this receiver to reject the message. Note that the entire DAP message (message-header + CRLF + message-body) is returned. This allows the sender to compare what it sent with what the receiver decompressed.
出于测试目的，具有有效格式的消息将以明文形式返回给原始发件人（IP地址、端口号），即不进行压缩。即使发送方请求接收方拒绝消息，也会出现这种情况。请注意，将返回整个DAP消息（消息头+CRLF+消息体）。这允许发送方将其发送的内容与接收方解压缩的内容进行比较。
Endpoint-ID is the global identifier of the sending endpoint. It can be used to test the case where multiple SigComp endpoints communicate with the same remote SigComp endpoint. For simplicity, the IPv4 address is used for this purpose.
端点ID是发送端点的全局标识符。它可用于测试多个SigComp端点与同一远程SigComp端点通信的情况。为简单起见，IPv4地址用于此目的。
Compartment-ID is the identifier of the *compressor* compartment that
the *sending* endpoint used to compress this message. It is assigned
Compartment-ID is the identifier of the *compressor* compartment that
the *sending* endpoint used to compress this message. It is assigned
by the sender and therefore only unique per sending endpoint; i.e., DAP messages sent by different endpoints MAY carry the same compartment-ID. Therefore, the receiver SHOULD use the (endpoint-ID, compartment-ID) pair carried in a message to determine the decompressor compartment identifier for that message. The exact local representation of the derived compartment identifier is an implementation choice.
由发送方提供，因此每个发送端点都是唯一的；i、 例如，不同端点发送的DAP消息可能携带相同的隔间ID。因此，接收方应使用消息中携带的（端点ID，隔间ID）对来确定该消息的减压器隔间标识符。派生隔间标识符的精确局部表示是一种实现选择。
To test SigComp feedback [1], peer compartments between two endpoints are defined in DAP as those with the same compartment-ID. For example, (endpoint-A, 1) and (endpoint-B, 1) are peer compartments. That means, SigComp feedback for a DAP message sent from compartment 1 of endpoint-A to endpoint-B will be piggybacked on a DAP message sent from compartment 1 of endpoint-B to endpoint-A.
为了测试SigComp反馈[1]，DAP中将两个端点之间的对等隔室定义为具有相同隔室ID的隔室。例如，（端点A，1）和（端点B，1）是对等隔室。这意味着，从endpoint-a的隔室1发送到endpoint-B的DAP消息的SigComp反馈将在从endpoint-B的隔室1发送到endpoint-a的DAP消息上进行。
A DAP receiver will follow the instruction carried in message-header line-5 to either accept or reject a DAP message. Note: line-6 and line-7 will be ignored if the message is rejected.
DAP接收器将按照消息头行-5中的指令接受或拒绝DAP消息。注意：如果消息被拒绝，第6行和第7行将被忽略。
A DAP receiver will follow the instruction in line-6 to create or close the decompressor compartment that is associated with the received DAP message (see above).
DAP接收器将按照第6行中的指示创建或关闭与接收到的DAP消息相关联的减压室（见上文）。
If line-7 of a received DAP message-header carries "TRUE", the receiver will send back a response message to the sender. This allows the test of SigComp feedback. As mentioned above, the response message MUST be compressed by, and sent from, the local compressor compartment that is a peer of the remote compressor compartment. Other than this constraint, the response message is just a regular DAP message that can carry arbitrary message-header and message-body. For example, the "need-response" field of the response can also be set to TRUE, which will trigger a response to response, and so on. Note that since each endpoint has control over the "need-response" field of its own messages, this does not lead to a dead loop. A sensible implementation of a DAP sender SHOULD NOT blindly set this field to TRUE unless a response is desired. For testing, the message-body of a response MAY contain the message-header of the original message that triggered the response.
如果收到的DAP消息头的第7行带有“TRUE”，则接收方将向发送方发回响应消息。这允许测试SigComp反馈。如上所述，响应消息必须由远程压缩机房的对等本地压缩机房压缩并发送。除了这个约束之外，响应消息只是一个常规的DAP消息，可以携带任意的消息头和消息体。例如，响应的“需要响应”字段也可以设置为TRUE，这将触发对响应的响应，依此类推。请注意，由于每个端点都可以控制自己消息的“需要响应”字段，因此这不会导致死循环。DAP发送方的合理实现不应盲目地将此字段设置为TRUE，除非需要响应。对于测试，响应的消息体可能包含触发响应的原始消息的消息头。
Message-seq can be used by a DAP sender to track each message it sends, e.g., in case of losses. Message loss can happen either on the path or at the receiving endpoint (i.e., due to decompression failure). The assignment of message-seq is up to the sender. For example, it could be either assigned per compartment or per endpoint. This has no impact on the receiving side.
DAP发送方可以使用Message seq跟踪其发送的每条消息，例如在丢失的情况下。消息丢失可能发生在路径上，也可能发生在接收端点（即，由于解压缩失败）。message seq的分配由发送方决定。例如，它可以分配给每个隔间或每个端点。这对接收端没有影响。
(Note: see (ABNF) [6] for basic rules.)
（注：基本规则见（ABNF）[6]）
DAP-message = message-header CRLF [ message-body ]
DAP消息=消息头CRLF[消息正文]
message-body = *OCTET
message-body = *OCTET
message-header = line-1 line-2 line-3 line-4 line-5 line-6 line-7 line-8
消息头=第1行第2行第3行第4行第5行第6行第7行第8行
line-1 = "DAP-version" ":" 1*DIGIT CRLF
line-2 = "endpoint-ID" ":" IPv4address CRLF
line-3 = "compartment-ID" ":" 1*DIGIT CRLF
line-4 = "message-seq" ":" 1*DIGIT CRLF
line-5 = "message-auth" ":" ( "ACCEPT" / "REJECT" ) CRLF
line-6 = "compartment-op" ":" ( "CREATE" / "CLOSE" / "NONE" ) CRLF
line-7 = "need-response" ":" ( "TRUE" / "FALSE" )
line-8 = "body-length" ":" 1*DIGIT CRLF
line-1 = "DAP-version" ":" 1*DIGIT CRLF
line-2 = "endpoint-ID" ":" IPv4address CRLF
line-3 = "compartment-ID" ":" 1*DIGIT CRLF
line-4 = "message-seq" ":" 1*DIGIT CRLF
line-5 = "message-auth" ":" ( "ACCEPT" / "REJECT" ) CRLF
line-6 = "compartment-op" ":" ( "CREATE" / "CLOSE" / "NONE" ) CRLF
line-7 = "need-response" ":" ( "TRUE" / "FALSE" )
line-8 = "body-length" ":" 1*DIGIT CRLF
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
DAP-version: 1 endpoint-ID: 123.45.67.89 compartment-ID: 2 message-seq: 0 message-auth: ACCEPT compartment-op: CREATE need-response: TRUE body-length: 228
DAP版本：1端点ID:123.45.67.89隔室ID:2消息序列：0消息验证：接受隔室操作：创建需要响应：真实体长：228
This is a DAP message sent from SigComp endpoint at IP address 123.45.67.89. This is the first message sent from compartment 2. Please accept the message, create the associated compartment, and send back a response message.
这是从IP地址为123.45.67.89的SigComp端点发送的DAP消息。这是从2舱发送的第一条信息。请接受该消息，创建关联的隔室，然后发回响应消息。
Authors' Addresses
作者地址
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Abigail Surtees西门子/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国
Phone: +44 (0)1794 833131
EMail: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Phone: +44 (0)1794 833131
EMail: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Mark A.West Siemens/Roke Manor Research Roke Manor Research Ltd.Romsey，Hants SO51 0ZN英国
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
美国德克萨斯州达拉斯坎贝尔路17210号Adam Roach Estacado Systems 250室，邮编75252
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。