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
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 3320、RFC 3321、およびRFC 3485：このドキュメントでは、次のRFCを更新します。
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
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で」「RFC 3320、セクション3.4の」このドキュメントのセクション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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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であることを述べています。 、nがUDP及び（DMS / 2）を介してトランスポートメッセージのため、のSigCompメッセージのサイズであるTCPを介して転送するためのもの - UDVMメモリサイズは（N DMS）であることがRFC 3320、セクション7で定義されています。つまり、メッセージは、バイトコードを含む場合（それがための少なくとも最初のメッセージであろうように）実際にデコンプレッサメモリ内のバイトコードの2つのコピーが存在することになる（図1参照します）。デコンプレッサメモリのバイトコードの第2のコピーの存在が、この場合に正しいです。
|<----------------------------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.
多くの実装のために、送信された復元バイトコードの長さは304バイトの範囲内です。 SigCompのは、2KのデフォルトDMSを指定しているため、記載の方式は、深刻な循環バッファの、圧縮メッセージ自体のサイズを制限します。いくつかのケースでは、状況のこのセットは、圧縮率に有害な効果を有しています。他人のために、それは圧縮された特定のメッセージを送信することは完全に不可能になります。
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メモリサイズは、TCPベースのプロトコル400 + 2432 = 2832であり、これは、DMSが8Kに切り上げられ、少なくとも5664（2832 * 2）バイトでなければならないことを意味します。 UDPベースのプロトコルのために、一つは考慮のSigCompメッセージ自体のサイズを取る必要があります。 （以前のメッセージ履歴なし）50％の単一のメッセージを圧縮するのに十分な平均エントロピーのテキストベースのプロトコルを仮定すると、サイズで8192バイトを超えることはないと予想されるメッセージは、プロトコルメッセージ自体は、SigCompのに4096バイトを追加します（バイトコードの400バイトの上にプラス3バイトのヘッダ）メッセージサイズ、または4096 + 400 = 4499. + 3 DMSを計算するために、一方が必要UDVMメモリサイズにこれを追加する必要があります= 6531 + 4499 2832、これは再びDMSの8Kに切り上げられます。
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.
例えば、メッセージの残りのバイトがある場合：0×01 0×02 0×03とUDVMは、入力バイト（6、a、b）は命令に遭遇します。次いで、デコンプレッサディスパッチャにはバイトを返さないと、bで指定された命令にジャンプします。デコンプレッサディスパッチャが正常バイトが0x01と0x02のを返すように、これは、入力バイト（2、C、D）の命令を含みます。
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.
INPUTバイト（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)
（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パッド（2）：location_bパッド（2）：location_cパッド（2）パッド（30）：udvm_memory_sizeパッド（2）：circular_bufferパッド（2）
align (64)
（64）を整列させます
MULTILOAD (location_a, 3, circular_buffer, udvm_memory_size, $location_a)
MULTILOAD（location_a、3、circular_buffer、udvm_memory_size、$ 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.
ステップバイステップの実装では、あろう：location_a（メモリアドレス64）にcircular_bufferのアドレスを書き込みます。 location_aにudvm_memory_size + 2（メモリアドレス66）のアドレスを書き込みます。 location_a + 4（メモリアドレス68）に - （今circular_bufferのアドレスであるインダイレクションを使用してアクセス）location_aに格納された値を書き込みます。したがって、正しい実装による実行の終わりに、location_cはcircular_bufferのアドレスを含むことになります。
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.
STATE-FREE命令はminimum_access_lengthをチェックしません。アプリケーションがメッセージを認証したまで状態を解放することができないので、これは正しいです。送信者が認証されたメッセージを作成するのに十分な情報を持っている場合は、とにかくストレージのうち、以前の状態をプッシュすることができます状態を保存するメッセージを送信するためのチェックの欠如は、セキュリティ上のリスクをもたらすことはありません。
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 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'.
命令は、POP、CALL、およびRETURNがメモリ内にスタックが配置されている場所を定義することがよく知られているメモリアドレスstack_locationを使用して設定されているスタックを利用するプッシュ。スタックの使用は述べRFC 3320、セクション8.3で定義されている：「スタック上の値は[stack_fill】積層する値をコピーした後、1だけ増加stack_fillの略語である 『押します』」そして、「stack_fillはstack_locationとstack_location + 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).
値がスタックにプッシュされたときstack_fillの値が0xFFFFであることが非常にまれなケースでは、元のstack_fill値は0x0000に1ずつ増加しなければならなくて、stack_locationとstack_location + 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の] = stack_locationスタックに書き込まれています。 Stack_fillは、1ずつ増加されるだろう。しかし、stack_locationとstack_location + 1の値が更新されたばかり。オーバーやアンダーフローに関して、スタックの整合性を維持するために、stack_fillは、この時点で再度読み込むことができない、とプッシュ値が上書きされます。
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によって設定された境界を尊重バイトのストリングは、メモリアドレスの昇順にコピーされ、」。 byte_copy_leftとbyte_copy_rightによって設定された境界の外でバイトをコピーすることは完全に合法であることを誤解しています。 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
もしcurrent_byte ==（（byte_copy_right - 1）のmod 2 ^ 16）：next_byte = byte_copy_left他：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
もしcurrent_byte == byte_copy_left：previous_byte =（byte_copy_right - 1）2 ^ 16他のMOD：previous_byte =（current_byte - 1）のmod 2 ^ 16
Moving to the left is only used for COPY_OFFSET.
左に動かすとだけ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 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).
介護が原因に解凍失敗を防ぐために取られなければならないのにその結果、コピーが（byte_copy_leftの左に開始し、それを越え続ける（および必要に応じて与えられたアルゴリズムに従ってそれに戻ってジャンプ）とbyte_copy_rightの右側に以上に始めることができる可能性が）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:
さらに明確にするために：それぞれ「BCL」と「BCR」によって示される場所にbyte_copy_leftとbyte_copy_rightと、次のようにレイアウトされたUDVMメモリを考慮してください。
+----------------------------------------+
| |
+----------^------------^----------------+
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
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
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
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
This document amends the list of instructions that obey byte copying rules in RFC 3320-Section 8.4 to include STATE-CREATE and CRC.
この文書では、とCRC-CREATE STATEが含まれるように8.4 RFC 3320 - セクションにバイトのコピー規則に従う命令のリストを修正します。
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.
RFC 3320 - セクション8.4には、バイトのコピールールを指定し、それらに従う命令のリストが含まれています。 STATE-CREATE、このリストではありませんが、END-MESSAGEです。これは、どちらの命令が実際に任意のバイトのコピーをしているという事実に混乱を引き起こしました。むしろ、両方の命令は状態を作成するために、状態ハンドラに情報を与えます。論理的には、両方の命令は、バイトのコピーについて同じ情報を持つ必要があります。
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.
状態が状態ハンドラにより作成されたとき（かEND-MESSAGEまたはSTATE-CREATE命令から）、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).
なお、STATE-CREATE命令及び状態が作成されるの発生との間UDVM変化の内容が、格納されたバイトは、作成時にバッファ中のものである場合（すなわち、メッセージは、解凍されたときと認証されました）。
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.
CRCは、バイトのコピー規則に従う命令のリストで、RFC 3320、セクション8.4で言及されていませんが、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.
STATE-FREE命令のための部分的な識別子はRFC 3320、セクションごとにバイトのコピー規則（END-MESSAGEの実行中）、読み込まれると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.
END-MESSAGE命令内の状態を作成し、解放のためのバッファの読み取りがバイトのコピー規則に従うことを考えることは、フィードバック項目を読むことも、バイトのコピー規則に従うべきかどうかについてのいくつかの混乱があるかもしれません。バイトコピー規則は、フィードバックの項目を読み込むには適用されません。
For state_retention_priority, 65535 < 0 < 1 < ... < 65534. This is slightly counter intuitive, but is correct.
state_retention_priorityのために、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:
状態の同じ部分が2つの異なる保持優先順位で作成されたときに混乱があるかもしれません。以下は、このことを明確に：
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]）は、実際の状態が、各コンパートメントは、自身のプライオリティと状態のこの作品の記録を維持する必要があります。 （この状態が優先順位が使用されているかに応じて、Bが予想よりも予想される以下の時間よりも長く保持することができ、その後に発生していない場合。これは、解凍の失敗が発生する可能性があります。）
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に記載されている共有モードの以下の実施例を考慮することによって示すことができる[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)]
Endpoint A Endpoint B [decomp cpt] [comp cpt]
エンドポイントAエンドポイントB [分解のCPT] [コンプCPT]
[SM1]
------------------------------->
[SM1]
[SM1, SM2]
--------------------X (message lost)
[SM1, BC, BF1]
<------------ref SM1------------
[SM2, BC, BF1]
endpoint B still believes SM1
is at endpoint A
[BC, BF1, BF2]
<------------ref SM1------------
decompression failure at A because SM1 has already been deleted
Aでの解凍に失敗SM1はすでに削除されているので、
Example 2:
例2：
Endpoint A Endpoint B
[decomp cpt] [comp cpt]
[SM1]
------------------------------->
[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, BC, BF1, BF2]
<------------ref SM1------------
[SM2, BC, BF2]
endpoint B still believes SM1
is at endpoint A
[BC, BF1, BF2, BF3]
<------------ref SM1------------
decompression failure at A because SM1 has already been deleted
Aでの解凍に失敗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の生成を引き起こして回避するための圧縮機のために、それはピア圧縮機の動作に関するいくつかの仮定を行うことができなければなりません。エンドポイントの1つは、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.
圧縮機が最小の優先状態の新しい作品を作成することができるようにリモートエンドポイントを希望する場合、それは状態の既存の部分を除去するために、STATE-FREE命令を使用することができることに留意されたいです。
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).
状態の作品を作成するときに、フル20バイトのハッシュが、この識別子を持つ状態の別の部分が存在するか否かを確認するためにチェックされるべきであることをRFC 3320、セクション6.2の状態。それがないと、状態項目が同一でない場合、新しい作成は失敗しなければなりません。この発生の確率は無視できるほど小さいことが述べられている（そしてそれは、以下を参照されます）。
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バイトが使用され、状態識別子の同一の第1のnバイトを有する状態の二枚、存在する場合、nは、この時点で6限り低くすることができた場合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])).
誕生日のパラドックス考えてみましょう（そのうちの2つが同じ誕生日を持っていることを、50％以上の確率で（誕生日を持っているだけで部屋に23人があるように持っている[8]））。
The naive calculation using factorials gives:
階乗を使用して素朴な計算ができます：
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
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：パラジウム（N、S）= 0.018パーセント、S = 10 000 000：パラジウム（N、S）= 16.28パーセントS = 100 000 000：パラジウム（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：パラジウム（N、S）= 3.42E-35％S = 10 000 000：パラジウム（N、S）= 3.42E-33％S = 100 000 000：パラジウム（N、S）= 3.42 E-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] misorderedメッセージの可能性にのみ参照します。しかし、「コンプレッサは、メッセージがリモートエンドポイントで利用可能なリソースを使用して解凍することができていることを確認しなければならない」という文は発生して誤った順序の可能性を考慮して、コンプレッサに責任を置きます。
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節の状態。しかしながら、フィードバックは例えば、（複数回送信されることが有益である場合があり、再送された200 OK SIPメッセージは、[9]は、SIP INVITEメッセージに元の200 OKことを意味し、それは実施フィードバック、かもしれません）リモートエンドポイントに達していません。それがフィードバックを更新し、別の有効なメッセージを受信するまでそのため、エンドポイントを繰り返し、フィードバックを送信する必要があります。
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はrequested_feedback_locationがゼロに等しいとき、何のフィードバック要求がなされていないと述べています。しかし、これは既存のフィードバックデータを放置又はこれは、既存のフィードバックデータは「は、フィードバックデータ」ではないと上書きされるべきであることを意味する場合にされていることを意味するかどうかの兆候はありません。 requested_feedback_locationがゼロに等しい場合は、既存のフィードバックデータはそのまま残し、以前のように任意の後続のメッセージで返されるべきである（SHOULD）。
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もrequested_feedback_locationがrequested_feedback_itemの存在/不在を示すゼロが、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 on any state that has been created by the sender using END-MESSAGE or STATE-CREATE instructions.
1のIビットを受信したエンドポイントは、ローカルに利用可能な状態のアイテムを格納するために使用されるメモリを解放することができます。しかし、これはEND-MESSAGEまたはSTATE-CREATE命令を使用して、送信者によって作成された任意の状態には影響を与えません。
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などのデコンプレッサリソースを動的に（RFC 3320、セクション9.4.9を参照）が返さパラメータフィードバックにおけるSMSおよびDMSビットを使用することにより、圧縮機で更新することができます。リソースを動的に変更する（離れて各区画の初期広告から）非常に頻繁に発生すると予想されていません。
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.
requested_feedback_locationで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コンパートメントSMS上の任意の影響を持っていない区画Oの少なくとも期間のエンドポイント0に区画Oに利用可能なローカルされているマップされていません
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
しかし、状態の所与の部分の正確な寿命は、SIPのためのSigCompとして公的規格で、例えば、定義される必要がある[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の拡張[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項で明確と組み合わせた場合）、明確に定義されています。特に、作成され、宣伝されている状態は、区画内にマッピングされた最小保存の優先度を持っており、それらはSTATE-FREE命令の新しい（非最小保持優先）状態や使用の創設によって削除されるまでだけ持続しています。
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:
エンドポイントの定義は、SIPのためにSigCompで説明したように肯定応答（RFC 3321-セクション5.1.2）の定義は、その状態を示すために使用されている広告を排除しないことを保証するために明確化を必要とするが、区画（の寿命を超えて維持される開始しました[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)
（0）で：udvm_memory_sizeパッド（2）：cycles_per_bitパッド（2）：sigcomp_versionパッド（2）：partial_state_id_lengthパッド（2）：state_lengthパッド（2）：（64）で予約パッド（2）：パッドbyte_copy_left（2） ：byte_copy_rightパッド（2）：パッドinput_bit_order（2）：stack_locationパッド（2）
; 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）において：INPUTバイト（1、byte_copy_left、エンド）出力を開始（byte_copy_left、1）JUMP（開始）
:end END-MESSAGE (0,0,0,0,0,0,0)
：エンドEND-MESSAGE（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)
0x064bに0x0334に「アプリケーション」の優先度2（それの優先度4）ではありません「SDP」は優先度2（それの優先度4）ではない0x089dで「送信」0x0553で優先度2で（それの優先順位3）「RECV」ではありません0x00f2で（それの優先順位4）「電話」は、優先度3（それの優先順位4）ではない、優先度2ではありません
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.
この文書は、辞書への変更は、それ自体が非後方互換であるように、辞書を修正し、辞書の二つの異なるコピーを維持するために、すべての実装を必要としません。このようなコストが高すぎるを回避するには自明であると圧縮率にほとんど影響を持っているバグのためです。代わりに、欠陥は実装がどんな結果的な問題を回避できるようにするために指摘されています。リモートエンドポイントに送信されたバイトコードがSIP / SDP辞書のみサブ部分をロードする命令が含まれている場合、具体的に、そのバイトコードに提供された入力ストリームは、対応する文字列がない限り、オフセットテーブルにこれらの5つのオフセットのいずれかを参照することはできません辞書の部分もロードされています。例えば、辞書（文字列とオフセットテーブルの両方）のバイトコードをロードのみ最初の三つの優先順位の使用有効であろう（0x089dで）「送信」のオフセット。しかし、（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 [4] [2]、およびSigCompの静的辞書を拡張更新します。 [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.
これは、SigCompのが唯一の受信圧縮メッセージごとに圧縮解除メッセージを生成するという事実によって緩和される - サービス拒否（DoS）攻撃ツールとしての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.
状態で充填することにより、DoS攻撃の標的としてのSigCompを攻撃 - これは、アプリケーション層は、状態操作を許可しなければならないという事実によって軽減されます。このアップデートは、そのメカニズムは変更されません。
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].
この文書では、[1]のSigCompを更新しますが、バージョンを変更しません。したがって、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].
この文書では、[2]にSigCompが拡張更新しますが、バージョンを変更しません。したがって、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
リチャード価格ラヨシュZaccomerティモForsmanのTor-エリック男性月ChristofferssonクァンチャンミエンウィリアムKemberyペッカPessi
[1] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[1]価格、R.、ボーマン、C.、Christoffersson、J.、ハンヌ、H.、劉、Z.、およびJ.ローゼンバーグ、 "シグナリング圧縮（SigCompの）"、RFC 3320、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]ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.、劉、Z.、およびR.価格、 "シグナリング圧縮（SigCompの） - 拡張操作"、RFC 3321、2003年1月。
[3] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression)", RFC 4077, October 2004.
[3]ローチ、A.、 "シグナリング圧縮のための否定応答メカニズム）"、RFC 4077、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]ガルシア - マーチン、M.、ボーマン、C.、オット、J.、価格、R.、およびA.ローチ、「シグナリング圧縮のためのセッション開始プロトコル（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、RFC 2119、1997年3月を。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications (ABNF)", RFC 2234, November 1997.
[6]クロッカー、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]ボーマン、C.、劉、Z.、価格、R.、およびG.カマリロを、進歩、2006年11月に作品 "セッション開始プロトコル（SIP）にシグナリング圧縮（SigCompの）を適用します"。
[8] Ritter, T., "Estimating Population from Repetitions in Accumulated Random Samples", 1994, <http://www.ciphersbyritter.com/ARTS/BIRTHDAY.HTM>.
[8]リッター、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[10] "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP)", October 2006.
[10]、2006年10月「セッション開始プロトコル（SIP）に基づくIPマルチメディア呼制御プロトコル」。
Appendix A. Dummy Application Protocol (DAP)
付録A.ダミーアプリケーションプロトコル（DAP）
A.1. Introduction
A.1。前書き
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.
本体長は、メッセージヘッダからメッセージボディを分離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.2. Processing a DAP Message
A.2。 DAPメッセージを処理
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 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.
区画-IDは、*送信エンドポイントは、このメッセージを圧縮するために使用*圧縮*コンパートメントの識別子です。これは、送信者とエンドポイントを送信するごとにそのためだけユニークで割り当てられます。すなわち、異なるエンドポイントによって送信された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]、2つのエンドポイント間のピアコンパートメントは同じコンパートメント-IDを有するものとしてDAPで定義されています。例えば、（エンドポイントA、1）及び（エンドポイントB、1）は、ピア区画です。つまり、エンドポイントBにエンドポイントAの区画1から送信されたDAPメッセージのためのSigCompフィードバック-AをエンドポイントするエンドポイントBの区画1から送信された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受信機は、DAPメッセージを受け入れるか、または拒否のいずれかにメッセージヘッダ行-5で搬送指示に従います。注意：メッセージが拒否された場合、ライン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の受信機は、受信されたDAPメッセージ（上記参照）に関連付けられているデコンプレッサ区画を作成するか、または閉じるためのライン6の命令に従います。
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.
ライン7受信DAPメッセージヘッダのが「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の送信者によって使用することができます。メッセージ損失は（原因伸張失敗に、すなわち、）パスまたは受信エンドポイントのいずれかで起こり得ます。メッセージ配列の割り当ては、送信者に任されています。例えば、それはどちらかの区画ごとまたはエンドポイントごとに割り当てることができます。これは、受信側に影響を及ぼしません。
A.3. DAP Message Format in ABNF
A.3。 ABNFでDAPメッセージ形式
(Note: see (ABNF) [6] for basic rules.)
（注：基本的なルールのために[6]（ABNF）参照）。
DAP-message = message-header CRLF [ message-body ]
DAP-メッセージ=メッセージヘッダーCRLF [メッセージ本体]
message-body = *OCTET
メッセージボディ= * 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
ライン-1 = "DAP-バージョン" "：" 1 * DIGITのCRLFライン-2 = "エンドポイントID" "：" 線-3 = "区画-ID" IPv4AddressをCRLF "：" 1 * DIGITのCRLFライン-4 = "メッセージ配列" "：" 1つの* DIGITのCRLFライン-5 = "メッセージ-AUTH" "："（ "ACCEPT" / "拒否"）CRLFライン-6 = "区画-OP" "："（ "" を作成/ "CLOSE" / "NONE"）CRLFライン7 = "必要応答" "："（ "TRUE" / "FALSE"）ライン8 = "本体の長さ" "：" 1 * DIGIT CRLF
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
= 1 * 3DIGIT IPv4Addressを "" 1 * 3DIGIT "" 1 * 3DIGIT "" 1 * 3DIGIT
A.4. An Example of a DAP Message
A.4。 DAPメッセージの例
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
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
アビゲイルサーティースシーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国
Phone: +44 (0)1794 833131 EMail: abigail.surtees@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833131 Eメール：URI abigail.surtees@roke.co.uk：http://www.roke.co.uk
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
マーク・A.西シーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国
Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833311 Eメール：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
アダムローチEstacadoシステム17210キャンベルRdを。スイート250、ダラス、TX 75252米国
Phone: sip:adam@estacado.net EMail: adam@estacado.net
電話：SIP：adam@estacado.net Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。