RFC4896 日本語訳
4896 Signaling Compression (SigComp) Corrections and Clarifications.A. Surtees, M. West, A.B. Roach. June 2007. (Format: TXT=58435 bytes) (Updates RFC3320, RFC3321, RFC3485) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループA.サーティーズの要求をネットワークでつないでください: 4896のM.の西アップデート: 3320、3321、3485シーメンス/Roke荘園研究カテゴリ: 標準化過程A.B.ローチエスタカードシステム2007年6月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントは、Signaling Compressionプロトコル(SigComp)で一般的な誤解といくつかのあいまいさについて説明して、どんな結果の問題も解決するために指導を開発者に提供します。SigCompはSession Initiationプロトコル(SIP)などのアプリケーション・プロトコルで発生するメッセージを圧縮することの計画を定義します。 このドキュメントは以下のRFCsをアップデートします: RFC3320、RFC3321、およびRFC3485。
Surtees, et al. Standards Track [Page 1] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[1ページ]RFC4896SigComp修正と明確化2007年6月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Decompression Memory Size . . . . . . . . . . . . . . . . . . 3
2.1. Bytecode within Decompression Memory Size . . . . . . . . 3
2.2. Default Decompression Memory Size . . . . . . . . . . . . 4
3. UDVM Instructions . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Data Input Instructions . . . . . . . . . . . . . . . . . 5
3.2. MULTILOAD . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Using the Stack . . . . . . . . . . . . . . . . . . . . . 6
4. Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Instructions That Use Byte Copying Rules . . . . . . . . . 9
5. State Retention Priority . . . . . . . . . . . . . . . . . . . 9
5.1. Priority Values . . . . . . . . . . . . . . . . . . . . . 9
5.2. Multiple State Retention Priorities . . . . . . . . . . . 10
5.3. Retention Priority 65535 (or -1) . . . . . . . . . . . . . 10
6. Duplicate State . . . . . . . . . . . . . . . . . . . . . . . 14
7. State Identifier Clashes . . . . . . . . . . . . . . . . . . . 14
8. Message Misordering . . . . . . . . . . . . . . . . . . . . . 15
9. Requested Feedback . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Feedback When SMS Is Zero . . . . . . . . . . . . . . . . 15
9.2. Updating Feedback Requests . . . . . . . . . . . . . . . . 16
10. Advertising Resources . . . . . . . . . . . . . . . . . . . . 16
10.1. The I-bit and Local State Items . . . . . . . . . . . . . 16
10.2. Dynamic Update of Resources . . . . . . . . . . . . . . . 17
10.3. Advertisement of Locally Available State Items . . . . . . 17
10.3.1. Basic SigComp . . . . . . . . . . . . . . . . . . . . 18
10.3.2. Dictionaries . . . . . . . . . . . . . . . . . . . . 18
10.3.3. SigComp Extended Mechanisms . . . . . . . . . . . . . 19
11. Uncompressed Bytecode . . . . . . . . . . . . . . . . . . . . 19
12. RFC 3485 SIP/SDP Static Dictionary . . . . . . . . . . . . . . 20
13. Security Considerations . . . . . . . . . . . . . . . . . . . 21
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
16.1. Normative References . . . . . . . . . . . . . . . . . . . 23
16.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Dummy Application Protocol (DAP) . . . . . . . . . . 24
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 24
A.2. Processing a DAP Message . . . . . . . . . . . . . . . . . 24
A.3. DAP Message Format in ABNF . . . . . . . . . . . . . . . . 26
A.4. An Example of a DAP Message . . . . . . . . . . . . . . . 26
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 2。 減圧記憶容量. . . . . . . . . . . . . . . . . . 3 2.1。 減圧記憶容量. . . . . . . . 3 2.2の中のバイトコード。 デフォルト減圧記憶容量. . . . . . . . . . . . 4 3。 UDVM指示. . . . . . . . . . . . . . . . . . . . . . 5 3.1。 データは指示. . . . . . . . . . . . . . . . . 5 3.2を入力しました。 MULTILOAD. . . . . . . . . . . . . . . . . . . . . . . . 5 3.3。 無州の.63.4。 スタック. . . . . . . . . . . . . . . . . . . . . 6 4を使用します。 規則. . . . . . . . . . . . . . . . . . . . . . 7 4.1をコピーするバイト。 バイト転写規則. . . . . . . . . 9 5を使用する指示。 保有優先権. . . . . . . . . . . . . . . . . . . 9 5.1を述べてください。 優先順位の値. . . . . . . . . . . . . . . . . . . . . 9 5.2。 倍数は保有プライオリティ. . . . . . . . . . . 10 5.3を述べます。 保有優先権65535(または、-1).106。 状態. . . . . . . . . . . . . . . . . . . . . . . 14 7をコピーしてください。 識別子衝突. . . . . . . . . . . . . . . . . . . 14 8を述べてください。 メッセージMisordering. . . . . . . . . . . . . . . . . . . . . 15 9。 フィードバック. . . . . . . . . . . . . . . . . . . . . . 15 9.1を要求しました。 SMSであるときに、フィードバックはゼロ. . . . . . . . . . . . . . . . 15 9.2です。 フィードバック要求. . . . . . . . . . . . . . . . 16 10をアップデートします。 リソース. . . . . . . . . . . . . . . . . . . . 16 10.1の広告を出します。 I-ビットとローカルは項目. . . . . . . . . . . . . 16 10.2を述べます。 ダイナミックなリソース更新. . . . . . . . . . . . . . . 17 10.3。 局所的に利用可能な州の項目. . . . . . 17 10.3.1の広告。 基本的なSigComp. . . . . . . . . . . . . . . . . . . . 18 10.3.2。 辞書. . . . . . . . . . . . . . . . . . . . 18 10.3.3。 SigCompはメカニズム. . . . . . . . . . . . . 19 11を広げました。 バイトコード. . . . . . . . . . . . . . . . . . . . 19 12を解凍しました。 RFC3485の一口/SDPの静的な辞書. . . . . . . . . . . . . . 20 13。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 21 14。 IANA問題. . . . . . . . . . . . . . . . . . . . . 22 15。 承認. . . . . . . . . . . . . . . . . . . . . . . 22 16。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 16.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 16.2。 有益な参照. . . . . . . . . . . . . . . . . . 23の付録のA.のダミーのアプリケーション・プロトコル(ちょと浸す).24A.1。 序論. . . . . . . . . . . . . . . . . . . . . . . 24A.2。 aを処理して、メッセージ. . . . . . . . . . . . . . . . . 24A.3をちょと浸してください。 ABNF. . . . . . . . . . . . . . . . 26A.4にメッセージ・フォーマットをちょと浸してください。 aに関する例はメッセージ. . . . . . . . . . . . . . . 26をちょと浸します。
Surtees, et al. Standards Track [Page 2] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[2ページ]RFC4896SigComp修正と明確化2007年6月
1. Introduction
1. 序論
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]は、言いなりになっているコンプレッサーによって送られたメッセージを減圧するために、Universal Decompressor Virtual Machine(UDVM)を定義します。 SigCompは、州の取り扱い、メッセージ構造、および他の詳細に対処するためにさらにメカニズムについて説明します。 減圧装置の振舞いは丹念に指定されますが、コンプレッサーの働きはimplementerのための選択として残されます。 実現と相互運用性テストの間、明確化を必要とする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インチでは、「RFC3320のRFC3.4インチが言及する3320セクション部3.4」というこのドキュメントのセクション3.4について言及します。[1]
1.1. Terminology
1.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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか?
2. Decompression Memory Size
2. 減圧記憶容量
2.1. Bytecode within Decompression Memory Size
2.1. 減圧記憶容量の中のバイトコード
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]は、デフォルトDecompression Memory Size(DMS)が2Kであると述べます。 UDVM記憶容量はRFC3320セクションの7で定義されます。nがTCPの上で輸送されたもののためにUDPと(DMS / 2)の上で輸送されたメッセージへのSigCompメッセージのサイズであるところにある(DMS--n)ように。 これは、メッセージがそこにバイトコード(少なくとも最初のメッセージのためにそうするように)を含むとき、それが実際に減圧装置メモリの中のバイトコードのコピーにな2部る(図1を見てください)を意味します。 減圧装置メモリでの2番目のコピーのバイトコードの存在はこの場合正しいです。
Surtees, et al. Standards Track [Page 3] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[3ページ]RFC4896SigComp修正と明確化2007年6月
|<----------------------------DMS--------------------------------->|
|<-----SigComp message---->|<------------UDVM memory size--------->|
+-+----------+-------------+-----+----------+----------------------+
| | bytecode | comp msg | | bytecode | circular buffer |
+-+----------+-------------+-----+----------+----------------------+
^ ^
| |
SigComp header Low bytes of UDVM
| <。----------------------------DMS--------------------------------->| | <、-、-、-、--SigCompメッセージ---->| <、-、-、-、-、-、-、-、-、-、-、--UDVM記憶容量--------->| +-+----------+-------------+-----+----------+----------------------+ | | バイトコード| コンピュータmsg| | バイトコード| 円形のバッファ| +-+----------+-------------+-----+----------+----------------------+ ^ ^ | | SigCompヘッダーLowバイトのUDVM
Figure 1: Bytecode and UDVM memory size within DMS
図1: バイトコードとDMSの中のUDVM記憶容量
2.2. Default Decompression Memory Size
2.2. デフォルト減圧記憶容量
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が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記憶容量は400+2432 = 2832です。 TCPベースのプロトコルのために、これは、DMSが少なくとも5664(2832*2)バイトでなければならないことを意味します。(バイトは8kまで一周します)。 UDPベースのプロトコルのために、SigCompメッセージ自体のサイズを考慮に入れなければなりません。 ただ一つのメッセージを50%(少しも前のメッセージ歴史のない)圧縮できるくらいの平均したエントロピー、およびサイズにおける8192バイトを超えていないと予想されるメッセージがあるテキストベースのプロトコルを仮定すると、プロトコルメッセージ自体はSigCompメッセージサイズ(400バイトのバイトコードと3バイトのヘッダーの上の)、または4096+400+3 = 4499に4096バイトを加えるでしょう。 DMS、1について計算するのは必要なUDVM記憶容量にこれを加えなければなりません: 2832+4499 = 6531 再びDMSの8kまで一周する。
Surtees, et al. Standards Track [Page 4] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[4ページ]RFC4896SigComp修正と明確化2007年6月
3. UDVM Instructions
3. UDVM指示
3.1. Data Input Instructions
3.1. データの入力指示
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:
圧縮されたメッセージからデータを入力するとき、INPUT-BYTES(RFC3320セクションの9.4.2)とINPUT-BITS(RFC3320セクションの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はINPUT-BYTES(6、a、b)指示に遭遇します。 そして、減圧装置発送者はバイトとジャンプを全くbによって指定された指示に返しません。 これがINPUT-BYTES(2、c、d)指示を含んでいるので、減圧装置発送者は首尾よくバイト0x01と0×02を返します。
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-BYTES(0、a、b)を使用できます。
3.2. MULTILOAD
3.2. MULTILOAD
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 opcodeで占領したどんなメモリかパラメタのいずれにも書くことができません。 さらに、何かパラメタの間接指定があれば、実行時間に間接指定しなければなりません。
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.
段階的な実現が結果になっても、段階的な実現(例えば、次にオペランドが実行するすべてを解読してください、他のすべての指示のモデルであるもの)以外のどんな実現のテクニックも同じようにもたらされなければなりません。
Surtees, et al. Standards Track [Page 5] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[5ページ]RFC4896SigComp修正と明確化2007年6月
For example:
例えば:
at (64)
at(64)
:location_a pad (2) :location_b pad (2) :location_c pad (2) pad (30) :udvm_memory_size pad (2) :circular_buffer pad (2)
:位置のパッド(2): 位置_bパッド(2): 位置_cパッド(2)パッド(30): udvm_メモリ_サイズパッド(2): 回覧_バッファパッド(2)
align (64)
並んでください。(64)
MULTILOAD (location_a, 3, circular_buffer,
udvm_memory_size, $location_a)
MULTILOAD(位置、3、円形の_バッファ、udvm_メモリ_サイズ、$位置)
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.
段階的な実現はそうするでしょう: 位置(メモリアドレス64)に回覧_バッファのアドレスを書いてください。 位置+2(メモリアドレス66)にudvm_メモリ_サイズのアドレスを書いてください。 位置(間接指定(現在、回覧_バッファのアドレスである)を使用することで、アクセスされる)に位置+4(メモリアドレス68)に格納された値を書いてください。 したがって、正しい実現による実行の終わりに、位置_cは回覧_バッファのアドレスを含むでしょう。
3.3. STATE-FREE
3.3. 州なしです。
The STATE-FREE instruction does not check the minimum_access_length. This is correct because the state cannot be freed until the application has authenticated the message. The lack of checking does not pose a security risk because if the sender has enough information to create authenticated messages, then sending messages that save state can push previous state out of storage anyway.
無州の指示は最小の_のアクセス_長さをチェックしません。 これは、アプリケーションがメッセージを認証するまで状態を解放できないので、正しいです。 送付者が堪能するなら作成する情報がメッセージを認証したので、照合の不足は危険人物を引き起こさないで、次に、状態を節約する送付メッセージは格納から先にをとにかく押すことができます。
The STATE-FREE instruction can only free state in the compartment that corresponds to the message being decompressed. Attempting to free state that is either from another compartment, or that is not associated with any compartment, has no effect.
無州の指示は減圧されるメッセージに対応するコンパートメントの状態を解放できるだけです。 どちらか別のコンパートメントからあるか、またはどんなコンパートメントにも関連づけられない状態を解放するのを試みるのを効き目がありません。
3.4. Using the Stack
3.4. スタックを使用します。
The instructions PUSH, POP, CALL, and RETURN make use of a stack that is set up using the well-known memory address stack_location to define where in memory the stack is located. Use of the stack is defined in RFC 3320-Section 8.3, which states: '"Pushing" a value on the stack is an abbreviation for copying the value to
指示のPUSH、POP、CALL、およびRETURNは、メモリでは、スタックがどこに位置しているかを定義するのに周知のメモリアドレススタック_位置を使用することでセットアップされるスタックを利用します。 スタックの使用はRFC3320セクションの8.3で定義されます。(RFCは以下を述べます)。 'スタックの値が「押す」であることが、値をコピーするための略語である、'
Surtees, et al. Standards Track [Page 6] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[6ページ]RFC4896SigComp修正と明確化2007年6月
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'.
+ 'スタック[スタック_中詰め]と次に増加するスタック_は1つ'いっぱいにし'スタック_中詰めがスタック_位置の2バイトの単語のための略語であり、スタック_位置は1です'。
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).
値がスタックに押されるとき非常にまれな場合では、スタック_の値がいっぱいになるのが、0xFFFFである、そして、元のスタック_中詰め値は1〜0×0000と書かれた後部によって増加させられて、_位置とスタック_位置+1(スタックに押された値を上書きする)を積み重ねなければなりません。
The new value pushed onto the stack has, in theory, been written
to stack [0xFFFF] = stack_location. Stack_fill would then be
increased by 1; however, the value at stack_location and
stack_location + 1 has just been updated. To maintain the
integrity of the stack with regard to over and underflow,
stack_fill cannot be re-read at this point, and the pushed value
is overwritten.
スタックに押された新しい値は、[0xFFFF]=スタック_位置を積み重ねるために理論上書かれています。 次に、スタック_中詰めは1つ増加するでしょう。 しかしながら、ちょうどスタック_位置とスタック_位置+1における値をアップデートしたところです。 アンダーフロー、_がいっぱいにするスタックは上書きできません。そして、保全する、積み重ねる、終わっている、ここに再読されて、上書きされます押すのが、評価する。
4. Byte Copying Rules
4. 規則をコピーするバイト
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:
「あとバイト_コピー_とバイト_コピー_で領域セットをまさしく尊敬して、バイトのストリングはメモリアドレスの昇順でコピーされます。」と、RFC3320セクションの8.4は述べます。 領域セットの外にあとバイト_コピー_とバイト_コピー_でバイトをまさしくコピーするのが完全に正統であるので、これは紛らわしいです。 あとバイト_コピー_とバイト_コピー_右は円形のバッファを以下の通りに維持する能力を提供します:
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
現在の_バイト=である((バイト_コピー_権利--1)モッズ2^16)なら: バイト_コピー次の_バイト=_はほかにいなくなりました: 次の_バイト=(現在の_バイト+1)のモッズ風の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
現在の_バイト=バイト_コピー_がいなくなったなら: 前の_バイトはほかにモッズ2^16と等しいです(バイト_コピー_権利--1): 前の_バイト=(現在の_バイト--1)のモッズ風の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
その結果、コピーがあとバイト_コピー_の左に始まって、それの向こう側に続くことができた、(付与に従って、急いで戻ってください。
Surtees, et al. Standards Track [Page 7] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[7ページ]RFC4896SigComp修正と明確化2007年6月
algorithm if necessary) and could begin at or to the right of byte_copy_right (though care must be taken to prevent decompression failure due to writing to / reading from beyond the UDVM memory).
アルゴリズム、必要なら)、右において、または、バイト_コピーの右に_まさしく始まることができました(UDVMメモリを超えて/読書に書くため減圧失敗を防ぐために注意しなければなりませんが)。
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"によって示された位置のあとバイト_コピー_とバイト_コピー_でそれぞれ広げたUDVMを考えてください:
+----------------------------------------+
| |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+ | | +----------^------------^----------------+ BCL BCR
If an opcode read or wrote bytes starting to the left of byte_copy_left, it would do so in the following order:
バイト_コピーの左にあと_を始動して、opcodeがバイトを読むか、または書くなら、以下のオーダーでそうするでしょうに:
+----------------------------------------+
| abcdefghijkl |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+ | abcdefghijkl| +----------^------------^----------------+ BCL BCR
If the opcode continues to read or write until it reaches byte_copy_right, it would then wrap around to byte_copy_left and continue (letters after the wrap are capitalized for clarity):
opcodeが、バイト_コピーに_右に達するまで、読むか、または書き続けているなら、次に、あとバイト_コピー_に巻きつけて、続くでしょう(包装の後の手紙は明快ために大文字で書かれます):
+----------------------------------------+
| abcQRSTUVjklmnop |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+ | abcQRSTUVjklmnop| +----------^------------^----------------+ BCL BCR
Similarly, writing to the right of byte_copy_right is a perfectly valid operation for opcodes that honor byte copying rules:
同様に、バイト_コピーの右に_右に書くのは、名誉のバイトがコピーされて、以下を統治するopcodesに、完全に有効な操作です。
+----------------------------------------+
| abcdefg |
+----------^------------^----------------+
BCL BCR
+----------------------------------------+ | abcdefg| +----------^------------^----------------+ BCL BCR
A final, somewhat odd relic of the foregoing rules occurs when byte_copy_right is actually less than byte_copy_left. In this case, reads and writes will skip the memory between the pointers:
バイト_コピー_権利が実際にあとバイト_コピー_より少ないときに、以上の規則の最終的で、いくらか変な遺物は起こります。 この場合、ポインタの間のメモリを意志のスキップに読み込んで、書きます:
+----------------------------------------+
| abcde fghijkl |
+----------^------------^----------------+
BCR BCL
+----------------------------------------+ | abcde fghijkl| +----------^------------^----------------+ BCR BCL
Surtees, et al. Standards Track [Page 8] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[8ページ]RFC4896SigComp修正と明確化2007年6月
4.1. Instructions That Use Byte Copying Rules
4.1. バイト転写規則を使用する指示
This document amends the list of instructions that obey byte copying rules in RFC 3320-Section 8.4 to include STATE-CREATE and CRC.
このドキュメントは州-CREATEとCRCを含むようにRFCの3320セクションの8.4における規則をコピーするバイトに従う指示のリストを修正します。
RFC 3320-Section 8.4 specifies the byte copying rules and includes a list of the instructions that obey them. STATE-CREATE is not in this list but END-MESSAGE is. This caused confusion due to the fact that neither instruction actually does any byte copying; rather, both instructions give information to the state-handler to create state. Logically, both instructions should have the same information about byte copying.
RFC3320セクションの8.4は規則をコピーするバイトを指定して、それらに従う指示のリストを含んでいます。 州-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か州-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).
UDVMのコンテンツが州-CREATE指示の発生と創設される状態の間で変化するなら格納されるバイトが創造時点のバッファのそれらであることに注意してください(すなわち、メッセージは、いつ減圧されて、認証されましたか)。
CRC is not mentioned in RFC 3320-Section 8.4 in the list of instructions that obey byte copying rules, but its description in RFC 3320-Section 9.3.5 states that these rules are to be obeyed. When reading data over which to perform the CRC check, byte copying rules apply as specified in RFC 3320-Section 8.4.
規則をコピーするバイトに従う指示のリストのRFCの3320セクションの8.4ではCRCについて言及しませんが、RFC3320セクションの9.3.5における記述は、これらの規則が従われることであると述べます。 CRCチェックを実行するデータを読むとき、バイト転写規則はRFCの3320セクションの8.4で指定されるように適用されます。
When the partial identifier for a STATE-FREE instruction is read, (during the execution of END-MESSAGE) byte copying rules as per RFC 3320-Section 8.4 apply.
無州の指示のための部分的な識別子が読まれるとき、RFCの3320セクションの8.4に従って(END-MESSAGEの実行の間の)バイト転写規則は適用されます。
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指示の中で状態を創設して、解放するためのバッファを読むと規則をコピーするバイトが従われるなら、また、読書フィードバック項目が規則をコピーするバイトに従うはずであるかどうかに関して何らかの混乱があるかもしれません。 バイト転写規則は読書フィードバック項目に申し込みません。
5. State Retention Priority
5. 州の保有優先権
5.1. Priority Values
5.1. 優先順位の値
For state_retention_priority, 65535 < 0 < 1 < ... < 65534. This is slightly counter intuitive, but is correct.
状態_保有_優先権、65535<0<1<のために… <65534。 これは、カウンタわずかに直感的ですが、正しいです。
Surtees, et al. Standards Track [Page 9] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[9ページ]RFC4896SigComp修正と明確化2007年6月
5.2. Multiple State Retention Priorities
5.2. 複数の州の保有プライオリティ
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で1つの状態を創設して、終点Bが保有優先権2でまさに同じ状態を創設するなら、コピー1部があるはずです。(国家管理のモデルに就くのは実際の状態のSigComp[1])に示されましたが、各コンパートメントはそれ自身の優先権でこの状態を記録にとどめるべきです。 (これが起こらないなら、状態は予期されたAかどの優先権によって、予期されたBより少ない時間が使用されているより長い間、維持されるかもしれません。 これで、Decompression Failureは起こることができました。)
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に不利とならなければなりません。すなわち、州の創造は新しい状態を創設するよりむしろ優先権をアップデートします。
5.3. Retention Priority 65535 (or -1)
5.3. 保有優先権65535(または、-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).
潜在的に、最低保有額優先権で複数の状態を格納することに関する問題が(65535) SigComp[1]で定義されるようにあります。 SigComp Extended[2]に記録される共有されたモードのものである以下の例を考えることによって、これを示すことができます。 保有優先権65535がある状態の周りの主要なものは減圧装置コンパートメントの終点でリモートコンプレッサー(減圧装置コンパートメントで州の創造を制御する)に関する知識なしでそれを作成できるということです。
Surtees, et al. Standards Track [Page 10] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[10ページ]RFC4896SigComp修正と明確化2007年6月
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)である、紀元前がバイトコード状態(優先権1)である、BFnは緩衝国(優先権0)です]
Endpoint A Endpoint B
[decomp cpt] [comp cpt]
終点A Endpoint B[decomp cpt][コンピュータcpt]
[SM1]
------------------------------->
[SM1]
[SM1]------------------------------->。[SM1]
[SM1, SM2]
--------------------X (message lost)
[SM1、SM2]--------------------X(失われたメッセージ)
[SM1, BC, BF1]
<------------ref SM1------------
[SM2, BC, BF1]
endpoint B still believes SM1
is at endpoint A
[SM1、紀元前、BF1] <。------------審判SM1------------ [SM2、紀元前、BF1] 終点Bは、SM1が終点Aにあるとまだ信じています。
[BC, BF1, BF2]
<------------ref SM1------------
[紀元前、BF1、BF2] <。------------審判SM1------------
decompression failure at A
because SM1 has already been deleted
Aでの減圧失敗、SM1は既に削除されました。
Surtees, et al. Standards Track [Page 11] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[11ページ]RFC4896SigComp修正と明確化2007年6月
Example 2:
例2:
Endpoint A Endpoint B
[decomp cpt] [comp cpt]
終点A Endpoint B[decomp cpt][コンピュータcpt]
[SM1]
------------------------------->
[SM1]
[SM1]------------------------------->。[SM1]
[SM1, BC, BF1]
(message lost)X------ref SM1-----
[SM1、紀元前、BF1] (メッセージは失われました)X------審判SM1-----
[SM1, SM2]
------------------------------->
endpoint B does not create SM2
because there is no space
[SM1, BC, BF1]
[SM1、SM2]-------------------------------スペースが全くないので、>終点BはSM2を作成しません。[SM1、紀元前、BF1]
[SM1, BC, BF1, BF2]
<------------ref SM1------------
[SM2, BC, BF2]
endpoint B still believes SM1
is at endpoint A
[SM1、紀元前、BF1、BF2] <。------------審判SM1------------ [SM2、紀元前、BF2] 終点Bは、SM1が終点Aにあるとまだ信じています。
[BC, BF1, BF2, BF3]
<------------ref SM1------------
[紀元前、BF1、BF2、BF3] <。------------審判SM1------------
decompression failure at A
because SM1 has already been deleted
Aでの減圧失敗、SM1は既に削除されました。
Figure 2: Retention priority 65535 examples
図2: 保有優先権65535の例
Surtees, et al. Standards Track [Page 12] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[12ページ]RFC4896SigComp修正と明確化2007年6月
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メッセージを減圧するのに必要であるデータのすべてが利用可能であることを確信しているに違いないと述べます。 その結果、それ、状態が存在するのが、確かであるはずがないならいずれも述べるSHOULD NOT参照。 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つの観測は状態の広告の領収書に従って、それがいつも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.
ナック[3]で定義されるように両方の終点がSigCompバージョン2を走らせているのが知られているなら、終点は、同期の損失の見込みが非常に小さいと仮定して、回復のためにナックメカニズムを当てにするかもしれません。
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.
しかしながら、コンプレッサーが、NACKsの世代を引き起こすのを避けてみるように、それは同輩コンプレッサーの働きに関するいくつかの仮定をすることができなければなりません。 また、終点のひとりがナックを支持しないなら、ある他の解決策が必要です。
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.
その結果、どこナックは、支持されていないか、またはナックにとって、大嫌いであるか。コンプレッサー、推薦は1片の最小の優先権州のSHOULDだけがいかなる時もコンパートメントに存在しているということです。 両方の終点がナック[3]を支持するなら、この推薦はリラックスするかもしれませんが、implementersは、慎重に複数の最小の優先権状態を創設する結果について考える必要があります。 どちらの場合ではも、アプリケーションの働きがメッセージ流動を制限するなら、この事実は複数の最小の優先権州の安全な創設を許すのに利用されるかもしれません。 しかしながら、まだ注意しなければなりません。
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.
コンプレッサーが、遠く離れた終点が最小の新しい優先権状態を創設できる必要があるなら、既存の状態を取り除くのに州の無料指示を使用できることに注意してください。
Surtees, et al. Standards Track [Page 13] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[13ページ]RFC4896SigComp修正と明確化2007年6月
6. Duplicate State
6. 状態をコピーしてください。
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.
1つの状態を創設するなら、まるでそれがちょうど作成されたかのようにそれが創造SHOULDの時に既に存在するコンパートメントでは、アップデートしてください、新しい州の保有優先があるかどうかの如何にかかわらず。
7. State Identifier Clashes
7. 州の識別子衝突
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).
RFC3320セクションの6.2は、1つの状態を創設するとき、完全な20バイトの細切れ肉料理がこの識別子があるもう1片の状態が存在するかどうか確認するためにチェックされるべきであると述べます。 そうして、州の項目が同じでないなら、新しい創造は失敗しなければなりません。 この発生の確率が消え失せてわずかであると(したがって、それはあって、以下を見てください)述べられています。
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と同じくらい低いかもしれないところで。 ここに、状態の2つの断片が同じ最初のnバイトの州の識別子と共にあると、州-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:
factorialsを使用するナイーブな計算は以下を与えます。
N!
Pd(N,s) = 1 - -------------
(N - s)! N^s
N! Pd(N、s)=1、-------------- (N--s!) N^s
where N is the number of possible values and s is the sample size.
Nがどこの可能な値とsの数であるかはサンプルサイズです。
However, due to dealing with large numbers, an approximation is needed:
しかしながら、大きい数に対処するため、近似が必要です:
Pd(N,s) = 1 - e^( LnFact(N) - LnFact(N-s) - s Ln(N) )
Pd(N、s)=1--e^(LnFact(N)--LnFact(N-s)--s Ln(N) )
where LnFact (x) is the log of x!, which can be approximated by:
LnFact(x)がxに関するログであるところ!、以下はどれに近似できるか。
Surtees, et al. Standards Track [Page 14] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[14ページ]RFC4896SigComp修正と明確化2007年6月
LnFact(x) ~ (x + 1/2) Ln(x) - x + Ln(2*Pi)/2 +
LnFact(x)~(x+1/2)Ln(x)--x+Ln(2*パイ)/2+
1 1 1 1
--- - ------- + -------- - --------
12x 360 x^3 1260 x^5 1680 x^7
1 1 1 1 --- - ------- + -------- - -------- 12x360x^3 1260x^5 1680x^7
which using N = 2^48 [6 octet partial state identifier] gives:
どの使用N=2^48[6の八重奏の部分的な州の識別子]が以下を与えますか?
s = 1 000 000: Pd (N,s) = 0.018% s = 10 000 000: Pd (N,s) = 16.28% s = 100 000 000: Pd (N,s) = 100.00%
s=1 000 000: Pd(N、s)は0.018%s=10 000 000と等しいです: Pd(N、s)は16.28%s=100 000 000と等しいです: 100.00Pd(N、s)=%
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:
aの見込みは、州の識別子の完全な20の八重奏を使用するとき、衝突して、本当に、消え失せてわずかな確率を持っています: N=2^160[完全な20八重奏州の識別子]を使用すると、以下は与えられます。
s = 1 000 000: Pd (N,s) = 3.42E-35% s = 10 000 000: Pd (N,s) = 3.42E-33% s = 100 000 000: Pd (N,s) = 3.42E-31%
s=1 000 000: Pd(N、s)=3.42E-35%s=10 000 000: 3.42E-33Pd(N、s)=%sは100 000 000と等しいです: 3.42E-31Pd(N、s)=%
Consequently, care must be taken when deciding how many octets of state identifier to use to access state at the server.
サーバで状態にアクセスするのに州の識別子のいくつの八重奏を使用するかを決めるとき、その結果、注意しなければなりません。
8. Message Misordering
8. メッセージMisordering
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メッセージの可能性の1つの参照箇所だけをします。 しかしながら、'コンプレッサーは、遠く離れた終点で利用可能なリソースを使用することでメッセージを減圧できるのを確実にしなければならないこと'が取るために重荷をコンプレッサーに置くという声明が発生をmisorderingする可能性について説明されます。
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.
misorderingが起こることができて、それには影響力があるだろうかどうかがコンパートメント定義と輸送によるか否かに関係なく、使用中に議定書を作ってください。 したがって、これらの要素を考慮に入れるのは、コンプレッサーのimplementer次第です。
9. Requested Feedback
9. 要求されたフィードバック
9.1. Feedback When SMS Is Zero
9.1. SMSであるときに、フィードバックはゼロです。
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.
終点がaを受けるなら、フィードバック、その時、それを要求してください。SHOULDはSMSがゼロであってもフィードバックを返します。 要求されたフィードバックの格納オーバーヘッドはSMSの一部ではありません。
Surtees, et al. Standards Track [Page 15] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[15ページ]RFC4896SigComp修正と明確化2007年6月
9.2. Updating Feedback Requests
9.2. フィードバック要求をアップデートします。
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.
終点が有効なメッセージを受け取るとき、それはそのコンパートメントのための要求されたフィードバックデータをアップデートします。 RFC3320セクションの5は、どんな要求されたフィードバック項目ももう少し伝える必要は全く一度よりないと述べます。 しかしながら、ケースが一度以上をフィードバックに送るのが有益である(例えば、INVITE SIPメッセージへの再送された200OK SIPメッセージ[9]は、オリジナルの200OK、およびそれが運んだフィードバックが遠く離れた終点に達していないかもしれないのを含意します)ところにあります。 したがって、フィードバックをアップデートする別の有効なメッセージを受け取るまで、終点SHOULDは繰り返してフィードバックを伝えます。
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州、どんなフィードバックも、要求しない。 しかしながら、触れない状態で残されるか、またはこれが、既存のフィードバックデータSHOULDが'フィードバックデータがありません'になるように上書きされることを意味するなら、これが、既存のフィードバックデータがそうであることを意味するかどうかしるしが全くありません。 要求された_フィードバック_位置がゼロと等しいなら、既存のフィードバックデータ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'.
.9がまた要求された_のフィードバック_品目の存在/欠如を示す要求された_フィードバック_位置がゼロにもかかわらず、Q旗と等しくないと既存のフィードバックデータがどうなるかに関する声明を全くしないRFCの3320セクションの9.4はゼロです。 この場合既存のフィードバックデータSHOULD、'フィードバックデータがありません'になるように、上書きされてください。
10. Advertising Resources
10. 広告リソース
10.1. The I-bit and Local State Items
10.1. I-ビットとローカルの州の項目
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.)
遠く離れた終点SHOULDはまだ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
1のI-ビットを受ける終点は局所的に利用可能な州の項目を格納するのに使用されるメモリを取り戻すことができます。しかしながら、これには、影響力が全くありません。
Surtees, et al. Standards Track [Page 16] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[16ページ]RFC4896SigComp修正と明確化2007年6月
on any state that has been created by the sender using END-MESSAGE or STATE-CREATE instructions.
どんな状態でも、それは、END-MESSAGEか州-CREATE指示を使用することで送付者によって作成されました。
10.2. Dynamic Update of Resources
10.2. ダイナミックなリソース更新
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などの減圧装置リソースをアップデートできます(RFC3320セクションの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.
絶対に必要でない場合、リソースを減らすのはそのように、潜在的同期問題とSHOULD NOTをさせます。 これがそうであるなら、遠く離れた終点が広告と共に送られたメッセージを承認するまで、メモリを取り戻してはいけません。 状態がSMSに減少を収容するために削除されるつもりであるなら、州の保有優先権に応じて、両方の終点はそれを削除しなければなりません(RFC3320部6.2を見てください)。 そして、コンプレッサーはごく最近広告に掲載されたリソースの量以上を使用してはいけません。
10.3. Advertisement of Locally Available State Items
10.3. 局所的に利用可能な州の項目の広告
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.
RFC3320セクションの3.3.3は、SigCompメッセージによってアップロードされていない終点が利用可能にする状態の断片になるように局所的に利用可能な州の項目を定義します。 出された例は辞書とよく知られている片のバイトコードです。 そして、RFC3320セクションの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])を広げています。
Surtees, et al. Standards Track [Page 17] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[17ページ]RFC4896SigComp修正と明確化2007年6月
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.
局所的に利用可能な州の項目の用途のどんな定義もいかなる他の用途とも衝突してはいけないことに注意してください。
10.3.1. Basic SigComp
10.3.1. 基本的なSigComp
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は、局所的に利用可能な状態(RFC3320セクションの9.4.9)の広告を出すために終点へのメカニズムを提供します。 終点であるなら広告を受け取る場合、それは'認識され'て、したがって、状態の特性は知られません。例えば、その長さと生涯、コンプレッサーは状態にアクセスするかどうか非常に慎重に考える必要があります。 特にナック[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が局所的に利用可能な州の項目に関連して使用のための以下のフックを提供する、さらなる定義、局所的に利用可能な州のSHOULD NOT、使用されてください。
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.
RFC3320セクションの6.2は、リモートコンプレッサーの依頼で創設された状態を妨げないように局所的に利用可能な州の項目をコンパートメントに写像する可能性を考慮して、これが完了しているなら州の項目には州の保有優先権65535がなければならないと述べます。 また、セクション5.3が、そのような断片の州のSHOULDの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.
要求された_フィードバック_位置(RFC3320セクションの9.4.9を見る)のI-ビットで、コンプレッサーは、以前に広告を出した局所的に利用可能な状態のいずれにも参照をつけないのを遠く離れた終点に示すことができます。 遠く離れた終点の州の取り扱いのために実現モデルに頼っていて、これは、メモリを取り戻すためにそのような州の項目によって使用されることで遠く離れた終点を許容するかもしれません。
10.3.2. Dictionaries
10.3.2. 辞書
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 Static Dictionary[4])か1つのバイトコードで指定しました。 一般に、これらの州:
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の持続時間がコンパートメントSMSにどんな影響力も持っていないので終点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[7]のためのSigCompなどの公共の仕様に基づき定義される必要がある。
Surtees, et al. Standards Track [Page 18] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[18ページ]RFC4896SigComp修正と明確化2007年6月
the 3GPP IMS specification [10]. Such a specification should also indicate whether or not advertisement of the state is needed.
3GPP IMS仕様[10]。 また、そのような仕様は、状態の広告が必要であるかどうかを示すべきです。
10.3.3. SigComp Extended Mechanisms
10.3.3. 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セクションの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:
終点の開始している承認(RFC3321部5.1の.2)の定義は、定義が状態がコンパートメントの生涯維持されるのを示すのに使用されることで広告を排除しないのを確実にするために明確化を必要とします。(SIP[7])のためにSigCompで議論するように。 したがって、明確化は以下の通りです。
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.
Endpoint A要求がEndpoint Bに創造を述べるところにEndpoint Bは次に、作成された州の項目の細切れ肉料理のEndpoint A.に広告を出すかもしれません。Thisは、(i) 状態がコンパートメントの中に首尾よく創設されたのをEndpoint Aまで運びます。 そして、SigComp[1]の時代と保有優先権に従って、州が少なくとも状態の生涯に利用可能であるために望んでいる(ii)は州の削除規則を定義しました。 [1]に応じてそれがコンパートメントから削除された後に状態がEndpoint Bで利用可能であるなら、状態はもうコンパートメントのSMSに向かって重要ではありません。 そのような通常、定義された生涯利用可能な状態の保証が全くないので、終点SHOULDは、今回ナック[3]が手があいているのが知られているところの後に状態にアクセスするのを試みるだけです。
11. Uncompressed Bytecode
11. 解凍されたバイトコード
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を走らせないでバイトを認識して、出力できるように)、これは特に役に立ちます。 したがって、それはここに記録されます。
Surtees, et al. Standards Track [Page 19] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[19ページ]RFC4896SigComp修正と明確化2007年6月
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_メモリ_サイズパッド(2):サイクルに、1_あたりの_はパッド(2)に噛み付きました: sigcomp_バージョンパッド(2): 部分的な_状態_イド_長さのパッド(2): (64)に_長さのパッド(2):reservedパッド(2)を述べてください: バイト_コピー_はパッド(2): バイト_コピー_を右のパッド(2)に残しました: _ビット_オーダーパッド(2)を入力してください: _位置のパッドを積み重ねてください。(2)
; Simple loop ; Read a byte ; Output a byte ; Until there are no more bytes!
; 簡単な輪。 1バイトを読んでください。 1バイトを出力してください。 それ以上のバイトが全くないまで!
at (128) :start INPUT-BYTES (1, byte_copy_left, end) OUTPUT (byte_copy_left, 1) JUMP (start)
(128) :start INPUT-BYTES(1、あとバイト_コピー_は終わる)OUTPUT(あとバイト_コピー_、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、0×00、0xa1、0x1c、0×01、0×86、0×09、0×22、0×86、0×01、0×16、0xf9、0×23
12. RFC 3485 SIP/SDP Static Dictionary
12. RFC3485の一口/SDPの静的な辞書
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つの最優先するセクションに分割される、それら、使用(それがダウンロードされなければならない場合で特に役に立ちます)。 辞書の部分だけが使用されているなら、両方の部品(ストリングとオフセットテーブル)の該当箇所は使用されています。
Surtees, et al. Standards Track [Page 20] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[20ページ]RFC4896SigComp修正と明確化2007年6月
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)
0×0334における'アプリケーション'は0x064bの2(それは優先権4である)'sdp'がない優先権では、2(それは優先権4である)が0x089dで'送る'優先権が0x00f2の2(それは優先権4である)'電話'がない優先権には優先権3が優先権2(それは優先権3です)'recv'では0×0553に、ないということであるということではありません。(それは優先権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部を維持してください。 問題に取りかかるために些細であり、圧縮比にごくわずかな影響を持っているバグには、そのような費用ははるかに高過ぎます。 代わりに、欠点は、implementersがどんな結果の問題も避けるのを許容するために指摘されます。遠く離れた終点に送られたバイトコードがSIP/SDP辞書のサブ一部だけをロードする指示を含んでいるなら、明確に、そのバイトコードに提供された入力ストリームはまた、辞書の対応するストリング部分がロードされていない場合これらの5のいずれもオフセットテーブルで相殺する参照をそうすることができません。 例えば、バイトコードが辞書の最初の3つのプライオリティだけをロードするなら(両方が、テーブルを結んで、相殺します)、オフセットの「発信する」(0x089dの)の使用は有効でしょう。 しかしながら、オフセットの「電話」(0x00f2の)の使用はそうしないでしょう。
13. Security Considerations
13. セキュリティ問題
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 Extended[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ビットを使用することによって、緩和されます。 このアップデートは、最小限を減少させないで、ある状況で、より多くのビットの使用を推薦します。
Surtees, et al. Standards Track [Page 21] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[21ページ]RFC4896SigComp修正と明確化2007年6月
Faking state or making unauthorized changes - this is mitigated by
the fact that the application layer has to authorize state
manipulation. This update does not change that mechanism.
状態を見せかけるか、または未承認の変更を作ります--応用層が州の操作を認可しなければならないという事実によってこれは緩和されます。 このアップデートはそのメカニズムを変えません。
Use of SigComp as a tool in a Denial of Service (DoS) attack -
this is mitigated by the fact that SigComp only generates one
decompressed message per incoming compressed message. That is not
changed by this update.
サービス妨害(DoS)攻撃におけるツールとしてのSigCompの使用--SigCompが入って来る圧縮されたメッセージあたり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.
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サイクル」の上限によって緩和されます。
14. IANA Considerations
14. IANA問題
This document updates SigComp [1], but does not change the version. Consequently, the IANA considerations are the same as those for [1].
このドキュメントは、SigComp[1]をアップデートしますが、バージョンを変えません。 その結果、IANA問題は[1]のためのそれらと同じです。
This document updates SigComp Extended [2], but does not change the version. Consequently, the IANA considerations are the same as those for [2].
このドキュメントは、SigComp Extended[2]をアップデートしますが、バージョンを変えません。 その結果、IANA問題は[2]のためのそれらと同じです。
This document updates Static Dictionary [4], but does not change the version. Consequently, the IANA considerations are the same as those for [4].
このドキュメントは、Static Dictionary[4]をアップデートしますが、バージョンを変えません。 その結果、IANA問題は[4]のためのそれらと同じです。
15. Acknowledgements
15. 承認
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
リチャード価格Lajos ZaccomerティモForsman Tor-エリックMalenジャンChristoffersson Kwang物腰チェンウィリアムKemberyペッカPessi
Surtees, et al. Standards Track [Page 22] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[22ページ]RFC4896SigComp修正と明確化2007年6月
16. References
16. 参照
16.1. Normative References
16.1. 引用規格
[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)」、RFC3320(2003年1月)。
[2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K., Liu,
Z., and R. Price, "Signaling Compression (SigComp) - Extended
Operations", RFC 3321, January 2003.
[2] ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.、リュウ、Z.、およびR.は「圧縮(SigComp)--操作を広げると合図すること」でのRFC3321(2003年1月)に値を付けます。
[3] Roach, A., "A Negative Acknowledgement Mechanism for Signaling
Compression)", RFC 4077, October 2004.
[3] ローチ、A.、「シグナリング圧縮のための否定的承認メカニズム)」、RFC4077、10月2004日
[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.ローチ、「セッション開始プロトコル(一口)とセッション記述はシグナリング圧縮(SigComp)のために(SDP)静的な辞書について議定書の中で述べます」、RFC3485、2003年2月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[5] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
16.2. Informative References
16.2. 有益な参照
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications (ABNF)", RFC 2234, November 1997.
[6] クロッカーとD.とP.Overell、「構文仕様(ABNF)のための増大しているBNF」、RFC2234、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] 「セッション開始プロトコル(一口)に圧縮(SigComp)に合図しながら、適用し」て、ボーマン、C.、リュウ、Z.、価格、R.、およびG.キャマリロは進行中(2006年11月)で働いています。
[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/芸術/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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[10] "IP Multimedia Call Control Protocol based on Session
Initiation Protocol (SIP)", October 2006.
[10] 「Session Initiationプロトコル(SIP)に基づくIP Multimedia Call Controlプロトコル」、2006年10月。
Surtees, et al. Standards Track [Page 23] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[23ページ]RFC4896SigComp修正と明確化2007年6月
Appendix A. Dummy Application Protocol (DAP)
付録のA.のダミーのアプリケーション・プロトコル(ちょと浸します)
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線のメッセージヘッダー、人影のない線、およびOPTIONALメッセージボディーから成ります。 スタイルはSIPとHTTPのものに類似しています。
The exact message format is given later in augmented Backus-Naur Form (ABNF) [6]. Here are a few notes:
後で増大しているBN記法(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。 aを処理して、メッセージをちょと浸してください。
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.
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
Compartment IDは*発信*終点がこのメッセージを圧縮するのに使用した*コンプレッサー*コンパートメントに関する識別子です。 それは割り当てられます。
Surtees, et al. Standards Track [Page 24] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[24ページ]RFC4896SigComp修正と明確化2007年6月
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.
送付者でしたがって、ユニークなだけで送付終点あたり。 すなわち、異なった終点によって送られたDAPメッセージは同じコンパートメントIDを運ぶかもしれません。 したがって、受信機SHOULDはそのメッセージに減圧装置コンパートメント識別子を決定するメッセージで運ばれた(終点コンパートメント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つの終点の間の同輩コンパートメントはDAPで同じコンパートメントIDがあるそれらと定義されます。 そして、例えば、(終点A、1)、(終点B、1)は同輩コンパートメントです。 その手段、終点Aのコンパートメント1から終点Bに送られたDAPメッセージのためのSigCompフィードバックは終点Bのコンパートメント1から終点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受信機は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メッセージ線-ヘッダーが「本当に」運ぶと、受信機は送付者に応答メッセージを返送するでしょう。 これはSigCompフィードバックのテストを許します。 応答メッセージが上に、圧縮しなければならなくて、発信したと言及するので、遠く離れたコンプレッサーコンパートメントの同輩である地方のコンプレッサーコンパートメントです。 この規制以外の、応答メッセージはただ任意のメッセージヘッダーとメッセージ本体を運ぶことができる通常のDAPメッセージです。 例えば、また、応答の「必要性応答」分野をTRUEなどに設定できます。(TRUEは応答への応答の引き金となるでしょう)。 各終点がそれ自身のメッセージの「必要性応答」分野を管理するのでこれが死んでいる輪に通じないことに注意してください。 応答が望まれていない場合、DAP送付者SHOULD NOTの分別がある実現は盲目的にこの分野を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送付者は、それが例えば、損失の場合に送る各メッセージを追跡するのにメッセージ-seqを使用できます。 メッセージの損失は経路の上、または、受信終点(すなわち、減圧失敗による)で起こることができます。 メッセージ-seqの課題は送付者次第です。 例えば、それはコンパートメント単位で割り当てられるか、終点のどちらか単位であるかもしれません。 これで、受信への影響に全く面がありません。
Surtees, et al. Standards Track [Page 25] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[25ページ]RFC4896SigComp修正と明確化2007年6月
A.3. DAP Message Format in ABNF
A.3。 ABNFにメッセージ・フォーマットをちょと浸してください。
(Note: see (ABNF) [6] for basic rules.)
(注意: 基本的なルールに関して(ABNF)[6]を見てください。)
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が等しい、「バージョンをちょと浸す、」、」、:、」 「1*DIGIT CRLF線-2は「終点ID」と等しい」:、」 「IPv4address CRLF線-3は「コンパートメントID」と等しい」:、」 「1*DIGIT CRLF線-4は「メッセージ-seq」と等しい」:、」 「1*DIGIT CRLF線-5は「メッセージ-auth」と等しい」:、」 (「受け入れる」か、または「拒絶します」) 「CRLF線-6=「コンパートメントオプアート」」:、」 (「作成」/「閉鎖」/「なにも」) 「CRLF線-7は「必要性応答」と等しい」:、」 (「本当である」か「誤っている」)です。 「線-8は「ボディー長さ」と等しい」:、」 1*ケタCRLF
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
「IPv4addressは1*3DIGITと等しい」、」 「1*3DIGIT」、」 「1*3DIGIT」、」 1*3DIGIT
A.4. An Example of a DAP Message
A.4。 aに関する例はメッセージをちょと浸します。
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
バージョンをちょと浸します: 1終点ID: 123.45.67.89 コンパートメントID: 2メッセージ-seq: 0メッセージ-auth: ACCEPTコンパートメントオプアート: CREATE必要性応答: TRUEボディー長さ: 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.
これはSigComp終点からIPアドレス123.45.67.89で送られたDAPメッセージです。 これはコンパートメント2から送られた最初のメッセージです。 メッセージを受け入れてください、そして、関連コンパートメントを作成してください、そして、応答メッセージを返送してください。
Surtees, et al. Standards Track [Page 26] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[26ページ]RFC4896SigComp修正と明確化2007年6月
Authors' Addresses
作者のアドレス
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
アビゲールサーティーズシーメンス/Roke Manor Research Roke荘園研究株式会社ロムジー、Hants SO51 0ZNイギリス
Phone: +44 (0)1794 833131 EMail: abigail.surtees@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833131はメールされます: 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 Manor Research Roke荘園研究株式会社ロムジー、Hants SO51 0ZNイギリス
Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
以下に電話をしてください。 +44 (0) 1794 833311はメールされます: mark.a.west@roke.co.uk ユリ: http://www.roke.co.uk
Adam Roach Estacado Systems 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
アダムローチエスタカードSystems17210キャンベル通り Suite250テキサス75252ダラス(米国)
Phone: sip:adam@estacado.net EMail: adam@estacado.net
以下に電話をしてください。 一口: adam@estacado.net EMail: adam@estacado.net
Surtees, et al. Standards Track [Page 27] RFC 4896 SigComp Corrections and Clarifications June 2007
サーティーズ、他 標準化過程[27ページ]RFC4896SigComp修正と明確化2007年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Surtees, et al. Standards Track [Page 28]
サーティーズ、他 標準化過程[28ページ]
一覧
スポンサーリンク
