[要約] RFC 4896は、SigCompプロトコルの修正と明確化に関するものであり、SigCompの実装と使用に関する誤りや不明点を解決することを目的としています。
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）The IETF Trust（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
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-Section 3.4のこのドキュメントのセクション3.4を参照してください。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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であると述べています。UDVMメモリサイズは、RFC 3320 -Section 7では（DMS -N）に定義されます。ここで、nはsigcompメッセージのサイズ、UDPを介して輸送されるメッセージ、および（DMS / 2）がTCPを介して輸送されたものに対して（DMS / 2）です。これは、メッセージにバイトコードが含まれている場合（少なくとも最初のメッセージの場合）、実際には減圧剤メモリ内のバイトコードの2つのコピーがあることを意味します（図1を参照）。この場合、減圧器メモリにBytecodeの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内のBYTECODEおよび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.
多くの実装では、送信される減圧バイトコードの長さは3〜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の使用を義務付けている人々は、適切なサイズのDMの使用を義務付けているアプリケーションにさらに仕様を提供する必要があります。このようなDMのサイジングは、（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）バイトでなければならないことを意味します。UDPベースのプロトコルの場合、SigCompメッセージ自体のサイズを考慮する必要があります。単一のメッセージを50％（以前のメッセージ履歴なし）と圧縮するのに十分な平均エントロピーを備えたテキストベースのプロトコル、およびサイズが8192バイトを超えると予想されないメッセージ自体がSIGCOMPに4096バイトを追加しますメッセージサイズ（400バイトのバイトコードと3バイトヘッダーの上に）、つまり4096 400 3 = 4499。最大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-Section 9.4.2）と入力ビット（RFC 3320-Section 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）命令が含まれているため、Decompressor Dispatcherはバイト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 (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.
段階的な実装をより簡単にするために、マルチロード命令は、マルチロードオペコードまたはそのパラメーターによって占有されているメモリ位置に書き込むことを明示的に許可されていません。さらに、パラメーターの間接がある場合、実行時に間接を行う必要があります。
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)
align (64)
align（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.
ステップバイステップの実装は、circular_bufferのアドレスをlocation_a（メモリアドレス64）に書き込みます。udvm_memory_sizeのアドレスをlocation_a 2（メモリアドレス66）に書き込みます。location_a（間接を使用してアクセス - 現在はcircular_bufferのアドレスにアクセス）に保存されている値をlocation_a 4（メモリアドレス68）に書き込みます。したがって、正しい実装による実行の最後に、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.
州のない命令では、最小限の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.
州のない命令は、減圧されているメッセージに対応するコンパートメント内の自由状態のみができます。別のコンパートメントからの状態、またはコンパートメントに関連付けられていない状態を解放しようとすると、効果がありません。
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'.
命令は、よく知られているメモリアドレスstack_locationを使用してセットアップされたスタックをプッシュ、ポップ、コール、および返すようにして、メモリの場所を定義します。スタックの使用は、RFC 3320-Section 8.3で定義されています。これは、「スタック」の値を「「Stack_fill」にコピーするための略語であり、Stack_fillを1倍にするための略語である」と述べています。'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の値がStackにプッシュされた場合、stack_fillの値が0xffffであるという非常にまれな場合、元のstack_fill値は1から0x0000増加し、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.
スタックに押し込まれた新しい値は、理論的には、stack [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-section 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
which is equivalent to the algorithm given in RFC 3320-Section 8.4.
これは、RFC 3320-Section 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
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の左から始まり、それを横切って続けることができます（必要に応じて、指定されたアルゴリズムに従ってそれに戻ります）。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:
opcodeがbyte_copy_leftの左から始まるbytesを読み取ったり書いたりした場合、次の順序でそれを行います。
+----------------------------------------+
| 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):
opcodeが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の右側に書き込むことは、バイトのコピールールを尊重するOPCODESにとって完全に有効な操作です。
+----------------------------------------+
| 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.
このドキュメントは、RFC 3320-Section 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.
RFC 3320-Section 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-section 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の内容が、状態作成命令の発生と作成される状態との間に変化する場合、保存されているバイトは作成時にバッファーにあるバイトであることに注意してください（すなわち、メッセージが解凍されている場合、認証）。
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-Section 8.4では、バイトのコピールールに従う指示のリストでは言及されていませんが、RFC 3320-Section 9.3.5での説明は、これらのルールが従うべきであると述べています。CRCチェックを実行するデータを読み取ると、RFC 3320-Section 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-section 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.
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を持つまったく同じ状態を作成する状態の一部を作成する場合、実際のコピーが1つのコピーがあるはずです（SigComp [1]で提案された状態管理モデル[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.
同じ状態が異なる優先順位を持つコンパートメント内に作成されている場合、その1つのコピーは新しい優先事項で保存する必要があり、SMSに対して1回だけカウントする必要があります。つまり、国家の創造は、新しい状態を作成するのではなく、優先事項を更新します。
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]で文書化されている共有モードの次の例を考慮することで示すことができます[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 [DECOMP CPT] [COMP 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
SM1がすでに削除されているため、Aでの減圧障害
Example 2:
例2：
Endpoint A Endpoint B [decomp cpt] [comp cpt]
エンドポイントAエンドポイント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
SM1がすでに削除されているため、Aでの減圧障害
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.
分解器コンパートメントに作成された最小優先度状態の1つ以上があると、対応するコンプレッサーは、その（減圧装置）コンパートメントにどの状態が存在するかを確信できません。状態が1つしかない場合、そのようなあいまいさは存在しません。
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).
問題は、最小優先度状態を作成するための異なるルールの結果です。特に、コンプレッサーの知識のない2番目の状態の作成は、コンプレッサーが予想するよりも早く最初のピースが押し出されることを意味する可能性があります（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.
1つの観察結果は、州の広告を受け取った後、常に最小優先順位状態の一部を参照することが常に安全であることです。
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 Averseコンプレッサーの場合、推奨事項は、一度にコンパートメントに最小優先度状態の1つのみが存在することです。両方のエンドポイントが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-Section 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まで低くなる可能性があります。状態アクセス命令は、減圧障害を引き起こします。状態を参照するコンプレッサーは、衝突なしに国家の創造が成功したため、この障害モードを期待しません。数千または数百万の州がある可能性のあるサーバーエンドポイントで、これが実際にどのくらいの可能性があるのでしょうか？
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人しかいなければならないのは、2人が同じ誕生日（誕生日[8]）を持つ可能性が50％以上です）。
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) )
where LnFact (x) is the log of x!, which can be approximated by:
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%
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%
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]は、誤ったメッセージの可能性を1つだけ参照しています。ただし、「コンプレッサーは、リモートエンドポイントで利用可能なリソースを使用してメッセージを解凍できることを保証する必要がある」という声明は、コンプレッサーにONUSを使用して、誤った注文が発生する可能性を考慮しています。
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-Section 5は、要求されたフィードバックアイテムを複数回送信する必要はないと述べています。ただし、フィードバックを複数回送信することが有益である場合があります（たとえば、招待状のSIPメッセージに再送信された200 OK SIPメッセージ[9]は、元の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-section 9.4.9は、要求された場合、_feedback_locationがゼロに等しいと、フィードバック要求は行われないと述べています。ただし、これが既存のフィードバックデータが触れられないままになっていることを意味するのか、既存のフィードバックデータを「フィードバックデータなし」にして上書きすることを意味するのかを示すものはありません。Requested_feedback_locationがゼロに等しい場合、既存のフィードバックデータは、以前のように後続のメッセージで触れずに返される必要があります。
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-section 9.4.9は、requested_feedback_locationがゼロに等しくない場合に既存のフィードバックデータに何が起こるかについて発言しませんが、qフラグは要求された_feedback_itemの存在/不在がゼロであることを示します。この場合、既存のフィードバックデータを上書きして「フィードバックデータなし」にする必要があります。
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ビットを受信するエンドポイントは、ローカルで利用可能な状態アイテムを保存するために使用されるメモリを取り戻すことができます。ただし、これは、終了式または状態を作成する命令を使用して、送信者によって作成されたどの状態にも影響を与えません。
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-Section 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-Section 3.3.3は、ローカルで利用可能な状態アイテムを、エンドポイントが利用可能であるが、SigCompメッセージによってアップロードされていない状態の部分であると定義しています。与えられた例は、辞書とよく知られているバイトコードです。また、RFC 3320-Section 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]) are incomplete has caused some confusion. Therefore, this section clarifies the situation.
ただし、SigComp [1]は、地元で利用可能な状態アイテムの使用、特にそれらが利用可能になる時間の長さを完全に定義していません（これまで意図していませんでした）。地元で利用可能な状態アイテムの使用は、他のドキュメントに定義のために残されています。しかし、この事実は、Sigcompにはローカルで利用可能な状態アイテムの使用のためのフックが含まれているという事実と、そのような用途の定義のいくつか（Sigcomp拡張[2]）が不完全であるという事実と相まって、混乱を引き起こしました。したがって、このセクションでは状況を明確にします。
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-Section 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-section 6.2は、ローカルに利用可能な状態アイテムをコンパートメントにマッピングする可能性を可能にし、これが行われた場合、状態項目は、リモートの要求に応じて作成された状態を妨げないために状態保持優先度65535を持たなければならないと述べていますコンプレッサー。セクション5.3は、コンパートメントごとにそのような状態を1つだけ作成することを推奨していることに注意してください。
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（RFC 3320-Section 9.4.9を参照）のiビットにより、コンプレッサーは、以前に宣伝されていたローカルで利用可能な状態を参照しないことをリモートエンドポイントに示すことができます。リモートエンドポイントでの状態処理のための実装モデルに応じて、これにより、リモートエンドポイントがそのような状態項目で使用されているメモリを取り戻すことができます。
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 the 3GPP IMS specification [10]. Such a specification should also indicate whether or not advertisement of the state is needed.
ただし、特定の状態では、正確な寿命を定義する必要があります。たとえば、SIP [7]や3GPP IMS仕様[10]のSigcompなどの公開仕様で定義する必要があります。このような仕様は、州の広告が必要かどうかを示す必要があります。
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-Section 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のSIGCOMPで説明されているように[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に宣伝することがあります。（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.
decompressorにメッセージ全体を出力するように単純に指示するbytecodeを記述することができます（効果的に非圧縮されますが、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)
; 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)
at（128）：input-bytes（1、byte_copy_left、end）output（byte_copy_left、1）ジャンプ（開始）を開始
:end END-MESSAGE (0,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 Static Dictionary [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:
ただし、辞書にはいくつかの小さなバグがあります。多くの場所で、オフセットテーブルのエントリは、文字列のリストの対応する優先度セクションにないアドレスを指します。その結果、ByteCodeがオフセットテーブルを使用し、辞書の使用を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）0x064bの「SDP」は優先度2（優先4）ではありません。0x00F2の優先度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.
このドキュメントは、辞書自体の変更はバックワード互換ではなく、辞書の2つの異なるコピーを維持するためにすべての実装が必要になるため、辞書を修正しません。このようなコストは、回避するのが簡単で、圧縮比に無視できる影響を与えるバグにとっては非常に高すぎます。代わりに、実装者が結果として生じる問題を回避できるようにするために、欠陥が指摘されています。具体的には、リモートエンドポイントに送信されたバイトコードに、SIP/SDP辞書のサブパーティションのみをロードする命令が含まれている場合、そのbytecodeに提供された入力ストリームは、対応する文字列がオフセットテーブルのこれらの5つのオフセットのいずれかを参照できません。辞書の一部もロードされています。たとえば、bytecodeが辞書の最初の3つの優先順位のみ（文字列とオフセットテーブルの両方）のみをロードする場合、「send」（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拡張[2]、およびSigcomp Static Dictionary [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.
Sigcompの使用拒否（DOS）攻撃のツールとしての使用 - これは、SigCompが着信圧縮メッセージごとに1つの減圧メッセージのみを生成するという事実によって軽減されます。このアップデートでは変更されません。
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拡張[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
リチャード・プライス・ラジョス・ザックマーティム・フォースマン・トー・エリック・マレンヤン・クリストファーズソン・クワン・ミエン・チャン・ウィリアム・ケンベリー・ペッカ・ペシ
[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.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「Signaling Compression（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] Hannu、H.、Christoffersson、J.、Forsgren、S.、Leung、K.、Liu、Z.、およびR. Price、「Signaling Compression（Sigcomp） - 拡張操作」、RFC 3321、2003年1月。
[3] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression)", RFC 4077, October 2004.
[3] Roach、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] 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 2119、1997年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] Borman、C.、Liu、Z.、Price、R。、およびG. Camarillo、「Signing Compression（SIGCOMP）をセッション開始プロトコル（SIP）に適用する」、2006年11月、Work in Progress。
[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：SESSION INTIATION Protocol"、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:
正確なメッセージ形式は、後に拡張されたBackus-Naurフォーム（ABNF）[6]で与えられます。ここにいくつかのメモがあります：
Each line of message-header MUST be terminated with CRLF.
Message-Headerの各行は、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.
Message-Headerのすべての文字列は、ケース非感受性です。
For implementation according to this appendix, the DAP-version MUST be set to 1.
この付録に従って実装するには、DAP-versionを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メッセージ全体（Message-Header 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.
Endpoint-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を運ぶ場合があります。したがって、受信機はメッセージに掲載された（Endpoint-ID、コンパートメントID）ペアを使用して、そのメッセージのDecompressorコンパートメント識別子を決定する必要があります。派生コンパートメント識別子の正確な局所表現は、実装の選択肢です。
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）はピアコンパートメントです。つまり、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レシーバーは、Message-Header Line-5で伝えられた命令に従って、DAPメッセージを受け入れるか拒否します。注：メッセージが拒否された場合、Line-6およびLine-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メッセージヘッダーのLine-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.
Message-seqは、DAP送信者が送信する各メッセージを追跡するために使用できます。たとえば、損失の場合に。メッセージの損失は、パスまたは受信エンドポイント（つまり、減圧の故障による）で発生する可能性があります。メッセージセックの割り当ては送信者次第です。たとえば、コンパートメントごとまたはエンドポイントごとに割り当てることができます。これは受信側に影響を与えません。
(Note: see (ABNF) [6] for basic rules.)
（注：基本ルールについては（ABNF）[6]を参照してください。）
DAP-message = message-header CRLF [ message-body ]
dap-message = message-header crlf [message-body]
message-body = *OCTET
message-header = line-1 line-2 line-3 line-4 line-5 line-6 line-7 line-8
Message-header = line-1 line-2 line-3 line-4 line-5 line-6 line-7 line-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
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-version：1 Endpoint-ID：123.45.67.89コンパートメントID：2メッセージセック：0メッセージ-Auth：コンパートメントを受け入れる：必要性応答を作成：真のボディレング：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 Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey、Hants So51 0Zn 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 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
Adam Roach Estacado Systems 17210 Campbell Rd。スイート250ダラス、テキサス州75252 US
Phone: sip:adam@estacado.net
EMail: adam@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。