Network Working Group H. Hannu
Request for Comments: 3321 J. Christoffersson
Category: Informational Ericsson
S. Forsgren
K.-C. Leung
Texas Tech University
Z. Liu
Nokia
R. Price
Siemens/Roke Manor
January 2003
Signaling Compression (SigComp) - Extended Operations
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes how to implement certain mechanisms in Signaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per-message compression.
この文書では、有意に単純なメッセージごとの圧縮を使用する場合に比べ圧縮効率を向上させることができるシグナリング圧縮（SigCompの）、RFC 3320で特定のメカニズムを実装する方法について説明します。
SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC 3320.
SigCompのは減圧のためのユニバーサルデコンプレッサ仮想マシン（UDVM）を使用して、本書で説明されたメカニズムは、RFC 3320で定義されたUDVMインストラクションを使用して実装することが可能です。
Table of Contents
目次
1. Introduction..................................................2
2. Terminology...................................................3
3. Architectural View of Feedback................................4
4. State Reference Model.........................................5
5. Extended Mechanisms...........................................6
6. Implications on SigComp......................................13
7. Security Considerations......................................17
8. IANA Considerations..........................................17
9. Acknowledgements.............................................17
10. Intellectual Property Right Considerations...................17
11. References...................................................17
12. Authors' Addresses...........................................18
13. Full Copyright Statement.....................................19
This document describes how to implement mechanisms with [SIGCOMP] to significantly improve the compression efficiency compared to per-message compression.
この文書では、有意に、メッセージごとの圧縮に比べて圧縮効率を向上させる【のSigComp]とメカニズムを実装する方法について説明します。
One such mechanism is to use previously sent messages in the SigComp compression process, referred to as dynamic compression. In order to utilize information from previously sent messages, it is necessary for a compressor to gain knowledge about the reception of these messages. For a reliable transport, such as TCP, this is guaranteed. For an unreliable transport however, the SigComp protocol can be used to provide such a functionality itself. That functionality is described in this document and is referred to as explicit acknowledgement.
そのような機構は、SigCompの圧縮過程で以前に送信されたメッセージを使用することである、などの動的圧縮と呼びます。圧縮機は、これらのメッセージの受信に関する知識を獲得するための以前に送信されたメッセージからの情報を利用するために、それが必要です。 TCPのような信頼性の高い輸送については、これが保証されています。しかしながら、信頼性の低いトランスポートのために、のSigCompプロトコルは、機能自体を提供するために使用することができます。その機能は、この文書に記載されており、明示的な承認と呼ばれています。
Another mechanism that will improve the compression efficiency of SigComp, especially when SigComp is applied to protocols that are of request/response type, is shared compression. This involves using received messages in the SigComp compression process. In particular the compression of the first few messages will gain from shared compression. Shared compression is described in this document.
SigCompのがリクエスト/レスポンス型であるプロトコルに適用される場合は特に、のSigCompの圧縮効率を向上させる別の機構は、圧縮を共有しています。これは、SigCompの圧縮過程で受信したメッセージを使用することを含みます。特に、最初のいくつかのメッセージの圧縮は共有圧縮から得ることができます。共有圧縮は、この文書に記述されています。
For better understanding of this document the reader should be familiar with the concept of [SIGCOMP].
このドキュメントをより良く理解するために、読者は[SigCompの]の概念を理解する必要があります。
The reader should consult [SIGCOMP] for definitions of terminology, since this document uses the same terminology. Further terminology is defined below.
この文書は同じ用語を使用するため、読者は、用語の定義については、[のSigComp]相談してください。さらに、専門用語を以下に定義されます。
Compressor
コンプレッサー
Entity that encodes application messages using a certain compression algorithm and keeps track of state that can be used for compression. The compressor is responsible for ensuring that the messages it generates can be decompressed by the remote UDVM.
特定の圧縮アルゴリズムを使用してアプリケーション・メッセージを符号化し、圧縮のために使用することができる状態を追跡するエンティティ。コンプレッサーは、それが生成するメッセージは、リモートUDVMによって解凍できることを確実にする責任があります。
Decompressor
デコンプレッサ
The decompressor is responsible for converting a SigComp message into uncompressed data. Decompression functionality is provided by the UDVM.
デコンプレッサは、圧縮されていないデータへのSigCompメッセージを変換するための責任があります。解凍機能がUDVMによって提供されます。
Dynamic compression
動的圧縮
Compression relative to messages sent prior to the current compressed message.
現在の圧縮されたメッセージの前に送信されたメッセージに圧縮相対。
Explicit acknowledgement
明示的な承認
Acknowledgement for a state. The acknowledgment is explicitly sent from a decompressor to its remote compressor. The acknowledgement should be piggybacked onto a SigComp message in order not to create additional security risks.
状態のための謝辞。承認は、明示的にそのリモート圧縮機に解凍器から送信されます。確認は、追加のセキュリティリスクを作成しないようにするためにのSigCompメッセージにピギーバックされなければなりません。
Shared compression
共有圧縮
Compression relative to messages received by the local endpoint prior to the current compressed message.
前現在の圧縮メッセージにローカルエンドポイントで受信されたメッセージに圧縮相対。
Shared state
共有状態
A state used for shared compression consists only of an uncompressed message. This makes the state independent of the compression algorithm.
共有の圧縮のために使用される状態は、非圧縮メッセージから成ります。これは、圧縮アルゴリズムの状態は依存しないようにします。
State identifier
状態識別子
Reference used to access a previously created item of state.
状態の以前に作成した項目にアクセスするための基準。
- shared_state_id
- shared_state_id
State identifier of a shared state.
共有状態の状態識別子。
- acked_state_id
- acked_state_id
State identifier of a state that is acknowledged as
successfully saved by the decompressor.
SigComp has a request/response mechanism to provide feedback between endpoints, see Figure 1. This particular functionality of SigComp is used in this document to provide support for the mechanisms described in this document.
SigCompのは、SigCompのこの特定の機能は、本書で説明されたメカニズムのサポートを提供するために、本書で使用されている図1を参照して、エンドポイント間のフィードバックを提供するための要求/応答機構を有します。
+--------------------+ +--------------------+
| Endpoint 1 | | Endpoint 2 |
| +--------------+ | | +--------------+ |
| | Compressor 1 | | | |Decompressor 2| |
| | [------------+--+--------------+--+--] * | |
| +-|-------^----+ | | +--|---|-------+ |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| +-|-------|----+ | | +--v---|-------+ |
| | * [----+--+--------------+--+------] | |
| |Decompressor 1| | | | Compressor 2 | |
| +--------------+ | | +--------------+ |
+--------------------+ +--------------------+
Figure 1. Architectural view
図1.アーキテクチャビュー
The feedback functionality of SigComp is used in this document to provide a mechanism for a SigComp endpoint to confirm which states have been established by its remote SigComp endpoint during the lifetime of a SigComp compartment. The established state confirmations are referred to as acknowledgments. Depending on the established states this particular type of feedback may or may not be used to increase the compression efficiency.
SigCompのフィードバック機能は、SigCompの区画の寿命の間にその遠隔のSigComp終点によって確立された状態を確認するためのSigComp終点のためのメカニズムを提供するために、本書で使用されています。確立された状態の確認は、肯定応答と呼ばれます。確立された状態に応じてフィードバックのこの特定のタイプまたは圧縮効率を増加させるために使用してもしなくてもよいです。
The following sections describe how the SigComp functionality of providing feedback information is used to support the mechanisms described in this document. Section 4 describes the state reference model of SigComp. Section 5 continues with a general description of the mechanisms and Section 6 describes the implications of some of the mechanisms on basic SigComp.
以下のセクションでは、フィードバック情報を提供するのにSigComp機能は、本書で説明されたメカニズムをサポートするために使用される方法を記載しています。セクション4は、SigCompの状態の参照モデルを記載しています。セクション5は、機構の一般的な説明を継続し、セクション6は、基本的にSigComp上の機構のいくつかの意味を説明しています。
A UDVM may want to save the status of its memory, and this status is referred to as a state. As explained in [SIGCOMP] a state save request may or may not be granted by the application. For later reference to a saved state, e.g., if the UDVM is to be loaded with this state, a reference is needed to locate the specific state. This reference is called a state identifier.
UDVMは、そのメモリの状態を保存することができ、この状態が状態という。要求セーブ【のSigComp]状態で説明したように、またはアプリケーションによって付与してもしなくてもよいです。 UDVMは、この状態でロードされる場合に保存された状態に後で参照するために、例えば、基準は、特定の状態を検索するために必要とされます。このリファレンスは、状態識別子と呼ばれています。
When compressor 1 compresses a message m it uses the information corresponding to a SigComp state that its remote decompressor 2 has established and acknowledged. If compressor 1 wishes to use the new state for compression of later messages it must save the new state. The new state contains information from the former state and from m. When an acknowledgement is received for this new state, compressor 1 can utilize the new state in the compression process. Below is an overview of the model together with an example of a message flow.
圧縮機1は、メッセージmを圧縮するとき、それは、その遠隔減圧装置2が成立し、認めているのSigComp状態に対応する情報を使用します。圧縮機1は、後にメッセージの圧縮のための新しい状態を使用したい場合は、新しい状態を保存する必要があります。新しい状態が元の状態から、そしてmからの情報が含まれています。肯定応答は、この新しい状態のために受信されると、圧縮機1は、圧縮プロセスで新しい状態を利用することができます。以下のメッセージ・フローの例と一緒にモデルの概要です。
Saved state(s)
保存された状態（S）
A state which is expected to be used for compression/decompression of later messages.
後でメッセージの圧縮/伸長に使用されることが期待されている状態。
Acked state(s)
ACKさ状態（S）
An acked state is a saved state for which the compressor has received an acknowledgement, i.e., the state has been established at the remote decompressor. The compressor must only use states that are established at the remote decompressor, otherwise a decompression failure will occur. For this reason, acknowledgements are necessary, at least for unreliable transport.
ACKさ状態、すなわち、状態が遠隔減圧装置で確立された、圧縮機が肯定応答を受信したために保存された状態です。圧縮機は、そうでなければ減圧障害が発生すると、リモートデコンプレッサで確立された状態を使用しなければなりません。このため、確認応答は、少なくとも信頼性の低い輸送に必要です。
Compressor 1 Decompressor 2
+---+ +---+
| C | | D |
+---+ +---+
Saved Acked | | Saved
State(s) State(s) | | State(s)
-----------------------+------------+------------------
s0 s0 | | s0
s1=s0+m1 | --m1(s0)-->|
| <--ack(s1) | s0,s1
s0,s1 s0,s1 | |
| |
s0,s1 s0,s1 | --m2(s1)-->| (m2 Lost)
s2=s1+m1 | |
| |
s0-s2 s0,s1 | |
s3=s1+m3 | --m3(s1)-->| s0,s1
| |
| |
| <--ack(s3) | s0,s1,s3=s1+m3
s0-s3 s0,s1,s3 | |
Figure 2. Example of message flow for dynamic compression
動的圧縮のためのメッセージフローの図2の例
Legend: Message 1 compressed making use of state s0 is denoted m1(s0). The notation s1=s0+m1 means that state s1 is created using information from state s0 and message m1. ack(s1) means that the creation of state s1 is acknowledged through piggybacking on a message traveling in the reverse direction (which is not shown in the figure).
凡例：状態S0を利用して圧縮されたメッセージ1をM1（S0）で示されます。表記S1 = S0 + m1は状態S1が状態S0とメッセージM1からの情報を使用して作成されることを意味します。 ACK（S1）は、状態S1の作成は（図示しない）は、逆方向に進行メッセージにピギーバックを介して肯定応答されることを意味します。
The following subsections give a general description of the extended mechanisms.
以下のサブセクションでは、拡張メカニズムの一般的な説明を与えます。
For a compressor to be able to utilize a certain state it must know that the remote decompressor has access to this state.
コンプレッサーが一定の状態を利用できるようにするには、リモート・デコンプレッサがこの状態へのアクセス権を持っていることを知っている必要があります。
In the case where compressed messages can be lost or misordered on the path between compressor and decompressor, an acknowledgement scheme must be used to notify the remote compressor that a certain state has been established.
圧縮されたメッセージが失わまたはコンプレッサとデコンプレッサとの間の経路上にmisorderedすることができる場合には、肯定応答方式は、特定の状態が確立されたリモートコンプレッサに通知するために使用されなければなりません。
Explicit acknowledgements can be initiated either by UDVM-code uploaded to the decompressor by the remote compressor or by the endpoint where the states have been established. These two cases will be explained in more detail in the following two sections.
明示的な確認応答は、リモート・コンプレッサによって解凍器にアップロードUDVMコードまたは状態が確立されているエンドポイントのいずれかによって開始することができます。これらの2つのケースは、次の2つのセクションでより詳細に説明します。
This is the case when e.g., compressor 1 has uploaded UDVM bytecode to decompressor 2. The UDVM bytecode will use the requested feedback field in the announcement information and the returned feedback field in the SigComp header to obtain knowledge about established states at endpoint 2.
例えば、圧縮機1は、UDVMバイトコードがエンドポイント2で確立された状態についての知識を得るためのSigCompヘッダで報知情報と戻されるフィードバック分野で要求フィードバックフィールドを使用する2.デコンプレッサするUDVMバイトコードをアップロードした場合です。
Consider Figure 3. An event flow for successful use of remote compressor initiated acknowledgements can be as follows:
図3.次のようにすることができ、リモートコンプレッサー開始確認応答の使用の成功のためのイベントの流れを考えてみます。
(1): Compressor 1 saves e.g., state(A). (2): The UDVM bytecode to initiate a state save for state(A) is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): As compressor 1 is the initiator of this acknowledgement it can use an arbitrary identifier to be returned to indicate that state(A) has been established. The identifier needs to consist of enough bits to avoid acknowledgement of wrong state. To avoid padding of the feedback items and for simplicity a minimum of 1 octet should be used for the identifier. The identifier is placed at the location of the requested_feedback_item [SIGCOMP]. The END-MESSAGE instruction is used to indicate the location of the requested_feedback_item to the state handler. (4): The requested feedback data is now called returned feedback data as it is placed into the SigComp message at compressor 2. (5): The returned feedback item is carried in the SigComp message according to Figure 4: see Section 6.1 and [SIGCOMP]. (6): The returned feedback item is handled according to: Section 7 of [SIGCOMP]
（1）圧縮機1は、例えば保存し、状態（A）。 （2）：UDVMバイトコードは、圧縮されたメッセージで運ばれるか、状態（A）に保存状態を開始するため、または既にエンドポイント2で保存された状態から解凍装置2によって取得することができる（3）：圧縮機1であるようにこの確認応答の開始は、状態（A）が確立されていることを示すために返される任意の識別子を使用することができます。識別子は間違った状態の確認応答を回避するために十分なビットで構成する必要があります。フィードバック項目のパディングを回避し、簡単にするために1つのオクテットの最小値は、識別子のために使用されるべきです。識別子はrequested_feedback_item【のSigComp]の位置に配置されています。 END-MESSAGE命令は状態ハンドラへrequested_feedback_itemの位置を示すために使用されます。 （4）：要求されたフィードバックデータは、現在と呼ばれ、それは、圧縮機2でのSigCompメッセージに置かれているように（5）フィードバックデータを返した：返されたフィードバック項目は、図4に記載のSigCompメッセージに実施される：第6.1節および[参照SigComp]。 （6）：のSigComp]のセクション7：返されたフィードバック項目はに従って処理され
+--------------+ (2) +--------------+
| Compressor 1 |--------------------------->|Decompressor 2|
+------^-------+ +-------^------+
| (1) (3) |
+---v---+ +---v---+
|State | |State |
|handler| |handler|
+---^---+ +---^---+
| (6) (4) |
+------v-------+ (5) +-------v------+
|Decompressor 1|<---------------------------| Compressor 2 |
+--------------+ +--------------+
Figure 3. Simplified SigComp endpoints
図3.簡体字のSigCompエンドポイント
When explicit acknowledgements are provided by an endpoint, the SigComp message will also carry acknowledgements, so-called acked_state_id: see Section 2. Consider Figure 3, an event flow for successful use of explicit endpoint initiated acknowledgements can be as follows:
明示的な確認応答がエンドポイントによって提供されている場合、のSigCompメッセージもacked_state_idいわゆる承認を運ぶます。図3を検討セクション2を参照してください、明示的なエンドポイントの使用の成功のためのイベント・フローは次のように確認応答が可能開始しました：
(1): Compressor 1 saves e.g., state(A). (2): The UDVM bytecode to initiate a state save for state(A) is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): A save state request for state(A) is passed to the state handler using the END-MESSAGE instruction. The application may then grant the state handler permission to save state(A): see [SIGCOMP]. (4): Endpoint 2 decides to acknowledge state(A) to endpoint 1. The state identifier (acked_state_id) for state(A) is placed in the SigComp message sent from compressor 2 to decompressor 1. (5): The UDVM bytecode to initiate (pass) the explicit acknowledgement to endpoint 1 is either carried in the compressed message, or can be retrieved by decompressor 1 from a state already saved at endpoint 1. (6): The acked_state_id for state(A) is passed to the state handler by placing the acked_state_id at the location of the "returned SigComp parameters" [SIGCOMP], whose location is given to the state handler using the END-MESSAGE instruction.
（1）圧縮機1は、例えば保存し、状態（A）。 （2）：UDVMバイトコードは、圧縮されたメッセージで運ばれるか、状態（A）に保存状態を開始する、または既にエンドポイント2（3）に保存された状態から解凍装置2によって取得することができる：保存状態要求の状態（A）は、END-MESSAGE命令を使用して状態ハンドラに渡されます。その後、状態を保存する状態ハンドラ権限を付与することができるアプリケーションは、（A）：[SigCompの]を参照してください。 （4）エンドポイント2は、状態（A）1.状態識別子（acked_state_id）をエンドポイントする状態（A）を確認することを決定するのSigCompメッセージに置かれているデコンプレッサ1に圧縮機2から送られてきた（5）：UDVMバイトコードに1は、圧縮されたメッセージで運ばれるか、または既にエンドポイント1（6）に保存された状態から減圧装置1によって取得することができるエンドポイントする明示的な確認応答開始（通過）：状態（A）のためのacked_state_idする状態に渡されます。位置END-MESSAGE命令を使用して状態ハンドラに与えられる「が返さのSigCompパラメータ」【のSigComp]の位置にacked_state_idを配置することによってハンドラ。
Note: When the requested feedback length is non-zero endpoint initiated acknowledgements should not be used, due to possible waste of bandwidth. When deciding to implement this mechanism one should consider whether this is worth the effort as all SigComp implementations will support the feedback mechanism and thus have the possibility to implement the mechanism of Section 5.1.1.
注意：要求されたフィードバックの長さがゼロ以外のエンドポイントは、確認応答が帯域幅の可能性廃棄物に、使用すべきではありません開始されます。このメカニズムを実装するために決定する際に一つは、これはすべてのSigComp実装がフィードバック機構をサポートするため、5.1.1項のメカニズムを実装する可能性がありますよう努力する価値があるかどうかを検討すべきです。
To make use of shared compression a compressing endpoint saves the uncompressed version of the compressed message as a state (shared state). As described in Section 2 the reference to a shared state is referred to as shared_state_id. The shared state's parameters state_address and state_instruction must be set to zero. The state_retention_priority must be set to 65535, and the other state parameters are set according to [SIGCOMP]. This is because different compression algorithms may be used to compress application messages traveling in different directions. The shared state is also created on a per-compartment basis, i.e., the shared state is stored in the same memory as the states created by the particular remote compressor. The choice of how to divide the state memory between "ordinary" states and shared states is an implementation decision at the compressor. Note that new shared state items must not be created unless the compressor has made enough state memory available (as decompression failure could occur if the shared state pushed existing state out of the state memory buffer).
共有圧縮を利用するために圧縮エンドポイントは状態（共有状態）などの圧縮されたメッセージの非圧縮バージョンを保存します。第2節で説明したように、共有状態への参照がshared_state_idと呼ばれます。共有状態のパラメータstate_addressとstate_instructionをゼロに設定する必要があります。 state_retention_priorityは65535に設定する必要があり、そして他の状態パラメータは、[のSigComp]に応じて設定されます。異なる圧縮アルゴリズムが異なる方向に走行アプリケーションメッセージを圧縮するために使用することができるからです。共有状態もあたり区画基づいて作成され、すなわち、共有状態は、特定のリモート・コンプレッサによって作成された状態と同じメモリに記憶されます。 「普通」の状態と共有状態の間の状態のメモリを分割する方法の選択は、コンプレッサの実装決定です。圧縮機（共有状態が状態メモリバッファのうち、既存の状態を押した場合に減圧障害が起こり得るように）十分な状態メモリが利用可能になっていない限り、新たな共有状態の項目が作成されてはならないことに留意されたいです。
A compressing endpoint must also indicate to the remote compressor that the shared state is available, but only if the local decompressor can retrieve the shared state. The retrieval of the shared state is done according to the state retrieval instruction of the UDVM.
圧縮エンドポイントは、共有状態が使用可能であることをリモートコンプレッサーに示す必要がありますが、地元のデコンプレッサは、共有状態を取得できた場合にのみ。共有状態の検索は、UDVMの状態検索命令に従って行われます。
Consider Figure 3. An event flow for successful use of shared compression can be as follows:
図3.次のようにすることができ、共有圧縮の使用の成功のためのイベントの流れを考えてみます。
(1): Compressor 1 saves e.g., state(M), which is the uncompressed version of the current application message to be compressed and sent. (2): The UDVM bytecode to indicate the presence of state(M) at endpoint 1 is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): The SHA-1 instruction is used at endpoint 2 to calculate the shared_state_id for state(M). The indication is passed to the state handler, by placing the shared identifier at the location of the "returned SigComp parameters" [SIGCOMP]. The location of the "returned SigComp parameters" is given to the state handler using the END-MESSAGE instruction. (4): If endpoint 2 uses shared compression, it compares the state identifier values in the "returned SigComp parameters" information with the value it has calculated for the current decompressed message received from endpoint 1. If there is a match then endpoint 2 uses the shared state together with the state it would normally use if shared compression is not supported to compress the next message. (5): The UDVM bytecode that will use the shared state (state(M)) in the decompression process at decompressor 1 is either carried in the compressed message, or can be retrieved by decompressor 1 from a state already saved at endpoint 1.
（1）圧縮機1は、例えば、圧縮され送信される現在のアプリケーション・メッセージの圧縮されていないバージョンである状態（M）を、保存します。 （2）：UDVMバイトコードは、圧縮されたメッセージで運ばれるか、エンドポイント1の状態（M）の存在を示すために、又は既にエンドポイント2（3）に保存された状態から解凍装置2によって取得することができる。SHA- 1つの命令は、状態（M）用shared_state_idを計算するために、エンドポイント2で使用されています。指示は、「返さのSigCompパラメータ」【のSigComp]の位置で共有識別子を配置することによって、ステートハンドラに渡されます。 「返されたSigCompパラメータ」の場所は、END-MESSAGE命令を使用した状態ハンドラに与えられています。 （4）エンドポイント2が共有圧縮を使用している場合、それは、状態識別子の値を比較し、それがエンドポイント1から受信した現在の解凍メッセージを計算した値との情報の一致がある場合、2回の使用をエンドポイント「のSigCompパラメータを返さ」共有圧縮が次のメッセージを圧縮するためにサポートされていない場合、それは通常使用する状態と一緒に共有状態。 （5）：解凍装置1における伸長処理に共有状態（状態（M））を使用するUDVMバイトコードは、圧縮されたメッセージで運ばれるか、または既にエンドポイント1に保存された状態から減圧装置1によって取得することができます。
Usually, signaling protocols (e.g., SIP) employ the concept of sessions. However, from the compression point of view, the messages sent by the same source contain redundancies beyond the session boundary. Consequently, it is natural to maintain the state data from the same source across sessions so that high performance can be achieved and maintained, with the overhead amortized over a much longer period of time than one application session.
通常、シグナリングプロトコル（例えば、SIP）セッションの概念を採用しています。しかし、ビューの圧縮ポイントから、同じソースによって送信されたメッセージは、セッション境界を越えて冗長性を含んでいます。従って、高い性能を達成し、維持することができるように、一つのアプリケーション・セッションよりも時間のかなり長い期間にわたって償却オーバーヘッドで、セッション間で同じソースからの状態データを維持することが自然です。
Maintaining states across application sessions can be achieved simply by making the lifetime of a compartment longer than the time duration of a single application session. Note that the states here are referring to those stored on a per-compartment basis, not the locally available states that are stored on a global basis (i.e., not compartment specific).
アプリケーションのセッション間で状態を維持することはもはや単一のアプリケーションのセッションの持続時間よりもコンパートメントの寿命を作ることによって簡単に達成することができます。状態はここあたりコンパートメントに基づいて格納されているものを参照していることに注意し、グローバルに格納されていないローカルで利用可能な状態（即ち、特定の区画ではありません）。
The concept of the user-specific dictionary is based on the observation that for protocols such as SIP, a given user/device combination will produce some messages containing fields that are always populated with the same data.
ユーザー固有の辞書の概念は、SIPなどのプロトコルのために、所与のユーザ/デバイスの組み合わせは、常に同じデータが移入されたフィールドを含むいくつかのメッセージを生成するという観察に基づいています。
Take SIP as an example. Capabilities of the SIP endpoints are communicated during session initiation, and tend not to change unless the capabilities of the device change. Similarly, user-specific information such as the user's URL, name, and e-mail address will likely not change on a frequent basis, and will appear regularly in SIP signaling exchanges involving a specific user.
一例として、SIPを取ります。 SIPエンドポイントの機能は、セッション開始時の通信、およびデバイスの変更の能力がない限り変更しない傾向があります。同様に、ユーザー固有の、ユーザのURLなどの情報、名前、および電子メールアドレスは、そう頻繁に変更されることはありませんし、特定のユーザーを含むSIPシグナリングの交換で定期的に表示されます。
Therefore, a SigComp compressor could include the user-specific dictionary as part of the initial messages to the decompressor, even before any time critical signaling messages are generated from a particular application. This enables an increase in compression efficiency once the messages start to flow.
したがって、SigCompの圧縮機は、任意のタイムクリティカルなシグナリングメッセージは、特定のアプリケーションから生成される前であっても、解凍器への初期メッセージの一部としてユーザー固有の辞書を含むことができます。メッセージが流れ始めたら、これは圧縮効率の向上を可能にします。
Obviously, the user-specific dictionary is a state item that would be good to have as a cross-session state: see Section 5.3.
もちろん、ユーザー固有の辞書は、クロスセッション状態として持つことが良いでしょう状態項目です：セクション5.3を参照してください。
The following mechanism can be used to avoid decompression failure due to reference to a non-existent state. This may occur in three cases: a) a state is not established at the remote SigComp endpoint due to the loss of a SigComp message; b) a state is not established due to insufficient memory; c) a state has been established but was deleted later due to insufficient memory.
以下の機構が存在しない状態に参照による伸張失敗を回避するために使用することができます。これは、3つの場合に発生する可能性があります。a）状態のSigCompメッセージの喪失に起因する遠隔のSigComp終点で確立されていません。 b）の状態は、メモリ不足のために確立されていません。 c）の状態が確立されていますが、メモリ不足のため、後に削除されました。
When a compressor sends a SigComp message that will create a new state on the decompressor side, it can indicate that the newly created state will be a checkpoint state by setting state_retention_priority [SIGCOMP] to the highest value sent by the same compressor. In addition, a checkpoint state must be explicitly acknowledged by the receiving decompressor to the sending compressor.
コンプレッサーは、デコンプレッサ側の新しい状態を作成するのSigCompメッセージを送信するときに、新しく作成された状態は同じ圧縮機によって送信された最高値に[のSigComp] state_retention_priorityを設定することで、チェックポイントの状態になることを示すことができます。また、チェックポイントの状態が明示的に送信する圧縮機へ受信デコンプレッサによって承認されなければなりません。
Consider Figure 3. An event flow for this kind of state management can be as follows:
図3.次のようにすることができ、状態管理のこの種のイベントの流れを考えてみます。
(1): Compressor 1 saves e.g., state(A), which it would like to have as a checkpoint state at decompressor 2. (2): The UDVM bytecode to indicate the state priority ([SIGCOMP] state_retention_priority) of state(A) and initiate a state save for state(A) is either carried in the compressed message, or can be retrieved by decompressor 2 from a state already saved at endpoint 2. (3): A save state request for state(A) is passed to the state handler using the END-MESSAGE instruction, including the indication of the state priority. The application grants the saving of state(A): see [SIGCOMP]. (4): An acknowledgement for state(A) (the checkpoint state) is returned to endpoint 2 using one of the mechanisms described in Section 5.1.
（1）状態の状態の優先度（[のSigComp] state_retention_priority）を示すためにUDVMバイトコード（A：圧縮機1は、減圧装置2（2）でのチェックポイントの状態として持っていると思います例えば、状態（A）は、保存さ）及び状態（A）に保存状態を開始するが、圧縮されたメッセージで運ばれるか、または（3）既にエンドポイント2で保存された状態から解凍装置2によって取得することができる：状態（A）のセーブ状態要求が渡されます状態優先の指示を含むEND-MESSAGE命令を使用して、状態ハンドラへ。 【のSigComp]参照：アプリケーションは、（A）状態の保存を許可します。 （4）：状態（A）（チェックポイント状態）に対する肯定応答は、セクション5.1で説明したメカニズムのいずれかを使用して2エンドポイントに戻されます。
Note: To avoid using a state that has been deleted due to insufficient memory a compressor must keep track of the memory available for saving states at the remote endpoint. The SigComp parameter state_memory_size which is announced by the SigComp feedback mechanism can be used to infer if a previous checkpoint state has been deleted (by a later checkpoint state creation request) due to lack of memory.
注意：コンプレッサーは、リモートエンドポイントでの状態を保存するために利用可能なメモリを追跡する必要がありますメモリ不足に削除された状態を使用しないようにします。 SigCompフィードバックメカニズムが発表されたのSigCompパラメータstate_memory_sizeは前のチェックポイントの状態がメモリ不足のため（後にチェックポイントの状態の作成要求により）削除された場合は推測するために使用することができます。
Usually a state consists of two parts: UDVM bytecode and dictionary. When dynamic compression is applied, new content needs to be added to the dictionary. To keep an upper bound of the memory consumption such as in the case for a low end mobile terminal, existing content of the dictionary must be deleted to make room for the new content.
UDVMバイトコードと辞書：通常の状態では2つの部分からなります。動的圧縮が適用されると、新しいコンテンツは辞書に追加する必要があります。こうしたローエンド携帯端末の場合と同様に、メモリ消費量の上限を維持するために、辞書の既存のコンテンツが新しいコンテンツのためのスペースを確保するために削除する必要があります。
Instead of explicitly signaling which parts of the dictionary need to be deleted on a per message basis, an implicit deletion approach may be applied. Specifically, some parts of the dictionary are chosen to be deleted according to a well-defined algorithm that is known and applied in the same way at both compressor and decompressor. For instance, the algorithm can be part of the predefined UDVM bytecode that is agreed between the two SigComp endpoints. As input to the algorithm, one provides the total number of bytes to be deleted. The algorithm then specifies which parts of the dictionary are to be deleted. Since the same algorithm is applied at both SigComp endpoints, there is no need for explicit signaling on a per message basis. This may lead to higher compression efficiency due to the avoidance of signaling overhead. It also means more robustness as there are no signaling bits on the wire that are subject to possible transmission errors/losses.
代わりに、明示的辞書の部分がメッセージごとに削除する必要があるシグナリングの、暗黙の削除手法を適用することができます。具体的には、辞書の一部は既知であり、コンプレッサーと減圧の両方で同様に適用され、明確に定義されたアルゴリズムに従って削除されるように選択されます。例えば、アルゴリズムは、2つのSigComp終点との間で合意された事前定義されたUDVMバイトコードの一部であってもよいです。アルゴリズムへの入力として、一方が削除されるバイトの合計数を提供します。次いで、アルゴリズムは、辞書の部分が削除されるかを指定します。同じアルゴリズムが両方のSigComp終点で適用されるので、メッセージごとに明示的なシグナリングは不要です。これは、シグナリングオーバーヘッドの回避のために、より高い圧縮効率をもたらし得ます。それはまた、可能な伝送エラー/損失を受けやすいワイヤにはシグナリングビットが存在しないように、よりロバスト性を意味します。
The extended features will have implications on the SigComp messages sent between the compressor and its remote decompressor, and on how to interpret e.g., returned SigComp parameters [SIGCOMP]. However, except for the mandatory bytes of the SigComp messages [SIGCOMP], the final message formats used are implementation issues. Note that an implementation that does not make use of explicit acknowledgements and/or shared compression is not affected, even if it receives this kind of feedback.
拡張機能は、圧縮機とそのリモート減圧装置との間で送信されるのSigCompメッセージの意味を有し、例えば、解釈する方法であろう、[のSigComp]のSigCompパラメータを返さ。ただし、のSigCompメッセージ【にSigComp]の必須のバイトを除いて、使用される最終的なメッセージフォーマットは実装上の問題です。それは、フィードバックのこの種のを受けても、明示的な確認応答および/または共有の圧縮を使用しない実装は影響されないことに注意してください。
To support the extended features, SigComp messages must carry the indications and information addressed in Section 5. For example to support shared compression and explicit acknowledgements the SigComp messages need to convey the following information:
拡張機能をサポートするために、SigCompのメッセージは、SigCompのメッセージは、以下の情報を伝えるために必要な共有の圧縮と明示的な承認をサポートするために、例えば、第5節で扱わ兆候や情報を伝える必要があります。
- The acked_state_id as described in Sections 2 and 5.1. - The shared_state_id as described in Sections 2 and 5.2.
- セクション2および5.1に記載されているようにacked_state_id。 - セクション2および5.2に記載されているようにshared_state_id。
Figure 4 depicts the format of a SigComp message according to [SIGCOMP]:
図4は、[のSigComp]に記載のSigCompメッセージのフォーマットを示す図です。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | len | | 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: returned feedback item : : returned feedback item :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | code_len |
: partial state identifier : +---+---+---+---+---+---+---+---+
| | | code_len | destination |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| | | |
: remaining SigComp message : : uploaded UDVM bytecode :
| | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
Figure 4. Format of a SigComp message
SigCompメッセージの図4.フォーマット
The format of the field "remaining SigComp message" is an implementation decision by the compressor which supplies the UDVM bytecode. Therefore there is no need to specify a message format to carry the information necessary for the extended features described in this document.
フィールド「残りのSigCompメッセージ」のフォーマットは、UDVMバイトコードを供給する圧縮機によって実装の決定です。したがって、この文書で説明拡張機能のために必要な情報を運ぶためにメッセージ形式を指定する必要はありません。
Figure 5 depicts an example of what the "remaining SigComp message" with support for shared compression and explicit acknowledgements, could look like. Note that this is only an example; the format is an implementation decision.
図5は、共有の圧縮と明示的な確認応答をサポートする「残りのSigCompメッセージが」、のように見えることができるものの一例を示しています。これは一例に過ぎないことに留意されたいです。形式は実装決定です。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Format according to Figure 4 |
: except for the field called :
| "remaining SigComp message" | "remaining SigComp message" field
+---+---+---+---+---+---+---+---+ --------
| s | a | r | Reserved | |
+---+---+---+---+---+---+---+---+ |
| | |
: shared_state_id* : Present if 's' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: acked_state_id* : Present if 'a' is set
| | |
+---+---+---+---+---+---+---+---+ |
| | |
: Rest of the SigComp message : |
| | v
+---+---+---+---+---+---+---+---+ --------------
Figure 5. Example of SigComp message for some of the extended features.
拡張機能の一部についてのSigCompメッセージの5例を図。
'r' : If set, then a state corresponding to the decompressed version of this compressed message (shared state) was saved at the compressor. * : The length of the shared_state_id and acked_state_id fields are of the same length as the partial state identifier.
「R」：設定されている場合、この圧縮されたメッセージ（共有状態）の伸長バージョンに対応する状態は、圧縮機で保存しました。 *：shared_state_idとacked_state_idフィールドの長さは、部分的状態識別子と同じ長さです。
This section describes how the "returned_SigComp_parameters" [SIGCOMP] information is interpreted to provide feedback according to Section 5.1 and 5.2.
このセクションでは、「returned_SigComp_parameters」【のSigComp】情報は、セクション5.1および5.2に係るフィードバックを提供するように解釈される方法を記載しています。
The partial_state_identifiers correspond to the hash_value for states that have been established at the remote endpoint after the reception of SigComp messages, i.e., these are acknowledgements for established states and may be used for compression. The partial_state_identifiers may also announce "global state" that is not mapped to any particular compartment and is not established upon the receipt of a SigComp message.
partial_state_identifiers、すなわち、これらは、確立された状態および圧縮のために使用することができるための肯定応答である、のSigCompメッセージの受信後、リモートエンドポイントで確立されている状態についてHASH_VALUEに対応します。 partial_state_identifiersはまた、任意の特定の区画にマッピングされていないとのSigCompメッセージの受信時に確立されていない「グローバルな状態を」アナウンスすることができます。
It is up to the implementation to deduce what kind of state each partial_state_identifier refers to, e.g., an acknowledged state or a shared state. In case a SigComp message that includes state identifiers for shared states and/or acknowledged states is received by a basic SigComp implementation, these identifiers will be ignored.
これは、例えば、各partial_state_identifierが参照状態のどのような肯定応答状態または共有の状態を推定するために、実装次第です。場合には、共有状態および/または肯定応答状態について状態識別子を含むのSigCompメッセージは、これらの識別子は無視され、基本のSigComp実装によって受信されます。
The I-bit of the requested feedback format is provided to switch off the list of locally available state items. An endpoint that wishes to receive shared_state_id must not set the I-bit to 1. The endpoint storing shared states and sending the list of locally available states to its remote endpoint must be careful when taking the decision whether to exclude or include different types of the locally available states (i.e., shared states or states of e.g., well-known algorithms) from/to the list.
要求されたフィードバック形式のIビットは、局所的に利用可能な状態の項目のリストをオフにするために設けられています。 shared_state_idを受信したいエンドポイントは、異なるタイプのを除外または含めるするかどうかの決定を取ったときにエンドポイントの共有状態を保存し、そのリモートエンドポイントにローカルで利用可能な状態のリストを送信するには注意しなければならない1にIビットを設定してはいけませんローカルで利用可能な状態（すなわち、共有状態または例えば、周知のアルゴリズムの状態）リストへ/から。
If shared compression is used between two endpoints (see Figure 1) then there exists an optimization, which, if implemented, makes an acked_state_id in the SigComp message unnecessary:
共有圧縮が2つのエンドポイント間で使用される場合、実装されている場合、不要のSigCompメッセージにacked_state_idを行う最適化を、存在する（図1参照）。
Compressor 1 saves a shared state(M), which is the uncompressed version of the current compressed message (message m) to be sent. Compressor 1 also sets bit 'r' (see Figure 5), to signal that state(M) can be used by endpoint 2 in the compression process. The acked_state_id for state(S), which was created at endpoint 2 upon the decompression of message m, may not have to be explicitly placed in the compressed messages from compressor 2 if the shared state(M) is used in the compression process.
圧縮機1は、送信される現在の圧縮されたメッセージ（メッセージm）の非圧縮バージョンである共有状態（M）を、保存します。圧縮機1は、ビット「r」を設定している状態（M）を通知するために、（図5参照）、圧縮プロセスにおいて、エンドポイント2で使用することができます。メッセージmの減圧時に、エンドポイント2で作成された状態のためacked_state_id（S）は、共有状態（M）は、圧縮工程で使用される場合、明示的に、圧縮機2からの圧縮されたメッセージ内に配置する必要はないかもしれません。
When endpoint 1 notices that shared state(M) is requested by decompressor 1, it implicitly knows that state(S) was created at endpoint 2. This follows since:
状態（M）を共有するエンドポイント1つの通知を解凍器1によって要求された場合、それは暗黙的にエンドポイント2の状態（S）が作成されたことを知っているこれは、以来、次のとおりです。
* Compressor 1 has instructed decompressor 2 to save state(S). * The indication of shared state(M) would never have been received by compressor 2 if state(S) had not been successfully saved, because if a state save request is denied then the corresponding announcement information is discarded by the state handler.
*圧縮機1は、状態（S）を保存するデコンプレッサ2を指示しました。要求の保存状態が拒否された場合、対応する告知情報が状態ハンドラによって破棄されるので、状態（S）が正常に保存されていない場合*共有状態（M）の表示は、圧縮機2によって受信されなかったでしょう。
Note: Endpoint 1's state handler must maintain a mapping between state(M) and state(S) for this optimization to work.
注意：エンドポイントは、1の状態ハンドラが動作するように、この最適化のための状態（M）および状態（S）との間のマッピングを維持する必要があります。
Note: The only state that is acknowledged by this feature is the state that was created by combining the state used for compression of the message and the message itself. For any other case the acked_state_id has to be used.
注：この機能によって確認されただけの状態では、メッセージとメッセージ自体の圧縮に使用される状態を組み合わせることによって作成された状態です。他のケースではacked_state_idを使用する必要があります。
Note: There is a possibility that state(S) is discarded due to lack of state memory even though the announcement information is successfully forwarded. This possibility must be taken into account (otherwise a decompression failure may occur); this can be done by using the SigComp parameter state_memory_size which is announced by the SigComp feedback mechanism. The endpoint can use this parameter to infer if a state creation request has failed due to lack of memory.
注意：状態（S）は報知情報が正常に転送されていても起因する状態メモリの不足のために廃棄されている可能性があります。この可能性は、（そうでなければ減圧障害が発生する可能性）を考慮しなければなりません。これは、のSigCompフィードバックメカニズムが発表されたのSigCompパラメータstate_memory_sizeを使用して行うことができます。状態の作成要求がメモリ不足のため失敗した場合、エンドポイントが推測するには、このパラメータを使用することができます。
The features in this document are believed not to add any security risks to the ones mentioned in [SIGCOMP].
この文書に記載されている機能は、[のSigComp]で述べたものに任意のセキュリティリスクを追加しないと考えられています。
This document does not require any IANA involvement.
このドキュメントは、IANAの関与を必要としません。
Thanks to Carsten Bormann, Christopher Clanton, Miguel Garcia, Lars-Erik Jonsson, Khiem Le, Mats Nordberg, Jonathan Rosenberg and Krister Svanbro for valuable input.
カルステンボルマン、クリストファー・クラントン、ミゲル・ガルシア、ラース・エリックジョンソン、Khiemル、マットノードバーグ、ジョナサン・ローゼンバーグと貴重な入力のためのクリスターSvanbroに感謝します。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
[SIP] 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.
[SIP]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[SIGCOMP] Price R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
【のSigComp]価格R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、劉、Z.およびJ.ローゼンバーグ、 "シグナリング圧縮（SigCompの）"、RFC 3320、2003年1月。
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
彼のハンヌボックス920エリクソンAB、SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 21 84 EMail: hans.hannu@epl.ericsson.se
電話：+46 920 20 21 84 Eメール：hans.hannu@epl.ericsson.se
Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden
1月Christofferssonボックス920エリクソンAB、SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 28 40 EMail: jan.christoffersson@epl.ericsson.se
電話：+46 920 20 28 40 Eメール：jan.christoffersson@epl.ericsson.se
Stefan Forsgren
ステファンForsgren
EMail: StefanForsgren@alvishagglunds.se
メールアドレス：StefanForsgren@alvishagglunds.se
Ka-Cheong Leung Department of Computer Science Texas Tech University Lubbock, TX 79409-3104 United States of America
コンピュータサイエンステキサス工科大学のKA-チョンレオン部門アメリカのラボック、TX 79409-3104米国
Phone: +1 806 742-3527 EMail: kcleung@cs.ttu.edu
電話：+1 806 742-3527 Eメール：kcleung@cs.ttu.edu
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039, USA
志剛劉ノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039、USA
Phone: +1 972 894-5935 EMail: zhigang.c.liu@nokia.com
電話：+1 972 894-5935 Eメール：zhigang.c.liu@nokia.com
Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN, United Kingdom
リチャード価格Rokeマナーリサーチ株式会社ロムジー、ハンツ、SO51 0ZN、イギリス
Phone: +44 1794 833681 EMail: richard.price@roke.co.uk
電話：+44 1794 833681 Eメール：richard.price@roke.co.uk
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。