Network Working Group R. Price
Request for Comments: 3320 Siemens/Roke Manor
Category: Standards Track C. Bormann
TZI/Uni Bremen
J. Christoffersson
H. Hannu
Ericsson
Z. Liu
Nokia
J. Rosenberg
dynamicsoft
January 2003
Signaling Compression (SigComp)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP) (RFC 3261) and the Real Time Streaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of the SigComp message.
この文書では、シグナリング圧縮（SigCompの）は、そのようなセッション開始プロトコル（SIP）（RFC 3261）およびリアルタイムストリーミングプロトコル（RTSP）（RFC 2326）などのアプリケーション・プロトコルによって生成されたメッセージを圧縮するためのソリューションを定義します。アーキテクチャとのSigCompの前提条件のSigCompメッセージのフォーマットと共に、概説されています。
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).
SigCompのための解凍機能は、解凍アルゴリズムを実行するタスクのために最適化されたユニバーサルデコンプレッサ仮想マシン（UDVM）によって提供されます。 UDVMは、DEFLATE（RFC-1951）などの多くの周知の圧縮機の出力を理解するように構成することができます。
Table of Contents
目次
1. Introduction...................................................2
2. Terminology....................................................3
3. SigComp architecture...........................................5
4. SigComp dispatchers...........................................15
5. SigComp compressor............................................18
6. SigComp state handler.........................................20
7. SigComp message format........................................23
8. Overview of the UDVM..........................................28
9. UDVM instruction set..........................................37
10. Security Considerations.......................................56
11. IANA Considerations...........................................58
12. Acknowledgements..............................................59
13. References....................................................59
14. Authors' Addresses............................................60
15. Full Copyright Statement......................................62
Many application protocols used for multimedia communications are text-based and engineered for bandwidth rich links. As a result the messages have not been optimized in terms of size. For example, typical SIP messages range from a few hundred bytes up to two thousand bytes or more [RFC3261].
マルチメディア通信のために使用される多くのアプリケーションプロトコルは、テキストベースおよび帯域幅が豊富なリンクのために設計されています。その結果、メッセージは、サイズの点で最適化されていません。例えば、典型的なSIPメッセージは数百バイトから最大2000バイト以上の[RFC3261]の範囲です。
With the planned usage of these protocols in wireless handsets as part of 2.5G and 3G cellular networks, the large message size is problematic. With low-rate IP connectivity the transmission delays are significant. Taking into account retransmissions, and the multiplicity of messages that are required in some flows, call setup and feature invocation are adversely affected. SigComp provides a means to eliminate this problem by offering robust, lossless compression of application messages.
2.5Gおよび3G携帯電話ネットワークの一部として、ワイヤレスハンドセットにおけるこれらのプロトコルの利用予定で、大規模なメッセージサイズが問題となります。低レートのIP接続で伝送遅延が重要です。アカウントの再送信、および一部のフローで必要とされるメッセージの多重度を考慮して、コールセットアップおよび機能の起動が悪影響を受けます。 SigCompのは、アプリケーションメッセージの堅牢な、可逆圧縮を提供することで、この問題を解消するための手段を提供します。
This document outlines the architecture and prerequisites of the SigComp solution, the format of the SigComp message and the Universal Decompressor Virtual Machine (UDVM) that provides decompression functionality.
この文書では、SigCompのソリューション、のSigCompメッセージと解凍機能を提供し、ユニバーサルデコンプレッサ仮想マシン（UDVM）の形式のアーキテクチャと前提条件を概説します。
SigComp is offered to applications as a layer between the application and an underlying transport. The service provided is that of the underlying transport plus compression. SigComp supports a wide range of transports including TCP, UDP and SCTP [RFC-2960].
SigCompのは、アプリケーションと基礎となるトランスポート間の層としての用途に提供されます。提供されるサービスは、基礎となるトランスポートプラス圧縮のものです。 SigCompはTCP、UDP、およびSCTP [RFC-2960]を含むトランスポートの広い範囲をサポートしています。
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 BCP 14, RFC 2119 [RFC-2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC-2119]に記載されているように解釈されます。
Application
応用
Entity that invokes SigComp and performs the following tasks:
SigCompを起動し、次のタスクを実行するエンティティ：
1. Supplying application messages to the compressor dispatcher 2. Receiving decompressed messages from the decompressor dispatcher 3. Determining the compartment identifier for a decompressed message.
1.解凍メッセージのコンパートメント識別子を決定デコンプレッサディスパッチャ3から解凍メッセージを受信コンプレッサディスパッチャ2にアプリケーション・メッセージを供給します。
Bytecode
バイトコード
Machine code that can be executed by a virtual machine.
仮想マシンで実行することができますマシンコード。
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によって解凍できることを確実にする責任があります。
Compressor Dispatcher
コンプレッサーディスパッチャ
Entity that receives application messages, invokes a compressor, and forwards the resulting SigComp compressed messages to a remote endpoint.
アプリケーション・メッセージを受信するエンティティは、圧縮機を起動し、リモートエンドポイントに得られたのSigComp圧縮されたメッセージを転送します。
UDVM Cycles
UDVMサイクル
A measure of the amount of "CPU power" required to execute a UDVM instruction (the simplest UDVM instructions require a single UDVM cycle). An upper limit is placed on the number of UDVM cycles that can be used to decompress each bit in a SigComp message.
UDVM命令を実行するために必要な「CPUパワー」の量の尺度（最も単純なUDVMインストラクションは、単一のUDVMサイクルを必要とします）。上限のSigCompメッセージの各ビットを復元するために使用することができるUDVMサイクルの数に置かれます。
Decompressor Dispatcher
デコンプレッサディスパッチャ
Entity that receives SigComp messages, invokes a UDVM, and forwards the resulting decompressed messages to the application.
SigCompメッセージを受信エンティティは、UDVMを呼び出して、アプリケーションに結果の圧縮解除されたメッセージを転送します。
Endpoint
終点
One instance of an application, a SigComp layer, and a transport layer for sending and/or receiving SigComp messages.
アプリケーションのSigComp層、及びのSigCompメッセージを送信及び/又は受信するためのトランスポート層の1つのインスタンス。
Message-based Transport
メッセージベースの交通
A transport that carries data as a set of bounded messages.
有界メッセージのセットとしてデータを運ぶトランスポート。
Compartment
区画
An application-specific grouping of messages that relate to a peer endpoint. Depending on the signaling protocol, this grouping may relate to application concepts such as "session", "dialog", "connection", or "association". The application allocates state memory on a per-compartment basis, and determines when a compartment should be created or closed.
ピアエンドポイントに関連するメッセージのアプリケーション固有のグルーピング。シグナリングプロトコルに応じて、このグループ分けは、「セッション」、「ダイアログ」、「接続」、または「関連」などのアプリケーションの概念に関連してもよいです。アプリケーションごとの区画に基づいて状態メモリを割り当て、区画を作成またはクローズすべきときを判断します。
Compartment Identifier
コンパートメント識別子
An identifier (in a locally chosen format) that uniquely references a compartment.
一意コンパートメントを参照する識別子（ローカルに選択された形式で）。
SigComp
SigComp
The overall compression solution, comprising the compressor, UDVM, dispatchers and state handler.
全体的な圧縮ソリューションは、圧縮機、UDVM、ディスパッチャ状態ハンドラを含みます。
SigComp Message
SigCompのメッセージ
A message sent from the compressor dispatcher to the decompressor dispatcher. In case of a message-based transport such as UDP, a SigComp message corresponds to exactly one datagram. For a stream-based transport such as TCP, the SigComp messages are separated by reserved delimiters.
デコンプレッサディスパッチャにコンプレッサディスパッチャから送信されたメッセージ。 UDPなどのメッセージベースのトランスポートの場合、のSigCompメッセージは、1つのデータグラムに相当します。 TCPなどのストリームベースの輸送のため、のSigCompメッセージは予約デリミタによって分離されています。
Stream-based transport
ストリームベースの輸送
A transport that carries data as a continuous stream with no message boundaries.
ないメッセージ境界と連続ストリームとしてデータを運ぶトランスポート。
Transport
輸送
Mechanism for passing data between two endpoints. SigComp is capable of sending messages over a wide range of transports including TCP, UDP and SCTP [RFC-2960].
2つのエンドポイント間でデータを渡すためのメカニズム。 SigCompはTCP、UDP、およびSCTP [RFC-2960]を含むトランスポートの広い範囲を介してメッセージを送信することが可能です。
Universal Decompressor Virtual Machine (UDVM)
ユニバーサルデコンプレッサ仮想マシン（UDVM）
The machine architecture described in this document. The UDVM is used to decompress SigComp messages.
マシンのアーキテクチャは、この文書で説明します。 UDVMがSigCompのメッセージを解凍するために使用されます。
State
状態
Data saved for retrieval by later SigComp messages.
データは、後のSigCompメッセージによって取得するために保存しました。
State Handler
状態ハンドラ
Entity responsible for accessing and storing state information once permission is granted by the application.
アクセスと権限がアプリケーションによって付与された後の状態情報を格納するための責任を負うエンティティ。
State Identifier
状態識別子
Reference used to access a previously created item of state.
状態の以前に作成した項目にアクセスするための基準。
In the SigComp architecture, compression and decompression is performed at two communicating endpoints. The layout of a single endpoint is illustrated in Figure 1:
SigCompのアーキテクチャでは、圧縮及び伸張は、2つの通信エンドポイントで実行されます。単一のエンドポイントのレイアウトは、図1に示されています。
+-------------------------------------------------------------------+
| |
| Local application |
| |
+-------------------------------------------------------------------+
| ^ |
Application message & | Decompressed | | Compartment
compartment identifier | message | | identifier
| | |
+-- -- -- -- -- -- -- --|-- -- -- -- -- -- -- --|--|-- -- -- -- -- -+
v | v
| +------------------------+ +----------------------+ |
| | | |
| +--| Compressor | | Decompressor |<-+ |
| | dispatcher | | dispatcher | |
| | | | | | | |
| +------------------------+ +----------------------+ |
| | ^ ^ ^ | |
| | | | |
| | | v | | |
| | +--------------+ +---------------+ | |
| | | | | | +-------+ | v | |
| | | Compressor 1 |<----->|State 1| | +--------------+ |
| | | | | | +-------+ | | | | |
| | +--------------+ | | | Decompressor | |
| | | | State handler |<-->| | | |
| | +--------------+ | | | (UDVM) | |
| | | | | | +-------+ | | | | |
| +->| Compressor 2 |<----->|State 2| | +--------------+ |
| | | | | +-------+ | | |
| +--------------+ +---------------+ SigComp layer |
| | | |
+-| -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --|-+
| |
| SigComp SigComp |
| message message |
v |
+-------------------------------------------------------------------+
| |
| Transport layer |
| |
+-------------------------------------------------------------------+
Figure 1: High-level architectural overview of one SigComp endpoint
図1：1のSigComp終点の高レベルのアーキテクチャの概要
Note that SigComp is offered to applications as a layer between the application and the underlying transport, and so Figure 1 is an endpoint when viewed from a transport layer perspective. From the perspective of multi-hop application layer protocols however, SigComp is applied on a per-hop basis.
SigCompのは、アプリケーションと基礎となるトランスポートの間の層としてアプリケーションに提供し、トランスポート層の視点から見たときに、図1は、エンドポイントであることに注意してください。しかしながらマルチホップアプリケーション層プロトコルの観点から、SigCompのは、ホップ毎ベースで適用されます。
The SigComp layer is further decomposed into the following entities:
SigComp層は、さらに次のエンティティに分解されます。
1. Compressor dispatcher - the interface from the application. The application supplies the compressor dispatcher with an application message and a compartment identifier (see Section 3.1 for further details). The compressor dispatcher invokes a particular compressor, which returns a SigComp message to be forwarded to the remote endpoint.
1.コンプレッサディスパッチャ - アプリケーションからインターフェース。アプリケーションは、アプリケーション・メッセージとコンパートメント識別子（詳細はセクション3.1を参照）を有するコンプレッサディスパッチャに供給する。コンプレッサディスパッチャは、リモートエンドポイントに転送されるのSigCompメッセージを返す特定の圧縮機を呼び出します。
2. Decompressor dispatcher - the interface towards the application. The decompressor dispatcher receives a SigComp message and invokes an instance of the Universal Decompressor Virtual Machine (UDVM). It then forwards the resulting decompressed message to the application, which may return a compartment identifier if it wishes to allow state to be saved for the message.
2.デコンプレッサディスパッチャ - アプリケーションへのインタフェース。デコンプレッサディスパッチャはのSigCompメッセージを受信し、ユニバーサルデコンプレッサ仮想マシン（UDVM）のインスタンスを呼び出します。それは、それが状態メッセージのために保存されることを可能にすることを望む場合にコンパートメント識別子を返すことができるアプリケーション、に得られた解凍メッセージを転送します。
3. One or more compressors - the entities that convert application messages into SigComp messages. Distinct compressors are invoked on a per-compartment basis, using the compartment identifiers supplied by the application. A compressor receives an application message from the compressor dispatcher, compresses the message, and returns a SigComp message to the compressor dispatcher. Each compressor chooses a certain algorithm to encode the data (e.g., DEFLATE).
3.つ以上の圧縮機 - のSigCompメッセージにアプリケーションのメッセージを変換するエンティティ。別個の圧縮機は、アプリケーションによって供給される区画識別子を用いて、毎区画に基づいて呼び出されます。コンプレッサは、コンプレッサディスパッチャからアプリケーション・メッセージを受信するメッセージを圧縮し、圧縮機のディスパッチャへのSigCompメッセージを返します。各圧縮機は、データ（例えば、DEFLATE）を符号化するために特定のアルゴリズムを選択します。
4. UDVM - the entity that decompresses SigComp messages. Note that since SigComp can run over an unsecured transport layer, a separate instance of the UDVM is invoked on a per-message basis. However, during the decompression process the UDVM may invoke the state handler to access existing state or create new state.
4. UDVM - のSigCompメッセージを解凍するエンティティ。 SigCompのは、セキュリティで保護されていないトランスポート層の上で実行することができるので、UDVMの別々のインスタンスがメッセージごとに呼び出されることに留意されたいです。しかし、解凍処理中にUDVMは、既存の状態にアクセスするか、新しい状態を作成するために、状態ハンドラを呼び出すことができます。
5. State handler - the entity that can store and retrieve state. State is information that is stored between SigComp messages, avoiding the need to upload the data on a per-message basis. For security purposes it is only possible to create new state with the permission of the application. State creation and retrieval are further described in Chapter 6.
5.国家ハンドラ - 保存及び状態を取得することができますエンティティ。状態は、メッセージごとにデータをアップロードする必要がなくなり、のSigCompメッセージの間で保存された情報です。セキュリティ上の目的のために、アプリケーションの許可を得て、新しい状態を作成することのみ可能です。状態の作成と検索は、さらに、第6章で説明されています。
When compressing a bidirectional application protocol the choice to use SigComp can be made independently in both directions, and compression in one direction does not necessarily imply compression in the reverse direction. Moreover, even when two communicating endpoints send SigComp messages in both directions, there is no need to use the same compression algorithm in each direction.
双方向アプリケーションプロトコルを圧縮するときにSigCompを使用する選択が両方向に独立に行うことができ、1つの方向の圧縮は、必ずしも逆方向に圧縮を意味するものではありません。また、2つの通信エンドポイントが両方向でのSigCompメッセージを送信する場合であっても、各方向に同一の圧縮アルゴリズムを使用する必要はありません。
Note that a SigComp endpoint can decompress messages from multiple remote endpoints at different locations in a network, as the architecture is designed to prevent SigComp messages from one endpoint interfering with messages from a different endpoint. A consequence of this design choice is that it is difficult for a malicious user to disrupt SigComp operation by inserting false compressed messages on the transport layer.
アーキテクチャは、1つのエンドポイントが別のエンドポイントからのメッセージと干渉のSigCompメッセージを防止するように設計されているようにSigComp終点は、ネットワーク内の異なる位置に複数のリモートエンドポイントからメッセージを解凍することができることに留意されたいです。この設計上の選択の結果は、悪意のあるユーザーが、トランスポート層の上に偽の圧縮されたメッセージを挿入してのSigCompの動作が中断することが困難であるということです。
From an application perspective the SigComp layer appears as a new transport, with similar behavior to the original transport used to carry uncompressed data (for example SigComp/UDP behaves similarly to native UDP).
アプリケーションの観点からのSigComp層は、非圧縮データを伝送するために使用された元の輸送と同様の挙動を有する（例えば、SigCompの/ UDPは、ネイティブUDPと同様に挙動する）、新たなトランスポートとして現れます。
Mechanisms for discovering whether an endpoint supports SigComp are beyond the scope of this document.
エンドポイントがサポートしているかどうかのSigCompを発見するためのメカニズムはこのドキュメントの範囲を超えています。
All SigComp messages contain a prefix (the five most-significant bits of the first byte are set to one) that does not occur in UTF-8 encoded text messages [RFC-2279], so for applications which use this encoding (or ASCII encoding) it is possible to multiplex uncompressed application messages and SigComp messages on the same port. Applications can still reserve a new port specifically for SigComp however (e.g., as part of the discovery mechanism).
このエンコーディングを使用するアプリケーション（またはASCII符号化のために、すべてのSigCompメッセージは、UTF-8でエンコードされたテキストメッセージ[RFC-2279]で発生していない接頭辞（最初のバイトの5つの最上位ビットが1に設定されている）を含みます）同じポート上で圧縮されていないアプリケーションメッセージとのSigCompメッセージを多重化することが可能です。アプリケーションは、まだしかし（例えば、発見メカニズムの一部として）は、具体的にSigCompのための新たなポートを予約することができます。
If a particular endpoint wishes to be stateful then it needs to partition its decompressed messages into "compartments" under which state can be saved. SigComp relies on the application to provide this partition. So for stateful endpoints a new interface is required to the application in order to leverage the authentication mechanisms used by the application itself.
特定のエンドポイントがステートフルであることを望む場合、それは状態を保存することができ、その下「コンパートメント」にその解凍メッセージを分割する必要があります。 SigCompのは、このパーティションを提供するために、アプリケーションに依存しています。だから、ステートフルエンドポイント用に新しいインターフェイスでは、アプリケーション自体で使用される認証メカニズムを活用するために、アプリケーションに必要とされます。
When the application receives a decompressed message it maps the message to a certain compartment and supplies the compartment identifier to SigComp. Each compartment is allocated a separate compressor and a certain amount of memory to store state information, so the application must assign distinct compartments to distinct remote endpoints. However it is possible for a local endpoint to establish several compartments that relate to the same remote endpoint (this should be avoided where possible as it may waste memory and reduce the overall compression ratio, but it does not cause messages to be incorrectly decompressed). In this case, reliable stateful operation is possible only if the decompressor does not lump several messages into one compartment when the compressor expected them to be assigned different compartments.
アプリケーションが展開されたメッセージを受信した場合には、特定の区画にメッセージをマッピングし、SigCompのにコンパートメント識別子を供給する。各区画は、状態情報を格納するために別個の圧縮機と一定量のメモリが割り当てられているので、アプリケーションは、別個のリモートエンドポイントに別個の区画を割り当てる必要があります。ローカルエンドポイントが同じリモートエンドポイントに関連するいくつかの区画を確立することが可能であるが（それはメモリを無駄にし、全体的な圧縮率を減らすことができるので、これは可能な限り避けるべきであるが、それは、メッセージが間違って解凍されることはありません）。この場合には、信頼性の高いステートフルな操作は、圧縮機がそれらを異なる区画に割り当てられることが期待とき解凍装置はつの区画に複数のメッセージを塊ない場合にのみ可能です。
The exact format of the compartment identifier is unimportant provided that different identifiers are given to different compartments.
コンパートメント識別子の正確なフォーマットは、異なる識別子が異なる区画に付与されていれば重要ではありません。
Applications that wish to communicate using SigComp in a stateful fashion should use an authentication mechanism to securely map decompressed messages to compartment identifiers. They should also agree on any limits to the lifetime of a compartment, to avoid the case where an endpoint accesses state information that has already been deleted.
ステートフルな方法でのSigCompを使用して通信したいアプリケーションは、しっかりとコンパートメント識別子に解凍されたメッセージをマッピングするための認証メカニズムを使用する必要があります。彼らはまた、エンドポイントがすでに削除されている状態情報にアクセスする場合を避けるために、コンパートメントの寿命への制限に同意する必要があります。
If a signaling protocol sends SigComp messages in both directions and there is a one-to-one relationship between the compartments established by the applications on both ends ("peer compartments"), the two endpoints can cooperate more closely. In this case, it is possible to send feedback information that monitors the behavior of an endpoint and helps to improve the overall compression ratio. SigComp performs feedback on a request/response basis, so a compressor makes a feedback request and receives some feedback data in return. The procedure for requesting and returning feedback in SigComp is illustrated in Figure 2:
シグナリングプロトコルは、両方向にのSigCompメッセージを送信し、両端（「ピア区画」）上のアプリケーションによって確立された区画との間に1対1の関係が存在する場合、2つのエンドポイントは、より密接に協力することができます。この場合、エンドポイントの動作を監視し、全体の圧縮率を向上させるのに役立つフィードバック情報を送信することが可能です。 SigCompのは、要求/応答に基づいてフィードバックを行い、圧縮機は、フィードバック要求を行い、見返りにいくつかのフィードバックデータを受信します。 SigCompのフィードバックを要求して戻すための手順は、図2に示されています。
+---------------------+ +---------------------+
| +-----------------+ | | +-----------------+ |
-->| Compressor |------------------------>| UDVM |<->
| | sending to B | | SigComp message | | | |2
| +-----------------+ | requesting feedback | +-----------------+ |
| ^ 1,9 | | 3 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | State | | | | State | |
| | handler | | | | handler | |
| +-----------------+ | | +-----------------+ |
| ^ 8 | | 4 | |
| | | | v |
| +-----------------+ | | +-----------------+ |
| | UDVM | | | | Compressor | |
<->| |<------------------------| sending to A |<--
6| +-----------------+ | SigComp message | +-----------------+ |
| 7 | returning feedback | 5 |
| Endpoint A | | Endpoint B |
+---------------------+ +---------------------+
Figure 2: Steps involved in the transmission of feedback data
図2：フィードバックデータの伝送に関与するステップ
The dispatchers, the application and the transport layer are omitted from the diagram for clarity. Note that the decompressed messages pass via the decompressor dispatcher to the application; moreover the SigComp messages transmitted from the compressor to the remote UDVM are sent via first the compressor dispatcher, followed by the transport layer and finally the decompressor dispatcher.
ディスパッチャ、アプリケーションおよびトランスポート層は、明瞭化のため図から省略されています。解凍メッセージがアプリケーションにデコンプレッサディスパッチャを介して通過することに留意されたいです。また、リモートUDVMに圧縮機から送信されたSigCompメッセージは、トランスポート層、最後にデコンプレッサディスパッチャに続く第1圧縮機ディスパッチャを介して送られます。
The steps for requesting and returning feedback data are described in more detail below:
フィードバックデータを要求して返すための手順は、以下でより詳細に説明されています。
1. The compressor that sends messages to Endpoint B piggybacks a feedback request onto a SigComp message.
1.エンドポイントBにメッセージを送信するコンプレッサはのSigCompメッセージへのフィードバックの要求をピギーバック。
2. When the application receives the decompressed message, it may return the compartment identifier for the message.
アプリケーションが展開されたメッセージを受信したとき2.、それはメッセージのコンパートメント識別子を返すことができます。
3. The UDVM in Endpoint B forwards the requested feedback data to the state handler.
3.エンドポイントBにおけるUDVMは状態ハンドラに要求されたフィードバックデータを転送します。
4. If the UDVM can supply a valid compartment identifier, then the state handler forwards the feedback data to the appropriate compressor (namely the compressor sending to Endpoint A).
4. UDVMが有効なコンパートメント識別子を供給することができた場合は、状態ハンドラは適切な圧縮機（エンドポイントAに送信つまり圧縮機）にフィードバックデータを転送します。
5. The compressor returns the requested feedback data to Endpoint A piggybacked onto a SigComp message.
前記圧縮機は、のSigCompメッセージにピギーバックエンドポイントAに要求されたフィードバックデータを返します。
6. When the application receives the decompressed message, it may return the compartment identifier for the message.
アプリケーションが展開されたメッセージを受信すると6は、それがメッセージのコンパートメント識別子を返すことができます。
7. The UDVM in Endpoint A forwards the returned feedback data to the state handler.
7.エンドポイントAにおけるUDVMは状態ハンドラに返されたフィードバックデータを転送します。
8. If the UDVM can supply a valid compartment identifier, then the state handler forwards the feedback data to the appropriate compressor (namely the compressor sending to Endpoint B).
8. UDVMが有効なコンパートメント識別子を供給することができた場合は、状態ハンドラは適切な圧縮機（エンドポイントBへの送信、すなわち圧縮機）にフィードバックデータを転送します。
The detailed role played by each entity in the transmission of feedback data is explained in subsequent chapters.
フィードバックデータの伝送において各エンティティによって果たされる役割の詳細は、後の章で説明されています。
An advantage of using a virtual machine for decompression is that almost all of the implementation flexibility lies in the SigComp compressors. When receiving SigComp messages an endpoint generally behaves in a predictable manner.
解凍用の仮想マシンを使用する利点は、ほとんどすべての実装の柔軟性のがSigCompのコンプレッサーにあるということです。 SigCompメッセージを受信した場合、エンドポイントは、一般的に予測可能な方法で動作します。
Note however that endpoints implementing SigComp will typically have a wide range of capabilities, each offering a different amount of working memory, processing power etc. In order to support this wide variation in endpoint capabilities, the following parameters are provided to modify SigComp behavior when receiving SigComp messages:
SigCompのを実装するエンドポイントは、典型的には、エンドポイントの能力のこの広い変化をサポートするために、各ワーキングメモリ、処理能力などの異なる量を提供し、機能の広い範囲を持つことになり、以下のパラメータを受信したときのSigCompの動作を変更するために設けられていることに注意してくださいSigCompのメッセージ：
decompression_memory_size state_memory_size cycles_per_bit SigComp_version locally available state (a set containing 0 or more state items)
decompression_memory_size state_memory_size cycles_per_bit SigComp_version局所的に利用可能な状態（0又はそれ以上の状態のアイテムを含むセット）
Each parameter has a minimum value that MUST be offered by all receiving SigComp endpoints. Moreover, endpoints MAY offer additional resources if available; these resources can be advertised to remote endpoints using the SigComp feedback mechanism.
各パラメータは、すべての受信のSigCompエンドポイントによって提供されなければならない最小値を持っています。また、エンドポイントが利用可能な場合、追加のリソースを提供することがあります。これらのリソースはのSigCompフィードバックメカニズムを使用してリモートエンドポイントにアドバタイズすることができます。
Particular applications may also agree a-priori to offer additional resources as mandatory (e.g., SigComp for SIP offers a dictionary of common SIP phrases as a mandatory state item).
特定のアプリケーションは、（例えば、SIPのためのSigCompは必須状態項目などの一般的なSIPフレーズの辞書を提供しています）必須として追加のリソースを提供するために事前に同意することができます。
Each of the SigComp parameters is described in greater detail below.
SigCompのパラメータの各々は、以下により詳細に記載されています。
The decompression_memory_size parameter specifies the amount of memory available to decompress one SigComp message. (Note that the term "amount of memory" is used on a conceptual level in order to specify decompressor behavior and allow resource planning on the side of the compressor -- an implementation could require additional, bounded amounts of actual memory resources or could even organize its memory in a completely different way as long as this does not cause decompression failures where the conceptual model would not.) A portion of this memory is used to buffer a SigComp message before it is decompressed; the remainder is given to the UDVM. Note that the memory is allocated on a per-message basis and can be reclaimed after the message has been decompressed. All endpoints implementing SigComp MUST offer a decompression_memory_size of at least 2048 bytes.
decompression_memory_sizeパラメータが1つのSigCompメッセージを解凍するために利用可能なメモリの量を指定します。実際のメモリリソースの量を境界あるいは編成ができ、実装の追加の必要ができた - （用語「メモリの量は、」デコンプレッサの動作を指定すると、圧縮機側のリソース計画を可能にするために、概念レベルで使用されることに注意してください。限り、これは概念モデル）は、このメモリの一部は、それが減圧される前のSigCompメッセージをバッファリングするために使用されないであろう減圧障害を引き起こさないように、完全に異なる方法でそのメモリ。残りはUDVMに与えられます。メモリは、メッセージごとに割り当てられ、メッセージは、解凍された後に再利用することができることに留意されたいです。 SigCompを実装するすべてのエンドポイントは、少なくとも2048バイトのdecompression_memory_sizeを提供しなければなりません。
The state_memory_size parameter specifies the number of bytes offered to a particular compartment for the creation of state. This parameter is set to 0 if the endpoint is stateless.
state_memory_sizeパラメータは、状態を作成するための特定の区画に提供されるバイトの数を指定します。エンドポイントがステートレスである場合、このパラメータは0に設定されています。
Unlike the other SigComp parameters, the state_memory_size is offered on a per-compartment basis and may vary for different compartments. The memory for a compartment is reclaimed when the application determines that the compartment is no longer required.
他のSigCompパラメータとは異なり、state_memory_sizeごとの区画に基づいて提供され、異なる区画のために変化してもよいです。アプリケーションは、区画がもはや必要とされていると判断しない場合に区画するためのメモリが再利用されます。
The cycles_per_bit parameter specifies the number of "UDVM cycles" available to decompress each bit in a SigComp message. Executing a UDVM instruction requires a certain number of UDVM cycles; a complete list of UDVM instructions and their cost in UDVM cycles can be found in Chapter 9. An endpoint MUST offer a minimum of 16 cycles_per_bit.
cycles_per_bitパラメータは、のSigCompメッセージの各ビットを復元するために利用可能な「UDVMサイクル」の数を指定します。 UDVM命令を実行すると、UDVMサイクルの特定の数を必要とします。 UDVMサイクルにおけるUDVM命令とそのコストの完全なリストは、エンドポイントが16 cycles_per_bitの最小値を提供しなければなりません。第9章に記載されています。
Each of the three parameter values MUST be chosen from the limited set given below, so that the parameters can be efficiently encoded for transmission using the SigComp feedback mechanism.
パラメータを効率的にSigCompフィードバックメカニズムを用いて送信するために符号化することができるように、3つのパラメータ値の各々は、下記の限定されたセットから選択されなければなりません。
The cycles_per_bit parameter is encoded using 2 bits, whilst the decompression_memory_size and state_memory_size are both encoded using 3 bits. The bit encodings and their corresponding values are as follows:
decompression_memory_sizeとstate_memory_sizeの両方の3ビットを用いて符号化される一方cycles_per_bitパラメータは、2ビットを用いて符号化されます。次のようにビットエンコーディングとそれに対応する値は次のとおりです。
Encoding: cycles_per_bit: Encoding: state_memory_size (bytes):
エンコード：cycles_per_bit：エンコーディング：state_memory_size（バイト）：
00 16 000 0 01 32 001 2048 10 64 010 4096 11 128 011 8192 100 16384 101 32768 110 65536 111 131072
００ １６ ０００ ０ ０１ ３２ ００１ ２０４８ １０ ６４ ０１０ ４０９６ １１ １２８ ０１１ ８１９２ １００ １６３８４ １０１ ３２７６８ １１０ ６５５３６ １１１ １３１０７２
The decompression_memory_size is encoded in the same manner as the state_memory_size, except that the bit pattern 000 cannot be used (as an endpoint cannot offer a decompression_memory_size of 0 bytes).
decompression_memory_sizeは（エンドポイントが0バイトのdecompression_memory_sizeを提供することができないように）ビットパターン000を用いることができないことを除いて、state_memory_sizeと同様に符号化されます。
The SigComp_version parameter specifies whether only the basic version of SigComp is available, or whether an upgraded version is available offering additional instructions etc. Within the UDVM, it is available as a 2-byte value, generated by zero-extending the 1- byte SigComp_version parameter (i.e., the first byte of the 2-byte value is always zero).
SigComp_versionパラメータは、SigCompの唯一の基本的なバージョンが利用可能であるか、またはアップグレードされたバージョンは、UDVM内等の追加の指示を提供利用可能であるかどうか、それがゼロに延びる1-バイトSigComp_versionをによって生成され、2バイトの値として利用可能であるかどうかを指定しますパラメータ（すなわち、2バイトの値の最初のバイトは常にゼロです）。
The basic version of SigComp is Version 0x01, which is the version described in this document.
SigCompのの基本的なバージョンは、この文書に記載されているバージョンであるバージョン0x01で、です。
To ensure backwards compatibility, if a SigComp message is successfully decompressed by Version 0x01 of SigComp then it will be successfully decompressed on upgraded versions. Similarly, if the message triggers a manual decompression failure (see Section 8.7), then it will also continue to do so.
SigCompメッセージが正常にSigCompのバージョン0x01ので減圧された場合に下位互換性を確保するために、それが正常にアップグレードバージョンで解凍されます。メッセージは（8.7節を参照）を手動解凍の失敗をトリガした場合同様に、それもそうしていきます。
However, messages that cause an unexpected decompression failure on Version 0x01 of SigComp may be successfully decompressed by upgraded versions.
しかし、SigCompのバージョン0x01の上の予期せぬ展開の失敗の原因となるメッセージが正常にアップグレードバージョンで解凍することができます。
The simplest way to upgrade SigComp in a backwards-compatible manner is to add additional UDVM instructions, as this will not affect the decompression of SigComp messages compatible with Version 0x01. Reserved addresses in the UDVM memory (Useful Values, see Section 7.2) may also be assigned values in future versions of SigComp.
このバージョンは0x01と互換性のSigCompメッセージの解凍には影響しませんよう後方互換性のある方法でのSigCompをアップグレードする最も簡単な方法は、追加のUDVM命令を追加することです。 UDVMメモリの予約アドレス（有用な値は、セクション7.2を参照）も、SigCompの将来のバージョンの値を割り当てることができます。
A SigComp state item is an item of data that is retained between SigComp messages. State items can be retrieved and loaded into the UDVM memory as part of the decompression process, often significantly improving the compression ratio as the same information does not have to be uploaded on a per-message basis.
SigCompの状態項目がのSigCompメッセージの間に保持されるデータの項目です。同じ情報は、メッセージごとにアップロードする必要がないような状態のアイテムは、しばしば著しく圧縮率を向上させる、伸張処理の一部として、UDVMメモリに取り出され、ロードすることができます。
Each endpoint maintains a set of state items where every item is composed of the following information:
各エンドポイントは、すべてのアイテムは、以下の情報から構成されている状態のアイテムのセットを維持します。
Name: Type of data:
名前：データの種類：
state_identifier 20-byte value state_length 2-byte value state_address 2-byte value state_instruction 2-byte value minimum_access_length 2-byte value from 6 to 20 inclusive state_value String of state_length consecutive bytes
state_length連続バイトの6〜20の包括state_value列からstate_identifier 20バイト値state_length 2バイト値state_address 2バイト値state_instruction 2バイト値minimum_access_length 2バイトの値
State items are typically created at an endpoint upon successful decompression of a SigComp message. The remote compressor sending the message makes a state creation request by invoking the appropriate UDVM instruction, and the state is saved once permission is granted by the application.
状態の項目は、通常のSigCompメッセージの解凍の成功時にエンドポイントで作成されます。メッセージを送信するリモートコンプレッサーは、適切なUDVM命令を呼び出すことにより、状態の作成要求を行い、許可がアプリケーションによって付与された後の状態が保存されます。
However, an endpoint MAY also wish to offer a set of locally available state items that have not been uploaded as part of a SigComp message. For example it might offer well-known decompression algorithms, dictionaries of common phrases used in a specific signaling protocol, etc.
しかし、エンドポイントものSigCompメッセージの一部としてアップロードされていない局所的に利用可能な状態のアイテムのセットを提供することを望むかもしれません。例えば、それは等、周知の解凍アルゴリズム、特定のシグナリングプロトコルで使用される一般的なフレーズの辞書を提供するかもしれません
Since these state items are established locally without input from a remote endpoint, they are most useful if publicly documented so that a wide collection of remote endpoints can determine the data contained in each state item and how it may be used. Further Internet Documents and RFCs may be published to describe particular locally available state items.
これらの状態の項目がリモートエンドポイントからの入力なしでローカルに確立されているので、それらは公にリモートエンドポイントの広いコレクションが各状態の項目に含まれるデータを決定することができるように文書化され、それがどのように使用することができる場合に最も有用です。また、インターネットドキュメントとRFCは、特定の局所的に利用可能な状態の項目を記述するために公開することができます。
Although there are no locally available state items that are mandatory for every SigComp endpoint, certain state items can be made mandatory in a specific environment (e.g., the dictionary of common phrases for a specific signaling protocol could be made mandatory for that signaling protocol's usage of SigComp). Also, remote endpoints can indicate their interest in receiving a list of some of the state items available locally at an endpoint using the SigComp feedback mechanism.
すべてのSigCompのエンドポイントのために必須で利用可能な状態の項目が何もローカルにありませんが、特定の状態の項目は、特定の環境で必須にすることができます（例えば、特定のシグナリングプロトコルのための共通のフレーズの辞書はのシグナリングプロトコルの使用のための必須作ることができますSigComp）。また、リモートエンドポイントはのSigCompフィードバックメカニズムを使用してエンドポイントでローカルに利用可能な状態の項目のいくつかのリストを受け取ることに関心を示すことができます。
It is a matter of local decision for an endpoint what items of locally available state it advertises; this decision has no influence on interoperability, but may increase or decrease the efficiency of the compression achievable between the endpoints.
それがアドバタイズ何局所的に利用可能な状態の項目エンドポイントのローカルの決定の問題です。この決定は、相互運用性に影響を及ぼさないが、増加またはエンドポイント間で達成できる圧縮の効率が低下することがあります。
This chapter defines the behavior of the compressor and decompressor dispatcher. The function of these entities is to provide an interface between SigComp and its environment, minimizing the effort needed to integrate SigComp into an existing protocol stack.
この章では、コンプレッサとデコンプレッサディスパッチャの動作を定義します。これらの事業体の機能は、既存のプロトコルスタックへのSigCompを統合するために必要な労力を最小限に抑え、SigCompのとその環境との間のインターフェイスを提供することです。
The compressor dispatcher receives messages from the application and passes the compressed version of each message to the transport layer.
コンプレッサディスパッチャは、アプリケーションからメッセージを受信し、トランスポート層に各メッセージの圧縮バージョンを渡します。
Note that SigComp invokes compressors on a per-compartment basis, so when the application provides a message to be compressed it must also provide a compartment identifier. The compressor dispatcher forwards the application message to the correct compressor based on the compartment identifier (invoking a new compressor if a new compartment identifier is encountered). The compressor returns a SigComp message that can be passed to the transport layer.
アプリケーションはまた、コンパートメント識別子を提供する必要があり、圧縮されるべきメッセージを提供するようにするとき、のSigCompごとの区画に基づいて圧縮機を起動することに注意してください。コンプレッサディスパッチャは、コンパートメント識別子（新しいコンパートメント識別子に遭遇した場合、新しい圧縮機を起動する）に基づいて、正しい圧縮機にアプリケーションメッセージを転送します。圧縮機は、トランスポート層に渡すことができるのSigCompメッセージを返します。
Additionally, the application should indicate to the compressor dispatcher when it wishes to close a particular compartment, so that the resources taken by the corresponding compressor can be reclaimed.
対応する圧縮機によって撮影されたリソースを再利用することができるように、それは、特定のコンパートメントを閉じたい場合に加えて、アプリケーションは、コンプレッサディスパッチャに示すべきです。
The decompressor dispatcher receives messages from the transport layer and passes the decompressed version of each message to the application.
デコンプレッサディスパッチャは、トランスポート層からメッセージを受信し、アプリケーションに各メッセージの圧縮解除バージョンを渡します。
To ensure that SigComp can run over an unsecured transport layer, the decompressor dispatcher invokes a new instance of the UDVM for each new SigComp message. Resources for the UDVM are released as soon as the message has been decompressed.
SigCompのは、セキュリティで保護されていない輸送層上に実行できることを保証するために、デコンプレッサディスパッチャは、各新規のSigCompメッセージのUDVMの新しいインスタンスを呼び出します。 UDVMのためのリソースは、すぐにメッセージが解凍されたとしてリリースされています。
The dispatcher MUST NOT make more than one SigComp message available to a given instance of the UDVM. In particular, the dispatcher MUST NOT concatenate two SigComp messages to form a single message.
ディスパッチャは、UDVMの特定のインスタンスに複数のSigCompメッセージを利用できるようにはなりません。特に、ディスパッチャは、単一のメッセージを形成するために2つのSigCompメッセージを連結してはいけません。
Once the UDVM has been invoked it is initialized using the SigComp message of Chapter 7. The message is then decompressed by the UDVM, returned to the decompressor dispatcher, and passed on to the receiving application. Note that the UDVM has no awareness of whether the underlying transport is message-based or stream-based, and so it always outputs decompressed data as a stream. It is the responsibility of the dispatcher to provide the decompressed message to the application in the expected form (i.e., as a stream or as a distinct, bounded message). The dispatcher knows that the end of a decompressed message has been reached when the UDVM instruction END-MESSAGE is invoked (see Section 9.4.9).
UDVMは、それがその後、UDVMで減圧され、第7章メッセージののSigCompメッセージを使用して初期化されて呼び出された後、デコンプレッサディスパッチャに戻り、受信側のアプリケーションに渡さ。 UDVMは、基礎となるトランスポートがメッセージベースまたはストリームベースであり、そしてそれは常にストリームとして伸張データを出力するかどうか全く意識を持っていないことに留意されたいです。予想される形態（すなわち、ストリームとして、または別個の、境界メッセージなど）に応用まで減圧メッセージを提供するために、ディスパッチャの責任です。ディスパッチャはUDVM命令END-MESSAGEが呼び出されたときに解凍メッセージの最後に（セクション9.4.9を参照）に達したことを知っています。
For a stream-based transport, two strategies are therefore possible for the decompressor dispatcher:
ストリームベースの輸送のために、2つの戦略は、デコンプレッサディスパッチャのためにことが可能です。
1) The dispatcher collects a complete SigComp message and then invokes the UDVM. The advantage is that, even in implementations that have multiple incoming compressed streams, only one instance of the UDVM is ever required.
1）ディスパッチャは、完全にSigCompメッセージを収集した後、UDVMを呼び出します。利点はさらに、複数の着信圧縮ストリームを有する実施態様では、UDVMのインスタンスが1つだけ今までに必要とされる、ということです。
2) The dispatcher collects the SigComp header (see Section 7) and invokes the UDVM; the UDVM stays active while the rest of the message arrives. The advantage is that there is no need to buffer up the rest of the message; the message can be decompressed as it arrives, and any decompressed output can be relayed to the application immediately.
2）ディスパッチャは、SigCompのヘッダ（セクション7参照）を収集し、UDVMを呼び出します。メッセージの残りの部分が到着する間、UDVMはアクティブのままです。利点は、メッセージの残りの部分をバッファリングする必要がないということです。メッセージは、それが到着すると解凍することができ、任意の解凍出力がすぐにアプリケーションに中継することができます。
In general, which of the strategies is used is an implementation choice.
戦略の使用され、一般的には実装の選択肢があります。
However, the compressor may want to take advantage of strategy 2 by expecting that some of the application message is passed on to the application before the SigComp message is terminated, e.g., by keeping the UDVM active while expecting the application to continuously receive decompressed output. This approach ("continuous mode") invalidates some assumptions of the SigComp security model and can only be used if the transport itself can provide the required protection against denial of service attacks. Also, since only strategy 2 works in this approach, the use of continuous mode requires previous agreement between the two endpoints.
しかし、圧縮機はのSigCompメッセージが終了する前に、連続的に解凍出力を受信するためのアプリケーションを期待しながら、アプリケーション・メッセージのいくつかがアクティブUDVMを維持することによって、例えば、アプリケーションに渡されることを期待することによって戦略2を利用することができます。このアプローチ（「連続モード」）のSigCompセキュリティモデルのいくつかの仮定を無効にし、輸送自体は、サービス拒否攻撃に対する必要な保護を提供することができる場合にのみ使用することができます。また、唯一の戦略このアプローチでは2つの作品以来、連続モードの使用は2つのエンドポイント間の以前の契約が必要です。
For a stream-based transport, the dispatcher delimits messages by parsing the compressed data stream for instances of 0xFF and taking the following actions:
ストリームベースの輸送のために、ディスパッチャは0xFFでのインスタンスの圧縮データストリームを解析し、次のアクションを取ることによって、メッセージを区切ります：
Occurs in data stream: Action:
データストリームで発生します。アクション：
0xFF 00 one 0xFF byte in the data stream 0xFF 01 same, but the next byte is quoted (could be another 0xFF) : : 0xFF 7F same, but the next 127 bytes are quoted 0xFF 80 to 0xFF FE (reserved for future standardization) 0xFF FF end of SigComp message
0xFFの00は、データの1つの0xFFのバイトが0xFFの01同じストリームが、次のバイトが引用されている（別の0xFFであってもよい）：0xFFの7Fは同じ、しかし次の127のバイトは、0xFFの（将来の標準化のために予約）の0xFF FEには0xFF 80を引用していますSigCompメッセージのFFの終わり
The combinations 0xFF01 to 0xFF7F are useful to limit the worst case expansion of the record marking scheme: the 1 (0xFF01) to 127 (0xFF7F) bytes following the byte combination are copied literally by the decompressor without taking any special action on 0xFF. (Note that 0xFF00 is just a special case of this, where zero following bytes are copied literally.)
1（0xFF01）127（0xFF7F）バイトには0xFFに特別なアクションを取ることなく、デコンプレッサによって文字通りコピーされるバイトの組み合わせ次0xFF7Fの組み合わせ0xFF01レコードマーキングスキームの最悪の場合の拡張を制限するのに有用です。 （は0xFF00ゼロ次のバイトが文字通りコピーされ、このだけの特別な場合であることに注意してください。）
In UDVM version 0x01, any occurrence of the combinations 0xFF80 to 0xFFFE that are not protected by quoting causes decompression failure; the decompressor SHOULD close the stream-based transport in this case.
UDVMバージョンが0x01では、引用によって保護されていない0xFFFEというに組み合わせ0xFF80の発生が伸張失敗を引き起こします。減圧装置は、この場合のストリームベースのトランスポートを閉じてください。
Upon receiving a decompressed message the application may supply the dispatcher with a compartment identifier. Supplying this identifier grants permission for the following:
解凍メッセージを受信するアプリケーションは、コンパートメント識別子とディスパッチャを供給することができます。以下は、この識別子が許可を与えるを供給：
1. Items of state accompanying the decompressed message can be saved using the state memory reserved for the specified compartment.
減圧メッセージに付随する状態の1項目は、指定された区画のために予約状態メモリを使用して保存することができます。
2. The feedback data accompanying the decompressed message can be trusted sufficiently that it can be used when sending SigComp messages that relate to the compressor's equivalent for the compartment.
2.解凍メッセージに付随するフィードバックデータは区画する圧縮機の等価に関連のSigCompメッセージを送信するときに使用することができることを十分に信頼することができます。
The dispatcher passes the compartment identifier to the UDVM, where it is used as per the END-MESSAGE instruction (see Section 9.4.9).
ディスパッチャは、それがEND-MESSAGE指示に従って使用されるUDVMにコンパートメント識別子を渡す（セクション9.4.9を参照）。
The application uses a suitable authentication mechanism to determine whether the decompressed message belongs to a legitimate compartment or not. If the application fails to authenticate the message with sufficient confidence to allow state to be saved or feedback data to be trusted, it supplies a "no valid compartment" error to the dispatcher and the UDVM is terminated without creating any state or forwarding any feedback data.
アプリケーションが展開されたメッセージが正当な区画に属しているか否かを決定するために、適切な認証メカニズムを使用します。アプリケーションは状態を保存するか、フィードバックデータが信頼できるようにするために十分な自信を持ってメッセージを認証するために失敗した場合は、ディスパッチャに「ノー有効なコンパートメント」エラーを供給し、UDVMは、任意の状態を作成したり、任意のフィードバックデータを転送せずに終了されます。
An important feature of SigComp is that decompression functionality is provided by a Universal Decompressor Virtual Machine (UDVM). This means that the compressor can choose any algorithm to generate compressed SigComp messages, and then upload bytecode for the corresponding decompression algorithm to the UDVM as part of the SigComp message.
SigCompのの重要な特徴は、解凍機能は、ユニバーサルデコンプレッサ仮想マシン（UDVM）によって提供されることです。これは、圧縮機は、圧縮のSigCompメッセージを生成するために、任意のアルゴリズムを選択し、その後のSigCompメッセージの一部としてUDVMに対応する解凍アルゴリズムのためのバイトコードをアップロードすることができることを意味します。
To help with the implementation and testing of a SigComp endpoint, further Internet Documents and RFCs may be published to describe particular compression algorithms.
SigCompのエンドポイントの実装とテストを支援するために、さらにインターネットドキュメントとRFCは、特定の圧縮アルゴリズムを記述するために公開することができます。
The overall requirement placed on the compressor is that of transparency, i.e., the compressor MUST NOT send bytecode which causes the UDVM to incorrectly decompress a given SigComp message.
圧縮機上に配置された全体的な要件は、透明性、すなわち、圧縮機が誤っ所与のSigCompメッセージを解凍するUDVMを引き起こすバイトコードを送ってはならないということです。
The following more specific requirements are also placed on the compressor (they can be considered particular instances of the transparency requirement):
以下のより具体的な要件も（それらは透明度の要件の特定のインスタンスと考えることができる）は、圧縮機に配置されています。
1. For robustness, it is recommended that the compressor supply some form of integrity check (not necessarily of cryptographic strength) over the application message to ensure that successful decompression has occurred. A UDVM instruction is provided for CRC verification; also, another instruction can be used to compute a SHA-1 cryptographic hash.
ロバスト性のために1、それが圧縮供給成功減圧が発生したことを確実にするためにアプリケーション・メッセージ上の整合性チェック（必ずしも暗号強度の）何らかの形のことをお勧めします。 UDVM命令はCRC検証するために設けられています。また、他の命令は、SHA-1暗号化ハッシュを計算するために使用することができます。
2. The compressor MUST ensure that the message can be decompressed using the resources available at the remote endpoint.
2.圧縮機は、メッセージがリモートエンドポイントに利用可能なリソースを使用して解凍することができることを確認しなければなりません。
3. If the transport is message-based, then the compressor MUST map each application message to exactly one SigComp message.
3.トランスポートがメッセージベースである場合、圧縮機は、厳密に1つのSigCompメッセージに各アプリケーションメッセージをマッピングする必要があります。
4. If the transport is stream-based but the application defines its own internal message boundaries, then the compressor SHOULD map each application message to exactly one SigComp message.
前記トランスポートストリームベースであるが、アプリケーションが独自の内部メッセージの境界を定義する場合、次に圧縮機は、厳密に1つのSigCompメッセージに各アプリケーションメッセージをマッピングすべきです。
Message boundaries should be preserved over a stream-based transport so that accidental or malicious damage to one SigComp message does not affect the decompression of subsequent messages.
1つのSigCompメッセージの偶発的または悪意的な破損は、後続のメッセージの解凍には影響を与えないように、メッセージの境界は、ストリームベースのトランスポート上で保存されるべきです。
Additionally, if the state handler passes some requested feedback to the compressor, then it SHOULD be returned in the next SigComp message generated by the compressor (unless the state handler passes some newer requested feedback before the older feedback has been sent, in which case the older feedback is deleted).
状態ハンドラが通過する場合に加えて、いくつかは、圧縮機へのフィードバックを要求し、それは、圧縮機（によって生成される次のSigCompメッセージに返されるべきである状態ハンドラは、古いフィードバックが送信される前にいくつかの新しい要求されたフィードバックを通過しない限り、その場合に古いフィードバック）が削除されます。
If present, the requested feedback item SHOULD be copied unmodified into the returned_feedback_item field provided in the SigComp message. Note that there is no need to transmit any requested feedback item more than once.
存在する場合、要求されたフィードバック項目はのSigCompメッセージに設けられreturned_feedback_itemフィールドに修飾されていないコピーする必要があります。複数回任意の要求されたフィードバック項目を送信する必要がないことに注意してください。
The compressor SHOULD also upload the local SigComp parameters to the remote endpoint, unless the endpoint has indicated that it does not wish to receive these parameters or the compressor determines that the parameters have already successfully arrived (see Section 5.1 for details of how this can be achieved). The SigComp parameters are uploaded to the UDVM memory at the remote endpoint as described in Section 9.4.9.
エンドポイントが、それは、これらのパラメータを受け取りたくないことを示しているか、または圧縮機のパラメータがすでに正常（これがいかにの詳細については、セクション5.1を参照してください到着したと判断しない限り、コンプレッサーはまた、リモートエンドポイントにローカルのSigCompパラメータをアップロードしてください達成）。セクション9.4.9で説明したようにSigCompパラメータは、リモートエンドポイントでUDVMメモリにアップロードされています。
A compressor MUST be certain that all of the data needed to decompress a SigComp message is available at the receiving endpoint. One way to ensure this is to send all of the needed information in every SigComp message (including bytecode to decompress the message). However, the compression ratio for this method will be relatively low.
圧縮機は、のSigCompメッセージを解凍するために必要なすべてのデータが受信エンドポイントで利用可能であることを特定していなければなりません。これを確保するための一つの方法は、（メッセージを解凍するためにバイトコードを含む）すべてのSigCompのメッセージに必要なすべての情報を送信することです。しかし、この方法での圧縮率は比較的低くなります。
To obtain the best overall compression ratio the compressor needs to request the creation of new state items at the remote endpoint. The information saved in these state items can then be accessed by later SigComp messages, avoiding the need to upload the data on a per-message basis.
最高の全体的な圧縮比を得るためには、コンプレッサは、リモートエンドポイントで新しい状態アイテムの作成を要求する必要があります。これらの状態の項目に保存された情報は、メッセージごとにデータをアップロードする必要がなくなり、後のSigCompメッセージによってアクセスすることができます。
Before the compressor can access saved state however, it must ensure that the SigComp message carrying the state creation request arrived successfully at the receiving endpoint. For a reliable transport (e.g., TCP or SCTP) this is guaranteed. For an unreliable transport however, the compressor must provide a suitable mechanism itself (see [RFC-3321] for further details).
コンプレッサーは、しかし、保存された状態にアクセスする前に、それは国家の作成要求を運ぶのSigCompメッセージを受信したエンドポイントで成功裏に到着したことを確認する必要があります。信頼性の高いトランスポート（たとえば、TCPまたはSCTP）については、これは保証されています。しかしながら、信頼性の低いトランスポートのために、圧縮機（詳細については、[RFC-3321]を参照）の適切な機構自体を提供しなければなりません。
The compressor must also ensure that the state item it wishes to access has not been rejected due to a lack of state memory. This can be accomplished by checking the state_memory_size parameter using the SigComp feedback mechanism (see Section 9.4.9 for further details).
コンプレッサーはまた、アクセスしようとする状態項目が原因ステートメモリ不足に拒否されていないことを確認する必要があります。これは、SigCompのフィードバック機構（詳細については、セクション9.4.9を参照）を使用してstate_memory_sizeパラメータをチェックすることによって達成することができます。
The compressor SHOULD make every effort to successfully compress an application message, but in certain cases this might not be possible (particularly if resources are scarce at the receiving endpoint). In this case a "compression failure" is called.
（リソースが受信エンドポイントで不足している場合は特に）の圧縮機が正常にアプリケーションメッセージを圧縮するためにあらゆる努力をする必要がありますが、特定のケースではこれができない場合があります。この場合、「圧縮の失敗を」と呼ばれています。
If a compression failure occurs then the compressor informs the dispatcher and takes no further action. The dispatcher MUST report this failure to the application so that it can try other methods to deliver the message.
圧縮障害が発生した場合、圧縮機は、ディスパッチャに通知し、さらなるアクションを取りません。それがメッセージを配信するために他の方法を試すことができるようにディスパッチャは、アプリケーションにこの失敗を報告しなければなりません。
This chapter defines the behavior of the SigComp state handler. The function of the state handler is to retain information between received SigComp messages; it is the only SigComp entity that is capable of this function, and so it is of particular importance from a security perspective.
この章では、SigCompの状態ハンドラの動作を定義します。状態ハンドラの機能は、受信されたのSigCompメッセージの間で情報を保持することです。それは、この機能が可能な唯一のSigCompエンティティであり、そしてそれは、セキュリティの観点から特に重要です。
To provide security against the malicious insertion or modification of SigComp messages, a separate instance of the UDVM is invoked to decompress each message. This ensures that damaged SigComp messages do not prevent the successful decompression of subsequent valid messages.
悪意のある挿入またはのSigCompメッセージの変更に対するセキュリティを提供するために、UDVMの別のインスタンスは、各メッセージを復元するために呼び出されます。これは、破損したSigCompメッセージは、その後の有効なメッセージの解凍の成功を妨げないことを保証します。
Note, however, that the overall compression ratio is often significantly higher if messages can be compressed relative to the information contained in previous messages. For this reason, it is possible to create state items for access when a later message is being decompressed. Both the creation and access of state are designed to be secure against malicious tampering with the compressed data. The UDVM can only create a state item when a complete message has been successfully decompressed and the application has returned a compartment identifier under which the state can be saved.
メッセージは、前のメッセージに含まれる情報に対して圧縮することができれば、全体的な圧縮比がしばしば有意に高いこと、しかし、注意してください。このような理由から、後にメッセージが解凍されているときにアクセスするための状態項目を作成することが可能です。状態の作成とアクセスの両方が圧縮されたデータを改ざん悪意のあるに対して安全であるように設計されています。完全なメッセージが正常に解凍されており、アプリケーションは状態を保存することができ、その下コンパートメント識別子を返したとき、UDVMは唯一の状態項目を作成することができます。
State access cannot be protected by relying on the application alone, since the authentication mechanism may require information from the decompressed message (which of course is not available until after the state has been accessed). Instead, SigComp protects state access by creating a state identifier that is a hash over the item of state to be retrieved. This state_identifier must be supplied to retrieve an item of state from the state handler.
状態へのアクセスは、認証機構は、（もちろん状態がアクセスされるまでは使用できません）減圧メッセージからの情報を必要とするかもしれないので、単独のアプリケーションに依存することによって保護することができません。その代わりに、SigCompの状態の項目にわたってハッシュを取得する状態識別子を作成することによって、状態へのアクセスを保護します。このstate_identifierは状態ハンドラから状態のアイテムを取得するために供給されなければなりません。
Also note that state is not deleted when it is accessed. So even if a malicious sender manages to access some state information, subsequent messages compressed relative to this state can still be successfully decompressed.
また、それがアクセスされたときの状態が削除されないことに注意してください。悪意のある送信者がいくつかの状態情報にアクセスするために管理していてもそう、この状態に比べて圧縮された後続のメッセージはまだ成功し解凍することができます。
Each state item contains a state_identifier that is used to access the state. One state identifier can be supplied in the SigComp message header to initialize the UDVM (see Chapter 7); additional state items can be retrieved using the STATE-ACCESS instruction. The
各状態項目は状態にアクセスするために使用されstate_identifierが含まれています。一つの状態識別子は、UDVM（第7章を参照）を初期化するためのSigCompメッセージヘッダーに供給することができます。追加の状態項目がSTATEアクセス命令を使用して取得することができます。ザ・
UDVM can also request the creation of a new state item by using the STATE-CREATE and END-MESSAGE instructions (see Chapter 9 for further details).
UDVMは、（詳細は、第9章を参照してください）STATE-CREATEとEND-MESSAGE命令を使用して、新しい状態項目の作成を要求することができます。
The state handler manages state memory on a per-compartment basis. Each compartment can store state up to a certain state_memory_size (where the application may assign different values for the state_memory_size parameter to different compartments).
状態ハンドラごとのコンパートメント毎に状態メモリを管理します。各区画は、（アプリケーションが別の区画にstate_memory_sizeパラメータの異なる値を割り当てることができる）、特定state_memory_sizeまでの状態を記憶することができます。
As well as storing the state items themselves, the state handler maintains a list of the state items created by a particular compartment and ensures that no compartment exceeds its allocated state_memory_size. For the purpose of calculation, each state item is considered to cost (state_length + 64) bytes.
ならびに状態項目自体を格納する、状態ハンドラは、特定の区画で作成された状態項目のリストを保持しない区画が割り当てられstate_memory_sizeを超えないことを保証します。計算の目的のために、各状態の項目が（state_length + 64）バイトを要すると考えられます。
Each instance of the UDVM can pass up to four state creation requests to the state handler, as well as up to four state free requests (the latter are requests to free the memory taken by a state item in a certain compartment). When the state handler receives a state creation request from the UDVM it takes the following steps:
UDVMの各インスタンスは、状態ハンドラへ、ならびに4つの状態フリー要求（後者は特定の区画に状態項目によって撮影されたメモリを解放するための要求である）までの4つの状態の作成要求に渡すことができます。状態ハンドラがUDVMから状態作成要求を受信した場合には、以下の手順を実行します。
1. The state handler MUST reject all state creation requests that are not accompanied by a valid compartment identifier, or if the compartment is allocated 0 bytes of state memory. Note that if a state creation request fails due to lack of state memory then it does not mean that the corresponding SigComp message is damaged; compressors will often make state creation requests in the first SigComp message of a compartment, before they have discovered the state_memory_size using the SigComp feedback mechanism.
1.状態ハンドラは有効なコンパートメント識別子を伴わない、または区画は、状態メモリの0バイトを割り当てられている場合、すべての状態の作成要求を拒絶しなければなりません。状態の作成要求が状態メモリが不足しているため失敗した場合、それが対応するのSigCompメッセージが破損していることを意味しないことに注意してください。彼らはのSigCompフィードバックメカニズムを使用してstate_memory_sizeを発見した前に、コンプレッサーは、多くの場合、コンパートメントの最初のSigCompメッセージの状態作成要求を行います。
2. If the state creation request needs more state memory than the total state_memory_size for the compartment, the state handler deletes all but the first (state_memory_size - 64) bytes from the state_value. It sets the state_length to (state_memory_size - 64), and recalculates the state_identifier as defined in Section 9.4.9.
2.状態作成要求が区画の合計state_memory_sizeよりステートメモリを必要とする場合、ステートハンドラは、最初の（state_memory_size - 64）が、すべてを削除state_valueのバイト。これは、（state_memory_size - 64）にstate_lengthを設定し、セクション9.4.9で定義されるようstate_identifierを再計算します。
3. If the state creation request contains a state_identifier that already exists then the state handler checks whether the requested state item is identical to the established state item and counts the state creation request as successful if this is the case. If not then the state creation request is unsuccessful (although the probability that this will occur is vanishingly small).
3.状態作成要求は、すでに要求された状態項目が確立状態項目と同一であり、これが事実であるかのように成功した状態の作成要求をカウントするかどうか、状態ハンドラのチェックを存在state_identifierが含まれている場合。状態の作成要求が失敗しない、その後場合（これが発生する確率は無視できるほど小さいですが）。
4. If the state creation request exceeds the state memory allocated to the compartment, sufficient items of state created by the same compartment are freed until enough memory is available to accommodate the new state. When a state item is freed, it is removed from the list of states created by the compartment and the memory cost of the state item no longer counts towards the total cost for the compartment. Note, however, that identical state items may be created by several different compartments, so a state item must not be physically deleted unless the state handler determines that it is no longer required by any compartment.
4.状態作成要求がコンパートメントに割り当て状態メモリを超えた場合、十分なメモリが新しい状態に適応するために利用可能になるまで、同じ区画で作成された状態の十分な項目が解放されます。状態項目が解放されると、それはコンパートメントによって作成された状態のリストから削除されていないと状態項目のメモリコストは、もはやコンパートメントのための総コストの方にカウントされます。ただし、同じ状態の項目がいくつかの異なる区画によって生成することができるので、状態ハンドラは、それがもはや区画によって必要とされていると判断しない場合を除き状態アイテムが物理的に削除してはならないこと。
5. The order in which the existing state items are freed is determined by the state_retention_priority, which is set when the state items are created. The state_retention_priority of 65535 is reserved for locally available states; these states must always be freed first. Apart from this special case, states with the lowest state_retention_priority are always freed first. In the event of a tie, then the state item created first in the compartment is also the first to be freed.
5.既存の状態の項目が解放される順序は、状態の項目が作成されたときに設定されているstate_retention_priority、によって決定されます。 65535のstate_retention_priorityは、ローカルで利用可能な状態のために予約されています。これらの状態は、常に最初に解放しなければなりません。これとは別に特別なケースから、最低state_retention_priorityと状態は常に最初に解放されます。同点の場合には、区画内に最初に作成された状態のアイテムも解放する最初のものです。
The state_retention_priority is always stored on a per-compartment basis as part of the list of state items created by each compartment. In particular, the same state item might have several priority values if it has been created by several different compartments.
state_retention_priorityは常に各区画によって作成された状態項目のリストの一部としてあたりの区画に基づいて格納されています。それは、いくつかの異なる区画によって作成されている場合は特に、同じ状態の項目には、いくつかの優先順位の値を持っているかもしれません。
Note that locally available state items (as described in Section 3.3.3) need not be mapped to any particular compartment. However, if they are created on a per-compartment basis, then they must not interfere with the state created at the request of the remote endpoint. The special state_retention_priority of 65535 is reserved for locally available state items to ensure that this is the case.
（セクション3.3.3で説明したように）、その局所的に利用可能な状態の項目に注意して、任意の特定の区画にマッピングする必要はありません。それらはあたりのコンパートメントに基づいて作成されている場合は、それらはリモートエンドポイントの依頼で作成された状態を妨害してはなりません。 65535の特別state_retention_priorityはこれが事実であることを保証するために、局所的に利用可能な状態のアイテムのために予約されています。
The UDVM may also explicitly request the state handler to free a specific state item in a compartment. In this case, the state handler deletes the state item from the list of state items created by the compartment (as before the state item itself must not be physically deleted unless the state handler determines that it is not longer required by any compartment).
UDVMはまた、明示的コンパートメント内の特定の状態項目を解放する状態ハンドラを要求することができます。この場合、状態ハンドラは（状態ハンドラは、それがより長い任意の区画によって必要とされていないと判断しない限り、それ自体が物理的に削除してはならない状態項目の前のような）区画によって作成された状態項目のリストから状態項目を削除します。
The application should indicate to the state handler when it wishes to close a particular compartment, so that the resources taken by the corresponding state can be reclaimed.
対応する状態で撮影されたリソースを再利用することができるように、それは、特定の区画を閉鎖したい場合、アプリケーションは、ステートハンドラに示すべきです。
The SigComp feedback mechanism allows feedback data to be received by a UDVM and forwarded via the state handler to the correct compressor.
SigCompのフィードバック機構は、フィードバックデータは、UDVMによって受信され、正しい圧縮機状態ハンドラを介して転送されることを可能にします。
Since this feedback data is retained between SigComp messages, it is considered to be part of the overall state and can only be forwarded if accompanied by a valid compartment identifier. If this is the case, then the state handler forwards the feedback data to the compressor responsible for sending messages that pertain to the peer compartment of the specified compartment.
このフィードバックデータのSigCompメッセージの間に保持されているので、全体的な状態の一部であると考えられ、有効なコンパートメント識別子を伴う場合にのみ転送することができます。このような場合は、その後、状態ハンドラは、指定されたコンパートメントのピア・コンパートメントに関連するメッセージを送信するための責任圧縮機にフィードバックデータを転送します。
This chapter describes the format of the SigComp message and how the message is used to initialize the UDVM memory.
この章では、SigCompのメッセージのフォーマットを説明し、メッセージがUDVMメモリを初期化するために使用される方法。
Note that the SigComp message is not copied into the UDVM memory as soon as it arrives; instead, the UDVM indicates when it requires compressed data using a specific instruction. It then pauses and waits for the information to be supplied before executing the next instruction. This means that the UDVM can begin to decompress a SigComp message before the entire message has been received.
それが到着するようにSigCompメッセージは、すぐにUDVMメモリにコピーされていないことに注意してください。それは特定の命令を使用して圧縮されたデータを必要とするとき代わりに、UDVMを示しています。その後、一時停止情報は、次の命令を実行する前に供給されるのを待ちます。これは、UDVMは、メッセージ全体が受信された前のSigCompメッセージを解凍し始めることができることを意味します。
A consequence of the above behavior is that when the UDVM is invoked, the size of the UDVM memory depends on whether the transport used to provide the SigComp message is stream-based or message-based. If the transport is message-based then sufficient memory must be available to buffer the entire SigComp message before it is passed to the UDVM. So if the message is n bytes long, then the UDVM memory size is set to (decompression_memory_size - n), up to a maximum of 65536 bytes.
上記の動作の結果は、UDVMが呼び出されたときに、UDVMメモリのサイズは、のSigCompメッセージを提供するために使用されるトランスポートストリームベースまたはメッセージベースであるかどうかに依存することです。トランスポートがメッセージベースであれば、十分なメモリは、それがUDVMに渡される前に、全体のSigCompメッセージをバッファリングするために使用可能でなければなりません。 65536バイトの最大値まで、 - メッセージをnとバイト長あれば、その後、UDVMメモリサイズは（N decompression_memory_size）に設定されています。
If the transport is stream-based however, then a fixed-size input buffer is required to accommodate the stream, independently of the size of each SigComp message. So, for simplicity, the UDVM memory size is set to (decompression_memory_size / 2).
トランスポートしかしストリームベースである場合、固定サイズの入力バッファは、それぞれ独立のSigCompメッセージのサイズ、ストリームを収容するために必要とされます。だから、簡単にするために、UDVMメモリサイズは（decompression_memory_size / 2）に設定されています。
As a separate instance of the UDVM is invoked on a per-message basis, each SigComp message must explicitly indicate its chosen decompression algorithm as well as any additional information that is needed to decompress the message (e.g., one or more previously received messages, a dictionary of common SIP phrases etc.). This information can either be uploaded as part of the SigComp message or retrieved from an item of state.
UDVMの別のインスタンスがメッセージごとに呼び出されるように、それぞれのSigCompメッセージが明示的に選択された解凍アルゴリズムならびにメッセージを解凍するために必要とされる任意の追加情報を指定する必要があり（例えば、1つ以上の以前のメッセージを受信し、一般的なSIPフレーズの辞書など）。この情報は、いずれかのSigCompメッセージの一部としてアップロードまたは状態の項目から検索することができます。
A SigComp message takes one of two forms depending on whether it accesses a state item at the receiving endpoint. The two variants of a SigComp message are given in Figure 3. (The T-bit controls the format of the returned feedback item and is defined in Section 7.1.)
SigCompメッセージは、受信エンドポイントで状態項目にアクセスするかどうかに応じて2つのいずれかの形式をとります。 SigCompメッセージの二つの変種が、図3に示されている（Tビットが返されたフィードバック項目の形式を制御し、セクション7.1で定義されています。）
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 3: Format of a SigComp message
図3：のSigCompメッセージのフォーマット
Decompression failure occurs if the SigComp message is too short to contain the expected fields (see Section 8.7 for further details).
SigCompメッセージが期待される分野が含まれているには短すぎる場合は解凍失敗は（詳細については、セクション8.7を参照）が発生します。
The fields except for the "remaining SigComp message" are referred to as the "SigComp header" (note that this may include the uploaded UDVM bytecode).
「残りのSigCompメッセージ」以外のフィールドが「のSigCompヘッダ」（これは、アップロードされたUDVMバイトコードを含んでいてもよいことに注意）と呼ばれます。
For both variants of the SigComp message, the T-bit is set to 1 whenever the SigComp message contains a returned feedback item. The format of the returned feedback item is illustrated in Figure 4.
SigCompメッセージが返されたフィードバック項目を含むたびにSigCompメッセージの両方の変異体について、Tビットが1に設定されています。返されたフィードバック項目の形式は、図4に示されています。
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | returned_feedback_field | | 1 | returned_feedback_length |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| |
: returned_feedback_field :
| |
+---+---+---+---+---+---+---+---+
Figure 4: Format of returned feedback item
図4：返されたフィードバック項目のフォーマット
Note that the returned feedback length specifies the size of the returned feedback field (from 0 to 127 bytes). So the total size of the returned feedback item lies between 1 and 128 bytes.
返されたフィードバックの長さが（0〜127バイト）から返されたフィードバック・フィールドのサイズを指定することに留意されたいです。だから、返されたフィードバック項目の合計サイズが1と128バイトの間にあります。
The returned feedback item is not copied to the UDVM memory; instead, it is buffered until the UDVM has successfully decompressed the SigComp message. It is then forwarded to the state handler with the rest of the feedback data (see Section 9.4.9 for further details).
返されたフィードバック項目はUDVMメモリにコピーされません。 UDVMが正常にSigCompメッセージを解凍するまで代わりに、それがバッファリングされています。次に、それをフィードバックデータ（詳細については、セクション9.4.9を参照）の残りの部分と状態ハンドラに転送されます。
The len field of the SigComp message determines which fields follow the returned feedback item. If the len field is non-zero, then the SigComp message contains a state identifier to access a state item at the receiving endpoint. All state items include a 20-byte state identifier as per Section 3.3.3, but it is possible to transmit as few as 6 bytes from the identifier if the sender believes that this is sufficient to match a unique state item at the receiving endpoint.
SigCompメッセージのLENフィールドが返されたフィードバック項目をたどるフィールドを決定します。 LENフィールドが非ゼロである場合、その後のSigCompメッセージは、受信エンドポイントの状態項目にアクセスするための状態識別子を含みます。すべての状態項目はセクション3.3.3に従って20バイトの状態識別子を含むが、送信者がこの受信エンドポイントに固有の状態項目に一致するのに十分であると考えている場合には、識別子からわずか6としてバイトを送信することができます。
The len field encodes the number of transmitted bytes as follows:
次のようにLENフィールドは、送信されたバイトの数を符号化します。
Encoding: Length of partial state identifier
エンコード：パーシャル状態識別子の長さ
01 6 bytes 10 9 bytes 11 12 bytes
01 6バイト10 9バイト11の12バイト
The partial state identifier is passed to the state handler, which compares it with the most significant bytes of the state_identifier in every currently stored state item. Decompression failure occurs if no state item is matched or if more than one state item is matched.
パーシャル状態識別子は、すべての現在保存されている状態の項目でstate_identifierの最上位バイトと比較状態ハンドラに渡されます。いかなる状態項目が一致していない場合、または複数の状態項目が一致した場合に減圧障害が発生します。
Decompression failure also occurs if exactly one state item is matched but the state item contains a minimum_access_length greater than the length of the partial state identifier. This prevents especially sensitive state items from being accessed maliciously by brute force guessing of the state_identifier.
正確に一つの状態項目が一致した場合に減圧障害も生じるが、状態項目は、部分状態識別子の長さよりも大きいminimum_access_lengthを含有します。これはstate_identifierの推測ブルートフォースによって悪意アクセスから特に敏感な状態のアイテムを防止します。
If a state item is successfully accessed then the state_value byte string is copied into the UDVM memory beginning at state_address.
状態項目が正常にアクセスされている場合は、state_valueバイト文字列はstate_addressから始まるUDVMメモリにコピーされます。
The first 32 bytes of UDVM memory are then initialized to special values as illustrated in Figure 5.
図5に示すように、UDVMメモリの最初の32バイトは、その後、特別な値に初期化されます。
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDVM_memory_size | 0 - 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cycles_per_bit | 2 - 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SigComp_version | 4 - 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| partial_state_ID_length | 6 - 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| state_length | 8 - 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: reserved : 10 - 31
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Initializing Useful Values in UDVM memory
図5：UDVMメモリに有用な値を初期化します
The first five 2-byte words are initialized to contain some values that might be useful to the UDVM bytecode (Useful Values). Note that these values are for information only and can be overwritten when executing the UDVM bytecode without any effect on the endpoint. The MSBs of each 2-byte word are stored preceding the LSBs.
最初の5つの2バイトワードはUDVMバイトコードに役に立つかもしれないいくつかの値（有用な値）を含むように初期化されています。これらの値は情報のみのためであり、エンドポイントに影響することなく、UDVMバイトコードを実行するときに上書きすることができることに留意されたいです。各2バイトワードのMSBはLSBを先行格納されています。
Addresses 0 to 5 indicate the resources available to the receiving endpoint. The UDVM memory size is expressed in bytes modulo 2^16, so in particular, it is set to 0 if the UDVM memory size is 65536 bytes. The cycles_per_bit is expressed as a 2-byte integer taking the value 16, 32, 64 or 128. The SigComp_version is expressed as a 2-byte value as per Section 3.3.2.
アドレス0〜5は、受信エンドポイントに使用可能なリソースを示しています。 UDVMメモリサイズは2 ^ 16を法とするので、UDVMメモリサイズが65536バイトである場合、特に、それが0に設定されているバイト数で表現されます。 cycles_per_bitはSigComp_versionはセクション3.3.2に従って2バイト値として表される16、32、64または128の値をとる2バイト整数として表現されます。
Addresses 6 to 9 are initialized to the length of the partial state identifier, followed by the state_length from the retrieved state item. Both are expressed as 2-byte values.
6~9アドレスが検索された状態項目からstate_length続く部分状態識別子の長さに初期化されます。両方が2バイト値として表されます。
Addresses 10 to 31 are reserved and are initialized to 0 for Version 0x01 of SigComp. Future versions of SigComp can use these locations for additional Useful Values, so a decompressor MUST NOT rely on these values being zero.
31から10が予約されているとのSigCompのバージョン0x01のために0に初期化されているアドレス。デコンプレッサはゼロであるこれらの値に依存してはならないようにSigCompの将来のバージョンでは、追加の有用な値のためにこれらの場所を使用することができます。
Any remaining addresses in the UDVM memory that have not yet been initialized MUST be set to 0.
まだ初期化されていないUDVMメモリ内の任意の残りのアドレスは0に設定しなければなりません。
The UDVM then begins executing instructions at the memory address contained in state_instruction (which is part of the retrieved item of state). Note that the remaining SigComp message is held by the decompressor dispatcher until requested by the UDVM.
UDVMは、その後（状態の検索項目の一部である）state_instructionに含まれるメモリアドレスで命令の実行を開始します。 UDVMによって要求されるまで、残りのSigCompメッセージは、デコンプレッサディスパッチャに保持されていることに留意されたいです。
(Note that the Useful Values are only set at UDVM startup; there is no special significance to this memory area afterwards. This means that the UDVM bytecode is free to use these locations for any other purpose a memory location might be used for; it just has to be aware they are not necessarily initialized to zero.)
（有用な値のみUDVMの起動時に設定されていることに注意してください。その後、このメモリ領域に特別な意味はありませんこれはUDVMバイトコードがメモリ位置がために使用されるかもしれない、他の目的のためにこれらの場所を自由に使用することを意味し、それだけで彼らは必ずしもゼロに初期化されていません注意する必要があります。）
If the len field is set to 0 then the bytecode needed to decompress the SigComp message is supplied as part of the message itself. The 12-bit code_len field specifies the size of the uploaded UDVM bytecode (from 0 to 4095 bytes inclusive); eight most significant bits are in the first byte, followed by the four least significant bits in the most significant bits in the second byte. The remaining bits in the second byte are interpreted as a 4-bit destination field that specifies the starting memory address to which the bytecode is copied. The destination field is encoded as follows:
LENフィールドは、その後0に設定されている場合のSigCompメッセージを解凍するために必要なバイトコードは、メッセージ自体の一部として供給されます。 12ビットcode_lenフィールド（0から包括4095バイト）アップロードUDVMバイトコードのサイズを指定します。上位8ビットは、第二のバイトの最上位ビットの4つの最下位ビットが続く、最初のバイトです。第二のバイトの残りのビットは、バイトコードがコピーされた開始メモリアドレスを指定する4ビットの宛先フィールドとして解釈されます。次のように宛先フィールドは、符号化されています：
Encoding: Destination address:
エンコード：宛先アドレス：
0000 reserved 0001 2 * 64 = 128 0010 3 * 64 = 196 0011 4 * 64 = 256 : : 1111 16 * 64 = 1024
* 64 = 1024 1111 16：0000 0001 2 * 64 = 128 0010 3 * 64 = 196 0011 4×64 = 256予約しました
Note that the encoding 0000 is reserved for future SigComp versions, and causes a decompression failure in Version 0x01.
符号0000は、将来のSigCompのバージョンのために予約、およびバージョンが0x01で解凍失敗を引き起こしていることに留意されたいです。
The UDVM memory is initialized as per Figure 5, except that addresses 6 to 9 inclusive are set to 0 because no state item has been accessed. The UDVM then begins executing instructions at the memory address specified by the destination field. As above, the remaining SigComp message is held by the decompressor dispatcher until needed by the UDVM.
UDVMメモリはそれが全く状態項目がアクセスされていないので、0に設定されている6~9包括的に対処する以外は、図5の通りに初期化されます。 UDVMは、宛先フィールドで指定されたメモリアドレスにある命令を実行開始します。 UDVMによって必要とされるまで、上記のように、残りのSigCompメッセージは、デコンプレッサディスパッチャに保持されています。
Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM). The UDVM is a virtual machine much like the Java Virtual Machine but with a key difference: it is designed solely for the purpose of running decompression algorithms.
SigCompのための解凍機能は、ユニバーサルデコンプレッサ仮想マシン（UDVM）によって提供されます。 UDVMは、Java仮想マシンのようなしかし重要な違いを持つ多くの仮想マシンである：それは、解凍アルゴリズムを実行する目的のためだけに設計されています。
The motivation for creating the UDVM is to provide flexibility when choosing how to compress a given application message. Rather than picking one of a small number of pre-negotiated algorithms, the compressor implementer has the freedom to select an algorithm of their choice. The compressed data is then combined with a set of UDVM instructions that allow the original data to be extracted, and the result is outputted as a SigComp message. Since the UDVM is optimized specifically for running decompression algorithms, the code size of a typical algorithm is small (often sub 100 bytes). Moreover, the UDVM approach does not add significant extra processing or memory requirements compared to running a fixed preprogrammed decompression algorithm.
UDVMを作成するための動機は、与えられたアプリケーションメッセージを圧縮する方法を選択する際の柔軟性を提供することです。むしろ事前に交渉したアルゴリズムの数が少ないの一つを取り上げるよりも、コンプレッサ実装者は、彼らの選択のアルゴリズムを選択する自由を持っています。圧縮されたデータは、その後、元のデータが抽出されることを可能にするUDVM命令のセットと組み合わされ、その結果がのSigCompメッセージとして出力されます。 UDVMが解凍アルゴリズムを実行するために特別に最適化されているので、一般的なアルゴリズムのコードサイズは、（多くの場合、100バイトサブ）小さいです。また、UDVMのアプローチは、固定された予めプログラムされた解凍アルゴリズムを実行していると比較して有意な余分な処理またはメモリ要件を追加しません。
Figure 6 gives a detailed view of the interfaces between the UDVM and its environment.
図6は、UDVMとその環境との間のインターフェースの詳細図を与えます。
+----------------+ +----------------+
| | Request compressed data | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide compressed data | |
| | | |
| | Output decompressed data | Decompressor |
| |-------------------------------->| dispatcher |
| | | |
| | Indicate end of message | |
| |-------------------------------->| |
| |<--------------------------------| |
| UDVM | Provide compartment identifier | |
| | +----------------+
| |
| | +----------------+
| | Request state information | |
| |-------------------------------->| |
| |<--------------------------------| |
| | Provide state information | State |
| | | handler |
| | Make state creation request | |
| |-------------------------------->| |
| | Forward feedback information | |
+----------------+ +----------------+
Figure 6: Interfaces between the UDVM and its environment
図6：UDVMとその環境の間のインタフェース
Note that once the UDVM has been initialized, additional compressed data and state information are only provided at the request of a specific UDVM instruction.
UDVMが初期化された後、追加の圧縮データと状態情報は、特定UDVM命令の要求に応じて提供されることに留意されたいです。
This chapter describes the basic features of the UDVM including the UDVM registers and the format of UDVM bytecode.
この章では、UDVMレジスタとUDVMバイトコードのフォーマットを含むUDVMの基本的な機能について説明します。
The UDVM registers are 2-byte words in the UDVM memory that have special tasks, for example specifying the location of the stack used by the CALL and RETURN instructions.
UDVMレジスタは、CALLおよびRETURN命令によって使用されるスタックの位置を特定例えば特別なタスクを有するUDVMメモリの2バイト・ワードです。
The UDVM registers are illustrated in Figure 7.
UDVMレジスタは、図7に示されています。
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_left | 64 - 65
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte_copy_right | 66 - 67
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| input_bit_order | 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stack_location | 70 - 71
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Memory addresses of the UDVM registers
図7：UDVMレジスタのメモリ・アドレス
The MSBs of each register are always stored before the LSBs. So, for example, the MSBs of byte_copy_left are stored at Address 64 whilst the LSBs are stored at Address 65.
各レジスタのMSBは常に最下位ビットの前に保存されます。したがって、たとえば、LSBの間、アドレス64に格納されていbyte_copy_leftの最上位ビットはアドレス65で保存されています。
The use of each UDVM register is defined in the following sections.
各UDVMレジスタの使用は、以下のセクションで定義されています。
(Note that the UDVM registers start at Address 64, that is 32 bytes after the area reserved for Useful Values. The intention is that the gap, i.e., the area between Address 32 and Address 63, will often be used as scratch-pad memory that is guaranteed to be zero at UDVM startup and is efficiently addressable in operand types reference ($) and multitype (%).)
（UDVMレジスタはアドレス64で開始することに注意してください、それは有用な値のために確保された領域の後に32バイトである。意図はギャップが、すなわち、アドレス32及び63をアドレスとの間の領域、多くの場合、スクラッチパッドメモリとして使用されることですそれは、UDVMの起動時にゼロであることが保証され、効率的にオペランドの型の参照（$）とマルチタイプ（％）でアドレス指定されています。）
The decompressor dispatcher stores the compressed data from the SigComp message before it is requested by the UDVM via one of the INPUT instructions. When the UDVM bytecode is first executed, the dispatcher contains the remaining SigComp message after the header has been used to initialize the UDVM as per Chapter 7.
それは入力命令のうちの1つを介してUDVMによって要求される前に、デコンプレッサディスパッチャはのSigCompメッセージからの圧縮データを格納します。 UDVMバイトコードが最初に実行された場合、ディスパッチャはヘッダは第7章に従ってUDVMを初期化するために使用された後、残りのSigCompメッセージを含みます。
Note that the INPUT-BITS and INPUT-HUFFMAN instructions retrieve a stream of individual compressed bits from the dispatcher. To provide bitwise compatibility with various well-known compression algorithms, the input_bit_order register can modify the order in which individual bits are passed within a byte.
入力ビットと入力ハフマン命令は、ディスパッチャからの個々の圧縮されたビットのストリームを取得することに留意されたいです。様々な周知の圧縮アルゴリズムとのビット単位の互換性を提供するために、input_bit_orderレジスタは、個々のビットがバイト内に渡される順序を変更することができます。
The input_bit_order register contains the following three flags:
input_bit_orderレジスタは、次の3つのフラグが含まれています。
0 7 8 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |F|H|P| 68 - 69
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The P-bit controls the order in which bits are passed from the dispatcher to the INPUT instructions. If set to 0, it indicates that the bits within an individual byte are passed to the INPUT instructions in MSB to LSB order. If it is set to 1, the bits are passed in LSB to MSB order.
Pビットは、ビットが入力命令にディスパッチャから渡される順序を制御します。 0に設定すると、それは個々のバイト内のビットがLSB順にMSBのINPUT指示に渡されることを示しています。それが1に設定されている場合は、ビットはLSB MSBの順に渡されます。
Note that the input_bit_order register cannot change the order in which the bytes themselves are passed to the INPUT instructions (bytes are always passed in the same order as they occur in the SigComp message).
input_bit_orderレジスタはバイト自体はINPUT命令（彼らはのSigCompメッセージで発生するようバイトは常に同じ順序で渡される）に渡される順序を変更することはできません。
The following diagram illustrates the order in which bits are passed to the INPUT instructions for both cases:
次の図は、ビットが両方の場合の入力指示に渡される順序を示しています。
MSB LSB MSB LSB MSB LSB MSB LSB
MSB LSB MSB LSB MSB LSB MSB LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 2 3 4 5 6 7|8 9 ... | |7 6 5 4 3 2 1 0| ... 9 8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Byte 0 Byte 1 Byte 0 Byte 1
バイト0バイト1つのバイト0バイト1
P = 0 P = 1
P = 0、P = 1
Note that after one or more INPUT instructions the dispatcher may hold a fraction of a byte (what used to be the LSBs if P = 0, or, the MSBs, if P = 1). If an INPUT instruction is encountered and the P-bit has changed since the last INPUT instruction, any fraction of a byte still held by the dispatcher MUST be discarded (even if the INPUT instruction requests zero bits). The first bit passed to the INPUT instruction is taken from the subsequent byte.
（P = 1の場合、P = 0の場合のLSBであることが使用したもの、または、最上位ビット）の後に、または複数の入力命令ディスパッチャは、バイトの端数を保持してもよいことに留意されたいです。入力命令に遭遇するとPビットが最後の入力指示以降に変更された場合、依然としてディスパッチャに保持されたバイトの端数は、（入力された指示がゼロのビットを要求しても）は廃棄されなければなりません。入力命令に渡される最初のビットは、後続のバイトから取り出されます。
When an INPUT instruction requests n bits of compressed data, it interprets the received bits as an integer between 0 and 2^n - 1. The F-bit and the H-bit specify whether the bits in these integers are considered to arrive in MSB to LSB order (bit set to 0) or in LSB to MSB order (bit set to 1).
入力された指示は、圧縮データのnビットを要求したとき、それは0と2の間の整数として受信したビットを解釈^ N - 1 FビットとHビットこれらの整数のビットはMSBに到着すると考えられるかどうかを指定LSB順序（0に設定ビット）に、または中LSB MSBの順に（ビット1に設定されます）。
If the F-bit is set to 0, the INPUT-BITS instruction interprets the received bits as arriving MSBs first, and if it is set to 1, it interprets the bits as arriving LSBs first. The H-bit performs the same function for the INPUT-HUFFMAN instruction. Note that it is possible to set these two bits to different values in order to use different bit orders for the two instructions (certain algorithms actually require this, e.g., DEFLATE [RFC-1951]). (Note that there are no special considerations for changing the F- or H-bit between INPUT instructions, unlike the discard rule for the P-bit described above.)
Fビットが0に設定されている場合は、入力ビット命令は、最初のMSBを到着として受信されたビットを解釈し、それは1に設定されている場合、それは最初のLSBを到着としてビットを解釈します。 Hビットは、入力ハフマン命令の同じ機能を実行します。 （特定のアルゴリズムは、実際にこれを必要とする、例えば、DEFLATE [RFC-1951]）は、2つの手順について異なるビット命令を使用するために異なる値にこれら2つのビットを設定することが可能であることに留意されたいです。 （上記Pビットのための廃棄ルールとは異なり、入力命令との間F-又はHビットを変更するための特別な考慮事項が存在しないことに注意してください。）
Decompression failure occurs if an INPUT-BITS or an INPUT-HUFFMAN instruction is encountered and the input_bit_order register does not lie between 0 and 7 inclusive.
INPUT-BITSまたはINPUT-ハフマン指示が検出されたとinput_bit_orderレジスタが0と7包括の間に存在しない場合、解凍の失敗が発生します。
Certain UDVM instructions make use of a stack of 2-byte words stored at the memory address specified by the 2-byte word stack_location. The stack contains the following words:
特定のUDVM命令は、2バイトのワードstack_locationで指定されたメモリアドレスに格納されている2バイトワードのスタックを利用します。スタックは、次の単語が含まれています。
Name: Starting memory address:
名前：開始メモリアドレス：
stack_fill stack_location stack[0] stack_location + 2 stack[1] stack_location + 4 stack[2] stack_location + 6 : :
stack_fill stack_locationスタック[0] stack_location + 2スタック[1] stack_location + 4スタック[2] stack_location + 6：
The notation stack_location is an abbreviation for the contents of the stack_location register, i.e., the 2-byte word at locations 70 and 71. The notation stack_fill is an abbreviation for the 2-byte word at stack_location and stack_location+1. Similarly, the notation stack[n] is an abbreviation for the 2-byte word at stack_location+2*n+2 and stack_location+2*n+3. (As always, the arithmetic is modulo 2^16.)
表記stack_locationは、stack_locationレジスタの内容の略語、すなわち、位置70での2バイトのワードと71表記stack_fillはstack_locationとstack_location + 1での2バイト語の略称です。同様に、表記スタック[n]はstack_locationに2バイトワード+ 2 * N + 2及びstack_location + 2 * N + 3の略です。 （いつものように、演算は、モジュロ2 ^ 16です。）
The stack is used by the CALL, RETURN, PUSH and POP instructions.
スタックはCALL、RETURN、PUSHとPOP命令で使用されます。
"Pushing" a value on the stack is an abbreviation for copying the value to stack[stack_fill] and then increasing stack_fill by 1. CALL and PUSH push values on the stack.
スタック上の値を「押すこと」[stack_fill】積層する値をコピーした後、スタックに1 CALLプッシュプッシュ値によってstack_fill増加させるための略語です。
"Popping" a value from the stack is an abbreviation for decreasing stack_fill by 1, and then using the value stored in stack[stack_fill]. Decompression failure occurs if stack_fill is zero at the commencement of a popping operation. POP and RETURN pop values from the stack.
スタックから「ポップ」の値は、[stack_fill】スタックに格納された値を使用し、次いで1 stack_fillを減少させ、の略語です。 stack_fillが飛び出る操作の開始時にゼロであれば減圧障害が発生しました。スタックからPOPやRETURNポップ値。
For both of these abstract operations, the UDVM first takes note of the current value of stack_location and uses this value for both sub-operations (accessing the stack and manipulating stack_fill), i.e., overwriting stack_location in the course of the operation is inconsequential for the operation.
これらの抽象操作の両方について、UDVMは最初stack_locationの現在の値をメモを取り、サブ操作（スタックにアクセスし、stack_fill操作）の両方のために、この値を使用して、すなわち、操作の過程でstack_locationを上書きすることのために重要でありません操作。
A number of UDVM instructions require a string of bytes to be copied to and from areas of the UDVM memory. This section defines how the byte copying operation should be performed.
UDVM命令の数は、UDVMメモリの領域へとからコピーするバイトのストリングを必要とします。このセクションでは、バイトのコピー操作を実行する方法を定義します。
The string of bytes is copied in ascending order of memory address, respecting the bounds set by byte_copy_left and byte_copy_right. More precisely, if a byte is copied from/to Address m then the next byte is copied from/to Address n where n is calculated as follows:
バイトの列がbyte_copy_leftとbyte_copy_rightによって設定された境界を尊重し、メモリアドレスの昇順にコピーされます。より正確には、バイトをmに対処するために/からコピーされた場合、次のバイトはアドレスへ/からコピーされたn次のようにnが算出されます。
Set k := m + 1 (modulo 2^16) If k = byte_copy_right then set n := byte_copy_left, else set n := k
kは= byte_copy_right次いでNを設定した場合の= M + 1（モジュロ2 ^ 16）：= byte_copy_left、他のセットn：= K Kを設定します
Decompression failure occurs if a byte is copied from/to an address beyond the UDVM memory.
バイトがUDVMメモリを超えたアドレスに/からコピーされた場合の減圧障害が発生しました。
Note that the string of bytes is copied one byte at a time. In particular, some of the later bytes to be copied may themselves have been written into the UDVM memory by the byte copying operation currently being performed.
バイトの文字列が一度に1つのバイトをコピーされることに注意してください。具体的には、コピーする後バイトの一部は、それ自体は、現在実行されているバイトコピー操作によってUDVMメモリに書き込まれていてもよいです。
Equally, it is possible for a byte copying operation to overwrite the instruction that invoked the byte copy. If this occurs, then the byte copying operation MUST be completed as if the original instruction were still in place in the UDVM memory (this also applies if byte_copy_left or byte_copy_right are overwritten).
バイトのコピー操作は、バイトのコピーを呼び出し命令を上書きするために等しく、それが可能です。この問題が発生した場合、元の命令はUDVMメモリの代わりに、まだあったかのように、その後、バイトのコピー動作が完了する必要があります（これも適用されるbyte_copy_leftまたは上書きbyte_copy_rightしている場合）。
Byte copying is used by the following UDVM instructions:
バイトのコピーは、以下のUDVM命令によって使用されます。
SHA-1, COPY, COPY-LITERAL, COPY-OFFSET, MEMSET, INPUT-BYTES, STATE-ACCESS, OUTPUT, END-MESSAGE
SHA-1、COPY、COPYリテラル、COPYオフセット、memsetの入力バイト、STATE-ACCESS、OUTPUT、END-MESSAGE
Each of the UDVM instructions in a piece of UDVM bytecode is represented by a single byte, followed by 0 or more bytes containing the operands required by the instruction.
UDVMバイトコードのピースにUDVM命令の各々は、命令によって必要とされるオペランドを含む0以上のバイトに続く、シングルバイトで表されます。
During instruction execution, conceptually the UDVM first fetches the first byte of the instruction, determines the number and types of operands required for this instruction, and then decodes all the operands in sequence before starting to act on the instruction. (Note that the UDVM instructions have been designed in such a way that this sequence remains conceptual in those cases where it would result in an unreasonable burden on the implementation.)
命令実行中に、概念的UDVMは、まず、命令の最初のバイトをフェッチし、この命令に必要なオペランドの数とタイプを決定し、指示に基づいて行動を開始する前に、シーケンス内のすべてのオペランドを復号します。 （UDVM命令はこの配列は、それが実装に無理な負担をもたらすような場合の概念的なままであるように設計されていることに注意してください。）
To reduce the size of typical UDVM bytecode, each operand for a UDVM instruction is compressed using variable-length encoding. The aim is to store more common operand values using fewer bytes than rarely occurring values.
典型的なUDVMバイトコードのサイズを小さくするために、UDVM命令の各オペランドは、可変長符号化を用いて圧縮されます。目的はめったに発生しない値よりも少ないバイトを使用して、より一般的なオペランド値を格納することです。
Four different types of operand are available: the literal, the reference, the multitype and the address. Chapter 9 gives a complete list of UDVM instructions and the operand types that follow each instruction.
オペランドの4つの異なるタイプが利用可能である：リテラル、参照、マルチタイプおよびアドレス。第9章では、UDVM命令と各命令に従わオペランドの型の完全なリストを提供します。
The UDVM bytecode for each operand type is illustrated in Figure 8 to Figure 10, together with the integer values represented by the bytecode.
各オペランドタイプのUDVMバイトコードがバイトコードで表される整数値と共に、図10に、図8に示されています。
Note that the MSBs in the bytecode are illustrated as preceding the LSBs. Also, any string of bits marked with k consecutive "n"s is to be interpreted as an integer N from 0 to 2^k - 1 inclusive (with the MSBs of n illustrated as preceding the LSBs).
バイトコードでのMSBがLSBを前のように図示されていることに留意されたいです。 （の最上位ビットとN個のLSBに先行するものとして図示）包括1 - また、ビットの任意の文字列が連続Kでマークされた「n」はsが2 ^ kに0から整数Nとして解釈されるべきです。
The decoded integer value of the bytecode can be interpreted in two ways. In some cases it is taken to be the actual value of the operand. In other cases it is taken to be a memory address at which the 2-byte operand value can be found (MSBs found at the specified address, LSBs found at the following address). The latter cases are denoted by memory[X] where X is the address and memory[X] is the 2- byte value starting at Address X.
バイトコードのデコードされた整数値は、2つの方法で解釈することができます。いくつかのケースでは、オペランドの実際の値であると解釈されます。 2バイトのオペランドの値を見つけることが可能なメモリアドレスであると解釈される他の場合には（指定されたアドレスで見出さのMSB、LSBは次のアドレスに見られます）。後者の場合は、[X] Xは、アドレスとメモリである[X]はアドレスXから始まる2バイトの値であるメモリが付されています
The simplest operand type is the literal (#), which encodes a constant integer from 0 to 65535 inclusive. A literal operand may require between 1 and 3 bytes depending on its value.
最も単純なオペランドタイプは0〜65535含めから整数定数をコードリテラル（＃）です。リテラルオペランドは、その値に応じて、1〜3バイトを必要とするかもしれません。
Bytecode: Operand value: Range:
バイトコード：オペランド値：範囲：
0nnnnnnn N 0 - 127 10nnnnnn nnnnnnnn N 0 - 16383 11000000 nnnnnnnn nnnnnnnn N 0 - 65535
0nnnnnnn N 0 - N 0 NNNNNNNN 127 10nnnnnn - 16383 11000000 NNNNNNNN N 0 NNNNNNNN - 65535
Figure 8: Bytecode for a literal (#) operand
図8：リテラル（＃）オペランドのバイトコード
The second operand type is the reference ($), which is always used to access a 2-byte value located elsewhere in the UDVM memory. The bytecode for a reference operand is decoded to be a constant integer from 0 to 65535 inclusive, which is interpreted as the memory address containing the actual value of the operand.
第二オペランドタイプは常にUDVMメモリの他の場所に位置する2バイトの値にアクセスするために使用される参照（$）、です。参照オペランドのバイトコードは、オペランドの実際の値を含むメモリアドレスとして解釈される0から包括65535整数定数、であることが復号化されます。
Bytecode: Operand value: Range:
バイトコード：オペランド値：範囲：
0nnnnnnn memory[2 * N] 0 - 65535 10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535 11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
NNNNNNNNメモリNNNNNNNN 65535 11000000 [N] 0 - - 0nnnnnnnメモリ[2 * N] 0 - 65535 10nnnnnn NNNNNNNNメモリ[2 * N] 0 65535
Figure 9: Bytecode for a reference ($) operand
図9：参照（$）オペランドのバイトコード
Note that the range of a reference operand is always 0 - 65535 independently of how many bits are used to encode the reference, because the operand always references a 2-byte value in the memory.
オペランドが常にメモリ内の2バイトの値を参照するため、独立して参照を符号化するために使用されるビット数の65535 - 参照オペランドの範囲は常に0であることに留意されたいです。
The third kind of operand is the multitype (%), which can be used to encode both actual values and memory addresses. The multitype operand also offers efficient encoding for small integer values (both positive and negative) and for powers of 2.
オペランドの第三の種類は、実際の値およびメモリアドレスの両方を符号化するために使用することができるマルチタイプ（％）、です。マルチタイプのオペランドは、（正と負の両方）小さな整数値の2の累乗のための効率的な符号化を提供します。
Bytecode: Operand value: Range:
バイトコード：オペランド値：範囲：
00nnnnnn N 0 - 63 01nnnnnn memory[2 * N] 0 - 65535 1000011n 2 ^ (N + 6) 64 , 128 10001nnn 2 ^ (N + 8) 256 , ... , 32768 111nnnnn N + 65504 65504 - 65535 1001nnnn nnnnnnnn N + 61440 61440 - 65535 101nnnnn nnnnnnnn N 0 - 8191 110nnnnn nnnnnnnn memory[N] 0 - 65535 10000000 nnnnnnnn nnnnnnnn N 0 - 65535 10000001 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
00nnnnnn N 0から63 01nnnnnnメモリ[2 * N] 0から65535 1000011n 2 ^（N + 6）64、128 10001nnn 2 ^（N + 8）、256、...、32768 111nnnnn N + 65504 65504から65535 1001nnnn NNNNNNNN NNNNNNNN N 0 NNNNNNNN 65535 10000000 - - N + 61440 61440 - 65535 101nnnnn NNNNNNNN N 0から8191 110nnnnn NNNNNNNNメモリ[N] 0 65535 10000001 NNNNNNNN NNNNNNNNメモリ[N] 0 - 65535
Figure 10: Bytecode for a multitype (%) operand
マルチタイプ（％）オペランドのバイトコード：図10
The fourth operand type is the address (@). This operand is decoded as a multitype operand followed by a further step: the memory address of the UDVM instruction containing the address operand is added to obtain the correct operand value. So if the operand value from Figure 10 is D then the actual operand value of an address is calculated as follows:
第四オペランドのタイプはアドレス（@）です。このオペランドは、更なるステップが続くマルチタイプオペランドとしてデコードされる：アドレスオペランドを含むUDVM命令のメモリアドレスが正しいオペランド値を得るために添加されます。図10からオペランド値は次のようにDは、アドレスの実際のオペランド値が算出されるのであれば：
operand_value = (memory_address_of_instruction + D) modulo 2^16
operand_value =（memory_address_of_instruction + D）モジュロ2 ^ 16
Address operands are always used in instructions that control program flow, because they ensure that the UDVM bytecode is position-independent code (i.e., it will run independently of where it is placed in the UDVM memory).
彼らは（すなわち、それは独立して、それがUDVMメモリ内に配置された場合の実行されます）UDVMバイトコードが位置独立コードであることを確認するため、アドレスオペランドは、常に、プログラムの流れを制御する命令で使用されています。
Once the UDVM has been invoked it executes the instructions contained in its memory consecutively unless otherwise indicated (for example when the UDVM encounters a JUMP instruction). If the next instruction to be executed lies outside the available memory then decompression failure occurs (see Section 8.7).
UDVMが呼び出された後、それは（UDVMは、JUMP命令を検出した場合など）他に示さない限り、連続的にそのメモリに含まれる命令を実行します。次の命令が、その後解凍障害が発生し、使用可能なメモリの外に嘘を実行する場合（8.7節を参照してください）。
To ensure that a SigComp message cannot consume excessive processing resources, SigComp limits the number of "UDVM cycles" allocated to each message. The number of available UDVM cycles is initialized to 1000 plus the number of bits in the SigComp header (as described in Section 7); this sum is then multiplied by cycles_per_bit. Each time an instruction is executed the number of available UDVM cycles is decreased by the amount specified in Chapter 9. Additionally, if the UDVM successfully requests n bits of compressed data using one of the INPUT instructions then the number of available UDVM cycles is increased by n * cycles_per_bit once the instruction has been executed.
SigCompメッセージが過剰処理リソースを消費することができないことを保証するために、のSigCompは、各メッセージに割り当てられた「UDVMサイクル」の数を制限します。利用可能なUDVMサイクル数1000プラス（第7節に記載のように）のSigCompヘッダ内のビットの数に初期化されます。この合計は、cycles_per_bitを掛けています。 UDVMが正常に利用可能UDVMサイクルの数を入力命令のいずれかを使用して圧縮されたデータのnビットだけ増加さを要求した場合、命令は、利用可能なUDVMサイクル数を実行するたびに、また第9章で指定された量だけ減少させますN *命令一度cycles_per_bitが実行されました。
This means that the maximum number of UDVM cycles available for processing an n-byte SigComp message is given by the formula:
これは、nバイトのSigCompメッセージを処理するために利用可能なUDVMサイクルの最大数は、以下の式によって与えられることを意味します。
maximum_UDVM_cycles = (8 * n + 1000) * cycles_per_bit
maximum_UDVM_cycles =（8×n個+ 1000）* cycles_per_bit
The reason that this total is not allocated to the UDVM when it is invoked is that the UDVM can begin to decompress a message that has only been partially received. So the total message size may not be known when the UDVM is initialized.
この合計は、それが呼び出されたUDVMに割り当てられていない理由は、UDVMは部分的にしか受信されたメッセージを解凍し始めることができるということです。 UDVMが初期化されるときに、全メッセージのサイズが知られないことがあります。
Note that the number of UDVM cycles MUST NOT be increased if a request for additional compressed data fails.
追加の圧縮されたデータの要求が失敗した場合にUDVMサイクル数が増加してはならないことに注意してください。
The UDVM stops executing instructions when it encounters an END-MESSAGE instruction or if decompression failure occurs (see Section 8.7 for further details).
UDVMは（詳細については、セクション8.7を参照）、それはEND-MESSAGE命令に遭遇したとき、または解凍障害が発生した場合、命令の実行を停止します。
If a compressed message given to the UDVM is corrupted (either accidentally or maliciously), then the UDVM may terminate with a decompression failure.
UDVMに与えられた圧縮されたメッセージは、（いずれかの偶然または故意）破損している場合、UDVMは伸張失敗に終了することができます。
Reasons for decompression failure include the following:
解凍失敗の理由は次のとおりです。
3. An instruction costs more than the number of remaining UDVM cycles.
3.命令は、残りのUDVMサイクルの数よりも多くの費用がかかります。
4. The UDVM attempts to read from or write to a memory address beyond its memory size.
4. UDVMは、読み出しまたはそのメモリサイズを超えてメモリアドレスに書き込もうとします。
7. An instruction is encountered that cannot be processed successfully by the UDVM (for example a RETURN instruction when no CALL instruction has previously been encountered).
7.指示は（例えば全くCALL命令が以前に遭遇されていないRETURN命令）UDVMによって正常に処理できない遭遇します。
9. A manual decompression failure is triggered using the DECOMPRESSION-FAILURE instruction.
9.手動減圧失敗は圧縮解除-FAILURE命令を使用してトリガされます。
If a decompression failure occurs when decompressing a message then the UDVM informs the dispatcher and takes no further action. It is the responsibility of the dispatcher to decide how to cope with the decompression failure. In general a dispatcher SHOULD discard the compressed message (or the compressed stream if the transport is stream-based) and any decompressed data that has been outputted but not yet passed to the application.
メッセージを解凍する際に減圧障害が発生した場合、UDVMは、ディスパッチャに通知し、以降のアクションを実行しません。解凍の失敗に対処する方法を決定するために、ディスパッチャの責任です。そして出力まだアプリケーションに渡されませんされた任意の展開データ（トランスポートストリームベースである場合、または圧縮ストリーム）一般に、ディスパッチャは、圧縮されたメッセージを破棄すべきです。
The UDVM currently understands 36 instructions, chosen to support the widest possible range of compression algorithms with the minimum possible overhead.
UDVMは現在、最小限のオーバーヘッドで圧縮アルゴリズムの可能な限り広い範囲をサポートするために選ばれた36個の命令を、理解します。
Figure 11 lists the different instructions and the bytecode values used to encode the instructions. The cost of each instruction in UDVM cycles is also given:
11リスト異なる命令と命令を符号化するために使用されるバイトコード値を図。 UDVMサイクルにおける各命令のコストも与えられます。
Instruction: Bytecode value: Cost in UDVM cycles:
命令：バイトコード値：UDVMサイクルにおけるコスト：
DECOMPRESSION-FAILURE 0 1 AND 1 1 OR 2 1 NOT 3 1 LSHIFT 4 1 RSHIFT 5 1 ADD 6 1 SUBTRACT 7 1 MULTIPLY 8 1 DIVIDE 9 1 REMAINDER 10 1 SORT-ASCENDING 11 1 + k * (ceiling(log2(k)) + n) SORT-DESCENDING 12 1 + k * (ceiling(log2(k)) + n) SHA-1 13 1 + length LOAD 14 1 MULTILOAD 15 1 + n PUSH 16 1 POP 17 1 COPY 18 1 + length COPY-LITERAL 19 1 + length COPY-OFFSET 20 1 + length MEMSET 21 1 + length JUMP 22 1 COMPARE 23 1 CALL 24 1 RETURN 25 1 SWITCH 26 1 + n CRC 27 1 + length INPUT-BYTES 28 1 + length INPUT-BITS 29 1 INPUT-HUFFMAN 30 1 + n STATE-ACCESS 31 1 + state_length STATE-CREATE 32 1 + state_length STATE-FREE 33 1 OUTPUT 34 1 + output_length END-MESSAGE 35 1 + state_length
圧縮解除-FAILURE 0 1 1 1 OR 2 1 NOT 3 1 LSHIFT 4 1 RSHIFT 5 1 ADD 6 1 SUBTRACT 7 1 MULTIPLY 8 1 DIVIDE 9 1 REMAINDER 10 1 SORT-ASCENDING 11 1 + K *（天井（LOG2（K） ）+ N）SORT-DESCENDING 12 1 + K *（天井（LOG2（K））+ n）はSHA-1 13 1 +長LOAD 14 1 MULTILOAD 15 1 + N PUSH 16 1 POP 17 1 COPY 18 1 +長COPY -literal 19 1 +長COPYオフセット20 1 +長さのmemset 21 1 +長JUMP 22 1 23 1 CALL 24 1 RETURN 25 1スイッチ26 1 + N CRC 27 1 +長入力バイト28 1 +長入力ビットを比較します29 1 INPUT-ハフマン30 1 + N STATE-ACCESS 31 1 + state_length 32 1 + state_length STATE-FREE 33 1 OUTPUT 34 1 + OUTPUT_LENGTH END-MESSAGE 35 1 + state_lengthをSTATE-CREATE
Figure 11: UDVM instructions and corresponding bytecode values
図11：UDVMインストラクションと対応するバイトコード値
Each UDVM instruction costs a minimum of 1 UDVM cycle. Certain instructions may cost additional cycles depending on the values of the instruction operands. Named variables in the cost expressions refer to the values of the instruction operands with these names.
各UDVM命令は1つのUDVMサイクルの最小値がかかります。特定の命令は、命令のオペランドの値に応じて、追加のサイクルを要するかもしれません。コスト式の名前付き変数は、これらの名前を持つ命令のオペランドの値を参照してください。
Note that for the SORT instructions, the formula ceiling(log2(k)) calculates the smallest value i such that k <= 2^i.
私は、そのK SORT手順について、式天井（LOG2（K））が最小値を算出することに注意してください<= 2 ^ I。
The UDVM instruction set offers a mix of low-level and high-level instructions. The high-level instructions can all be emulated using combinations of low-level instructions, but given a choice it is generally preferable to use a single instruction rather than a large number of general-purpose instructions. The resulting bytecode will be more compact (leading to a higher overall compression ratio) and decompression will typically be faster because the implementation of the high-level instructions can be more easily optimized.
UDVM命令セットは、低レベルと高レベル命令のミックスを提供しています。ハイレベルの命令は、すべてのローレベル命令の組合せを使用してエミュレートされ、単一の命令ではなく、汎用命令の多くを使用することが一般的に好ましい選択肢を与えることができます。得られたバイトコードは、（より高い全体的な圧縮比をもたらす）よりコンパクトになり、ハイレベル命令の実装はより容易に最適化することができるので、減圧は、典型的に速くなります。
All instructions are encoded as a single byte to indicate the instruction type, followed by 0 or more bytes containing the operands required by the instruction. The instruction specifies which of the four operand types of Section 8.5 is used in each case. For example the ADD instruction is followed by two operands:
すべての命令は、命令によって必要とされるオペランドを含む0以上のバイトに続く、命令の種類を示すために単一のバイトとして符号化されます。命令は、それぞれの場合に使用されるセクション8.5の4つのオペランドタイプを指定します。例えば、ADD命令は二つのオペランドが続きます。
ADD ($operand_1, %operand_2)
ADD（$ operand_1、％のoperand_2）
When converted into bytecode the number of bytes required by the ADD instruction depends on the value of each operand, and whether the multitype operand contains the operand value itself or a memory address where the actual value of the operand can be found.
バイトコードに変換されるときADD命令によって必要とされるバイト数は各オペランドの値に依存し、マルチタイプのオペランドはオペランド値自体又はオペランドの実際の値を見つけることができるメモリアドレスが含まれているかどうか。
Each instruction is explained in more detail below.
各命令は、以下に詳細に説明されます。
Whenever the description of an instruction uses the expression "and then", the intended semantics is that the effect explained before "and then" is completed before work on the effect explained after the "and then" is commenced.
命令の記述は「当時と」という表現を使用するたびに、意図した意味は効果が前に説明した「とし、」「とし、」開始された後に効果の作業を説明する前に完了していることです。
The following instructions provide a number of mathematical operations including bit manipulation, arithmetic and sorting.
以下の手順は、ビット操作、算術およびソートなどの数学的操作の数を提供します。
The AND, OR, NOT, LSHIFT and RSHIFT instructions provide simple bit manipulation on 2-byte words.
AND、OR、NOT、LSHIFTとRSHIFT命令は、2バイトの単語に簡単なビット操作を提供します。
AND ($operand_1, %operand_2) OR ($operand_1, %operand_2) NOT ($operand_1) LSHIFT ($operand_1, %operand_2) RSHIFT ($operand_1, %operand_2)
AND（$ operand_1、％のoperand_2）OR（$ operand_1、％のoperand_2）NOT（$ operand_1）LSHIFT（$ operand_1、％のoperand_2）RSHIFT（$ operand_1、％のoperand_2）
After the operation is complete, the value of the first operand is overwritten with the result. (Note that since this operand is a reference, it is the 2-byte word at the memory address specified by the operand that is overwritten.)
操作が完了した後、最初のオペランドの値が結果に上書きされます。 （このオペランドを基準であるので、それが上書きされるオペランドで指定されたメモリアドレスの2バイトのワードであることに注意してください。）
The precise definitions of LSHIFT and RSHIFT are given below. Note that m and n are the 2-byte values encoded by the operands, and that floor(x) calculates the largest integer not greater than x:
LSHIFTとRSHIFTの正確な定義は以下の通りです。なお、mおよびnはオペランドによってコードされる2バイトの値で、そのフロア（x）はxより大きくない最大の整数を算出します。
LSHIFT (m, n) := m * 2^n (modulo 2^16) RSHIFT (m, n) := floor(m / 2^n)
LSHIFT（M、N）= M * 2 ^ N（モジュロ2 ^ 16）RSHIFT（M、N）=フロア（M / 2 ^ N）
The ADD, SUBTRACT, MULTIPLY, DIVIDE and REMAINDER instructions perform arithmetic on 2-byte words.
ADD、SUBTRACT、乗算、除算、残りの命令は、2バイトワードで演算を実行します。
ADD ($operand_1, %operand_2) SUBTRACT ($operand_1, %operand_2) MULTIPLY ($operand_1, %operand_2) DIVIDE ($operand_1, %operand_2) REMAINDER ($operand_1, %operand_2)
MULTIPLY（$ operand_1、％のoperand_2）（$ operand_1、％のoperand_2）SUBTRACT（$ operand_1、％のoperand_2）を追加DIVIDE（$ operand_1、％のoperand_2）REMAINDER（$ operand_1、％のoperand_2）
After the operation is complete, the value of the first operand is overwritten with the result.
操作が完了した後、最初のオペランドの値が結果に上書きされます。
The precise definition of each instruction is given below:
各命令の正確な定義は以下のとおりであります：
ADD (m, n) := m + n (modulo 2^16) SUBTRACT (m, n) := m - n (modulo 2^16) MULTIPLY (m, n) := m * n (modulo 2^16) DIVIDE (m, n) := floor(m / n) REMAINDER (m, n) := m - n * floor(m / n)
= M×n個（モジュロ2 ^ 16 - ：= M + N（モジュロ2 ^ 16）SUBTRACT（M、N）：N（モジュロ2 ^ 16）MULTIPLY（M、N）=（M、N）を追加）DIVIDE（M、N）=フロア（M / N）余り（M、N）= M - N *床（M / N）
Decompression failure occurs if a DIVIDE or REMAINDER instruction encounters an operand_2 that is zero.
DIVIDE又はREMAINDER命令がゼロであるoperand_2に遭遇した場合解凍エラーが発生します。
The SORT-ASCENDING and SORT-DESCENDING instructions sort lists of 2- byte words.
SORT-ASCENDINGおよびSORT-DESCENDING命令は2つのバイトの単語のリストを並べ替えます。
SORT-ASCENDING (%start, %n, %k) SORT-DESCENDING (%start, %n, %k)
SORT-昇順（％開始、％N、％のK）SORT-降順（％開始、％N、％のK）
The start operand specifies the starting memory address of the block of data to be sorted.
スタートオペランドはソートするデータのブロックの開始メモリアドレスを指定します。
The block of data itself is divided into n lists each containing k 2-byte words. The SORT-ASCENDING instruction applies a certain permutation to the lists, such that the first list is sorted into ascending order (treating each 2-byte word as an unsigned integer). The same permutation is applied to all n lists, so lists other than the first will not necessarily be sorted into order.
データ自体のブロックは各々K 2バイトの単語を含むn個のリストに分割されています。 SORT-上昇命令は、最初のリストは、（符号なし整数として各2バイトワードを処理する）昇順にソートされるように、リストに特定の順列を適用します。最初以外のリストが必ずしも順序にソートされないように同一の順列は、全てのN個のリストに適用されます。
In the case that two words have the same value, the original ordering of the list is preserved.
二つの単語が同じ値を持っている場合には、リストの元の順序は保持されます。
For example, the first list might contain a set of integers to be sorted whilst the second list might be used to keep track of where the integers appear in the sorted list:
例えば、最初のリストは、第二のリストが整数でソートされたリストに表示される場所を追跡するために使用されるかもしれない一方でソートする整数の集合が含まれる場合があります。
Before sorting After sorting
ソート後、ソートする前に
List 1 List 2 List 1 List 2
リスト1つのリスト2リスト1つのリスト2
8 1 1 2 1 2 1 3 1 3 3 4 3 4 8 1
８ １ １ ２ １ ２ １ ３ １ ３ ３ ４ ３ ４ ８ １
The SORT-DESCENDING instruction behaves as above, except that the first list is sorted into descending order.
SORT-下降命令は、最初のリストを降順にソートされていることを除いて、上記のように振る舞います。
The SHA-1 instruction calculates a 20-byte SHA-1 hash [RFC-3174] over the specified area of UDVM memory.
SHA-1命令はUDVMメモリの指定された領域上に20バイトのSHA-1ハッシュ[RFC-3174]を算出します。
SHA-1 (%position, %length, %destination)
SHA-1（％位置、％の長さ、％先）
The position and length operands specify the starting memory address and the length of the byte string over which the SHA-1 hash is calculated. Byte copying rules are enforced as per Section 8.4.
位置と長さのオペランドは、開始メモリアドレスとSHA-1ハッシュが計算されるバイト文字列の長さを指定します。バイトコピー規則はセクション8.4に従って実施されます。
The destination operand gives the starting address to which the resulting 20-byte hash will be copied. Byte copying rules are enforced as above.
デスティネーション・オペランドは、結果として得られる20バイトのハッシュをコピーする先の開始アドレスを与えます。バイトコピー規則は、上記のように適用されます。
The following instructions are used to set up the UDVM memory, and to copy byte strings from one memory location to another.
以下の手順は、UDVMメモリを設定するには、もう1つのメモリ位置からバイト文字列をコピーするために使用されています。
The LOAD instruction sets a 2-byte word to a certain specified value. The format of a LOAD instruction is as follows:
LOAD命令は、特定の指定された値に2バイトワードを設定します。次のようにLOAD命令の形式は次のとおりです。
LOAD (%address, %value)
LOAD（％アドレス、％値）
The first operand specifies the starting address of a 2-byte word, whilst the second operand specifies the value to be loaded into this word. As usual, MSBs are stored before LSBs in the UDVM memory.
第2オペランドは、このワードにロードされる値を指定しながら、最初のオペランドは、2バイトワードの開始アドレスを指定します。いつものように、MSBはUDVMメモリ内のLSB前に保存されます。
The MULTILOAD instruction sets a contiguous block of 2-byte words in the UDVM memory to specified values.
MULTILOAD命令は、指定された値にUDVMメモリ内の2バイトワードの連続ブロックを設定します。
MULTILOAD (%address, #n, %value_0, ..., %value_n-1)
MULTILOAD（％アドレス、＃N、％VALUE_0、...、％value_n-1）
The first operand specifies the starting address of the contiguous 2-byte words, whilst the operands value_0 through to value_n-1 specify the values to load into these words (in the same order as they appear in the instruction).
オペランドがvalue_n-1に（それらが命令に現れるのと同じ順序で）これらの単語にロードする値を指定する貫通VALUE_0ながら、最初のオペランドは、連続する2バイト・ワードの開始アドレスを指定します。
Decompression failure occurs if the set of 2-byte words set by the instruction would overlap the memory locations held by the instruction (including its operands) itself, i.e., if the instruction would be self-modifying. (This restriction makes it simpler to implement MULTILOAD step-by-step instead of having to decode all operands before being able to copy data, as is implied by the conceptual model of instruction execution.)
命令は自己書き換えであるかどう命令によって設定された2バイトワードのセットは、すなわち、（そのオペランドを含む）命令自体によって保持されるメモリ位置に重なるかどう減圧障害が発生しました。 （命令実行の概念モデルによって示唆されるように、この制限は、それが単純な代わりのデータをコピーすることができる前に、すべてのオペランドを復号化するのでMULTILOADステップバイステップを実現することができます。）
The PUSH and POP instructions read from and write to the UDVM stack (as defined in Section 8.3).
PUSHおよびPOP命令から読み出され（セクション8.3で定義されるように）UDVMスタックに書き込みます。
PUSH (%value) POP (%address)
PUSH（％値）POP（％アドレス）
The PUSH instruction pushes the value specified by its operand on the stack.
PUSH命令はスタック上のオペランドで指定された値をプッシュします。
The POP instruction pops a value from the stack and then copies the value to the specified memory address. (Note that the expression "and then" implies that the copying of the value is inconsequential for the stack operation itself, which happens beforehand.)
POP命令は、指定されたメモリアドレスに値をスタックから値をポップし、次いでコピー。 （その表現に注意「とし、」値のコピーが予め起こるスタック操作自体について重要ではないことを意味します。）
See Section 8.3 for possible error conditions.
可能性のあるエラー条件については、セクション8.3を参照してください。
The COPY instruction is used to copy a string of bytes from one part of the UDVM memory to another.
COPY命令はUDVMメモリの一部から別のバイトの文字列をコピーするために使用されます。
COPY (%position, %length, %destination)
COPY（％位置、％の長さ、％先）
The position operand specifies the memory address of the first byte in the string to be copied, and the length operand specifies the number of bytes to be copied.
位置オペランドがコピーされる文字列内の最初のバイトのメモリアドレスを指定し、長オペランドをコピーするバイト数を指定します。
The destination operand gives the address to which the first byte in the string will be copied.
デスティネーション・オペランドが文字列の最初のバイトがコピーされる先のアドレスを提供します。
Byte copying is performed as per the rules of Section 8.4.
バイトコピーはセクション8.4の規則に従って行われます。
A modified version of the COPY instruction is given below:
コピー指示の修正バージョンを以下に示します：
COPY-LITERAL (%position, %length, $destination)
COPYリテラル（％位置、％の長さ、$先）
The COPY-LITERAL instruction behaves as a COPY instruction except that after copying is completed, the value of the destination operand is replaced by the address to which the next byte of data would be copied. More precisely it is replaced by the value n, derived as per Section 8.4 with m set to the destination address of the last byte to be copied, if any (i.e., if the value of the length operand is zero, the value of the destination operand is not changed).
COPYリテラル命令は、コピーが完了した後に、デスティネーション・オペランドの値は、データの次のバイトがコピーされる先のアドレスによって置き換えられることを除いてコピー指示として振る舞います。もしあれば（すなわち、長オペランドの値が先の値、ゼロであれば、より正確には、コピーされる最後のバイトの宛先アドレスにm個のセットでセクション8.4に従って導出さ、値nに置き換えられオペランド）は変更されません。
A further version of the COPY-LITERAL instruction is given below:
COPYリテラル命令のさらなるバージョンを以下に示します：
COPY-OFFSET (%offset, %length, $destination)
COPY-OFFSET（オフセット％、％長、$先）
The COPY-OFFSET instruction behaves as a COPY-LITERAL instruction except that an offset operand is given instead of a position operand.
COPYオフセット命令オフセットオペランドはなく、位置オペランドを説明することを除いて、COPYリテラル命令として振る舞います。
To derive the value of the position operand, starting at the memory address specified by destination, the UDVM counts backwards a total of offset memory addresses.
位置オペランドの値を導出するには、目的地によって指定されたメモリアドレスから始まる、UDVMは後方オフセットメモリアドレスの合計をカウントします。
If the memory address specified in byte_copy_left is reached, the next memory address is taken to be (byte_copy_right - 1) modulo 2^16.
モジュロ2 ^ 16 - byte_copy_leftで指定されたメモリアドレスに達した場合、次のメモリアドレスは、（1 byte_copy_right）とします。
The COPY-OFFSET instruction then behaves as a COPY-LITERAL instruction, taking the value of the position operand to be the last memory address reached in the above step.
COPYオフセット命令は、次いで上記の工程に達する最後のメモリアドレスに位置オペランドの値をとる、COPYリテラル命令として振る舞います。
The MEMSET instruction initializes an area of UDVM memory to a specified sequence of values. The format of a MEMSET instruction is as follows:
memsetの命令は、値の指定されたシーケンスにUDVMメモリの領域を初期化します。次のようにmemsetの命令の形式は次のとおりです。
MEMSET (%address, %length, %start_value, %offset)
memset（％アドレス、％の長さは、％START_VALUE、％オフセット）
The sequence of values used by the MEMSET instruction is specified by the following formula:
memsetの命令によって使用される値のシーケンスは、次の式で指定されます。
Seq[n] := (start_value + n * offset) modulo 256
配列[N]：=（START_VALUE + N *オフセット）モジュロ256
The values Seq[0] to Seq[length - 1] inclusive are each interpreted as a single byte, and then concatenated to form a byte string where the first byte has value Seq[0], the second byte has value Seq[1] and so on up to the last byte which has value Seq[length - 1].
値配列の配列[0] [長さ - 1]までは、各単一バイトとして解釈し、次に最初のバイト値配列[0]、第二のバイト値配列[1]を有し有するバイトストリングを形成するために連結されています等値配列[長さ - 1]を有する最後のバイトまで。
The string is then byte copied into the UDVM memory beginning at the memory address specified as an operand to the MEMSET instruction, obeying the rules of Section 8.4. (Note that the byte string may overwrite the MEMSET instruction or its operands; as explained in Section 8.5, the MEMSET instruction must be executed as if the original operands were still in place in the UDVM memory.)
文字列は、セクション8.4の規則に従う、memsetの命令へのオペランドとして指定されたメモリアドレスから始まるUDVMメモリにコピーバイトです。 （バイト列は、memsetを命令またはそのオペランドを上書きすることができることに留意されたい。8.5節で説明したように、元のオペランドがUDVMメモリ内の所定の位置に残っていたかのように、memsetの命令が実行されなければなりません。）
The following instructions alter the flow of UDVM code. Each instruction jumps to one of a number of memory addresses based on a certain specified criterion.
次の手順では、UDVMコードの流れを変えます。各命令は、ある特定の基準に基づいてメモリアドレスのうちの1つにジャンプします。
Note that certain I/O instructions (see Section 9.4) can also alter program flow.
特定のI / O命令ことに注意してください（9.4節を参照）、プログラムの流れを変えることができます。
The JUMP instruction moves program execution to the specified memory address.
JUMP命令は、指定されたメモリアドレスにプログラムの実行を移動します。
JUMP (@address)
JUMP（@address）
Decompression failure occurs if the value of the address operand lies beyond the overall UDVM memory size.
アドレスオペランドの値が全体的なUDVMメモリサイズを超える場合は解凍障害が発生しました。
The COMPARE instruction compares two operands and then jumps to one of three specified memory addresses depending on the result.
比較命令は、2つのオペランドを比較し、その結果に応じて3つの指定されたメモリアドレスの1つにジャンプします。
COMPARE (%value_1, %value_2, @address_1, @address_2, @address_3)
COMPARE（％値_1、_2％、@ ADDRESS_1、@ address_2、@ address_3）
If value_1 < value_2 then the UDVM continues instruction execution at the memory address specified by address 1. If value_1 = value_2 then it jumps to the address specified by address_2. If value_1 > value_2 then it jumps to the address specified by address_3.
値_1 <_2なら、UDVMは値_1 = _2それはaddress_2で指定されたアドレスにジャンプする場合は、アドレス1で指定されたメモリアドレスの命令の実行を継続します。値_1> _2が、それはaddress_3で指定されたアドレスにジャンプします。
The CALL and RETURN instructions provide support for compression algorithms with a nested structure.
CALLとRETURN命令は、入れ子構造の圧縮アルゴリズムをサポートしています。
CALL (@address) RETURN
CALL（@address）RETURN
Both instructions use the UDVM stack of Section 8.3. When the UDVM reaches a CALL instruction, it finds the memory address of the instruction immediately following the CALL instruction and pushes this 2-byte value on the stack, ready for later retrieval. It then continues instruction execution at the memory address specified by the address operand.
どちらの命令は、8.3節のUDVMスタックを使用します。 UDVMは、CALL命令に到達すると、それは直ちにCALL命令に続く命令のメモリアドレスを検索し、後の検索のために準備ができてスタック上のこの2バイトの値を、プッシュします。これは、アドレスのオペランドで指定されたメモリアドレスの命令の実行を継続します。
When the UDVM reaches a RETURN instruction it pops a value from the stack and then continues instruction execution at the memory address just popped.
UDVMはRETURN命令に到達すると、それがスタックから値をポップしてからちょうどポップメモリアドレスの命令の実行を継続します。
See Section 8.3 for error conditions.
エラー条件については、セクション8.3を参照してください。
The SWITCH instruction performs a conditional jump based on the value of one of its operands.
切替指示は、そのオペランドの1つの値に基づく条件付きジャンプを実行します。
SWITCH (#n, %j, @address_0, @address_1, ... , @address_n-1)
SWITCH（＃N、％jを、@ address_0、@ ADDRESS_1、...、@ address_n-1）
When a SWITCH instruction is encountered the UDVM reads the value of j. It then continues instruction execution at the address specified by address j.
切替指示が検出されるとUDVMは、jの値を読み取ります。その後、アドレスjで指定したアドレスの命令の実行を継続します。
Decompression failure occurs if j specifies a value of n or more, or if the address lies beyond the overall UDVM memory size.
jがn以上の値を指定した場合、またはアドレスが、全体的なUDVMメモリサイズを超える場合は解凍障害が発生しました。
The CRC instruction verifies a string of bytes using a 2-byte CRC.
CRC命令は、2バイトのCRCを使用してバイトの文字列を検証します。
CRC (%value, %position, %length, @address)
CRC（％値、％位置％の長さ、@address）
The actual CRC calculation is performed using the generator polynomial x^16 + x^12 + x^5 + 1, which coincides with the 2-byte Frame Check Sequence (FCS) of PPP [RFC-1662].
実際のCRC計算は生成多項式を用いて行われるX ^ 16 + X ^ 12 + X ^ PPP [RFC-1662]の2バイトのフレーム・チェック・シーケンス（FCS）と一致5 + 1、。
The position and length operands define the string of bytes over which the CRC is evaluated. Byte copying rules are enforced as per Section 8.4.
位置と長さのオペランドは、CRCが評価される上バイトの文字列を定義します。バイトコピー規則はセクション8.4に従って実施されます。
The CRC value is computed exactly as defined for the 16-bit FCS calculation in [RFC-1662].
[RFC-1662]の16ビットFCS計算のために定義されるようにCRC値が正確に計算されます。
The value operand contains the expected integer value of the 2-byte CRC. If the calculated CRC matches the expected value then the UDVM continues instruction execution at the following instruction. Otherwise the UDVM jumps to the memory address specified by the address operand.
値オペランドは、2バイトのCRCの期待される整数値が含まれています。計算されたCRCが期待値と一致した場合は、UDVMは、次の命令で、命令の実行を継続します。それ以外の場合はUDVMはアドレスオペランドで指定したメモリアドレスにジャンプします。
The following instructions allow the UDVM to interface with its environment. Note that in the overall SigComp architecture all of these interfaces pass to the decompressor dispatcher or to the state handler.
次の手順では、UDVMは、その環境とのインタフェースを可能にします。全体のSigCompアーキテクチャで、これらのインタフェースの全てがデコンプレッサディスパッチャまたは状態ハンドラに渡すことに留意されたいです。
The DECOMPRESSION-FAILURE instruction triggers a manual decompression failure. This is useful if the UDVM bytecode discovers that it cannot successfully decompress the message (e.g., by using the CRC instruction).
圧縮解除-FAILURE命令は手動解凍失敗をトリガします。 UDVMバイトコードは、それが成功（CRC命令を使用して、例えば）メッセージを解凍することができないことを発見した場合に便利です。
This instruction has no operands.
この命令は、オペランドはありません。
The INPUT-BYTES instruction requests a certain number of bytes of compressed data from the decompressor dispatcher.
INPUTバイト命令は、デコンプレッサディスパッチャからの圧縮データのバイトの一定数を要求します。
INPUT-BYTES (%length, %destination, @address)
INPUTバイト（％の長さ、％宛先、@address）
The length operand indicates the requested number of bytes of compressed data, and the destination operand specifies the starting memory address to which they should be copied. Byte copying is performed as per the rules of Section 8.4.
長オペランドは、圧縮されたデータの要求されたバイト数を示し、デスティネーション・オペランドは、それらがコピーされなければならないために開始メモリアドレスを指定します。バイトコピーはセクション8.4の規則に従って行われます。
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はアドレスオペランドで指定されたアドレスにプログラムの実行を移動します。
If the INPUT-BYTES is encountered after an INPUT-BITS or an INPUT-HUFFMAN instruction has been used, and the dispatcher currently holds a fraction of a byte, then the fraction MUST be discarded before any data is passed to the UDVM. The first byte to be passed is the byte immediately following the discarded data.
INPUT-BYTESがINPUT-BITSまたはINPUT-ハフマン命令の後に遭遇した場合に使用されてきた、とディスパッチャは、現在のバイトの割合を保持している任意のデータをUDVMに渡される前に、その端数は捨てなければなりません。渡される最初のバイトはすぐに廃棄されたデータを、次のバイトです。
The INPUT-BITS instruction requests a certain number of bits of compressed data from the decompressor dispatcher.
INPUTビット命令は、デコンプレッサディスパッチャからの圧縮データのビットの特定の数を要求します。
INPUT-BITS (%length, %destination, @address)
INPUT-BITS（％の長さ、％宛先、@address）
The length operand indicates the requested number of bits. Decompression failure occurs if this operand does not lie between 0 and 16 inclusive.
長オペランドは、ビットの要求された数を示します。このオペランドは、0と16包括の間に存在しない場合、解凍の失敗が発生します。
The destination operand specifies the memory address to which the compressed data should be copied. Note that the requested bits are interpreted as a 2-byte integer ranging from 0 to 2^length - 1, as explained in Section 8.2.
デスティネーション・オペランドが圧縮されたデータをコピーすべきメモリアドレスを指定します。セクション8.2で説明したように、1 - 要求されたビットは0から2 ^長さの範囲の2バイト整数として解釈されることに留意されたいです。
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 INPUT-HUFFMAN instruction requests a variable number of bits of compressed data from the decompressor dispatcher. The instruction initially requests a small number of bits and compares the result against a certain criterion; if the criterion is not met, then additional bits are requested until the criterion is achieved.
INPUT - ハフマン指示は、デコンプレッサディスパッチャからの圧縮データのビットの可変数を要求します。命令は、最初は少ないビット数を要求し、特定の基準に対して結果を比較します。基準が満たされない場合の基準が達成されるまで、追加のビットが要求されます。
The INPUT-HUFFMAN instruction is followed by three mandatory operands plus n additional sets of operands. Every additional set contains four operands as shown below:
INPUT-ハフマン命令は3つの必須のオペランドプラスオペランドのN個の追加の組が続きます。以下に示すように、すべての追加のセットが4つのオペランドが含まれています。
INPUT-HUFFMAN (%destination, @address, #n, %bits_1, %lower_bound_1, %upper_bound_1, %uncompressed_1, ... , %bits_n, %lower_bound_n, %upper_bound_n, %uncompressed_n)
INPUT-ハフマン（％宛先、@address、#N、％bits_1、％lower_bound_1、％upper_bound_1、％uncompressed_1、...、％bits_n、％lower_bound_n、％upper_bound_n、％uncompressed_n）
Note that if n = 0 then the INPUT-HUFFMAN instruction is ignored and program execution resumes at the following instruction. Decompression failure occurs if (bits_1 + ... + bits_n) > 16.
N = 0の場合INPUT-ハフマン命令が無視されている場合、プログラムの実行は次の命令から再開することに注意してください。 （bits_1 + ... + bits_n）> 16あれば減圧障害が発生しました。
In all other cases, the behavior of the INPUT-HUFFMAN instruction is defined below:
他のすべての場合において、INPUT-ハフマン命令の動作は以下に定義されます。
2. Request bits_j compressed bits. Interpret the returned bits as an integer k from 0 to 2^bits_j - 1, as explained in Section 8.2.
圧縮されたビットbits_j 2.リクエスト。セクション8.2で説明したように、1 - 0の2 ^ bits_jの整数kとして返されたビットを解釈します。
4. If data is requested that lies beyond the end of the SigComp message, terminate the INPUT-HUFFMAN instruction and move program execution to the memory address specified by the address operand.
4.データがのSigCompメッセージの終わりを超えて存在するように要求された場合、INPUT-ハフマン命令を終了し、アドレスオペランドによって指定されたメモリアドレスにプログラムの実行を移動します。
5. If (H < lower_bound_j) or (H > upper_bound_j) then set j := j + 1. Then go back to Step 2, unless j > n in which case decompression failure occurs.
5. IF（H <lower_bound_j）または（H> upper_bound_j）を設定J = J + 1そして場合解凍障害が発生しない限り、J> Nた、ステップ2に戻ります。
6. Copy (H + uncompressed_j - lower_bound_j) modulo 2^16 to the memory address specified by the destination operand.
6.コピー（H + uncompressed_j - lower_bound_j）デスティネーション・オペランドで指定されたメモリアドレスにモジュロ2 ^ 16。
The STATE-ACCESS instruction retrieves some previously stored state information.
ステートアクセス命令は、いくつかの以前に格納された状態情報を取得します。
STATE-ACCESS (%partial_identifier_start, %partial_identifier_length, %state_begin, %state_length, %state_address, %state_instruction)
STATE-ACCESS（％のpartial_identifier_start％のpartial_identifier_length％のSTATE_BEGIN％のstate_length％のstate_address、％のstate_instruction）
The partial_identifier_start and partial_identifier_length operands specify the location of the partial state identifier used to retrieve the state information. This identifier has the same function as the partial state identifier transmitted in the SigComp message as per Section 7.2.
partial_identifier_startとpartial_identifier_lengthオペランドは、状態情報を取得するために使用される部分状態識別子の位置を指定します。この識別子は、セクション7.2に従ってのSigCompメッセージで送信部分の状態識別子と同じ機能を有しています。
Decompression failure occurs if partial_identifier_length does not lie between 6 and 20 inclusive. Decompression failure also occurs if no state item matching the partial state identifier can be found, if more than one state item matches the partial identifier, or if partial_identifier_length is less than the minimum_access_length of the matched state item. Otherwise, a state item is returned from the state handler.
partial_identifier_lengthは6と20包括の間に存在しない場合、解凍の失敗が発生します。複数の状態項目が部分的識別子と一致する場合、またはpartial_identifier_lengthが一致状態項目のminimum_access_length未満であれば、部分的状態識別子に一致する状態項目が、見つからない場合は解凍の失敗が発生します。それ以外の場合は、状態項目は状態ハンドラから返されます。
If any of the operands state_address, state_instruction or state_length is set to 0 then its value is taken from the returned item of state instead.
オペランドstate_address、state_instruction又はstate_lengthのいずれかを0に設定されている場合、その値は代わりに状態の戻された項目から取られます。
Note that when calculating the number of UDVM cycles the STATE-ACCESS instruction costs (1 + state_length) cycles. The value of state_length MUST be taken from the returned item of state in the case that the state_length operand is set to 0.
UDVMサイクルの数を計算するステートアクセス命令コスト（1 + state_length）サイクルことに留意されたいです。 state_lengthの値はstate_lengthオペランドが0に設定された場合に状態の返された項目から取らなければなりません。
The state_begin and state_length operands define the starting byte and number of bytes to copy from the state_value contained in the returned item of state. Decompression failure occurs if bytes are copied from beyond the end of the state_value. Note that decompression failure will always occur if the state_length operand is set to 0 but the state_begin operand is non-zero.
STATE_BEGINとstate_lengthオペランドは状態の戻された項目に含まstate_valueからコピーするバイトの開始バイトと数を定義します。バイトはstate_valueの終わりを越えてからコピーされた場合に減圧障害が発生しました。 state_lengthオペランドが0に設定されますがSTATE_BEGINオペランドがゼロでされた場合には、減圧障害が常に発生します注意してください。
The state_address operand contains a UDVM memory address. The requested portion of the state_value is byte copied to this memory address using the rules of Section 8.4.
state_addressオペランドはUDVMメモリアドレスが含まれています。 state_valueの要求された部分は、セクション8.4の規則を使用して、このメモリアドレスにコピーされたバイトです。
Program execution then resumes at the memory address specified by state_instruction, unless this address is 0 in which case program execution resumes at the next instruction following the STATE-ACCESS instruction. Note that the latter case only occurs if both the state_instruction operand and the state_instruction value from the requested state are set to 0.
このアドレスは、プログラムの実行状態アクセス命令に続く次の命令で再開される場合に0でない限り、プログラムの実行は、次いで、state_instructionによって指定されたメモリアドレスで再開します。要求された状態からstate_instructionオペランドとstate_instruction値の両方が0に設定されている場合、後者の場合にのみ発生することに注意してください。
The STATE-CREATE instruction requests the creation of a state item at the receiving endpoint.
STATE-CREATE指示が受信エンドポイントで状態項目の作成を依頼します。
STATE-CREATE (%state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
（％のstate_length％のstate_address％のstate_instruction％のminimum_access_length、％のstate_retention_priority）STATE-CREATE
Note that the new state item cannot be created until a valid compartment identifier has been returned by the application. Consequently, when a STATE-CREATE instruction is encountered the UDVM simply buffers the five supplied operands until the END-MESSAGE instruction is reached. The steps taken at this point are described in Section 9.4.9.
有効なコンパートメント識別子は、アプリケーションによって返されるまで、新たな状態項目を作成することができないことに注意してください。 STATE-CREATE命令に遭遇したときにEND-MESSAGE命令が到達するまでその結果、UDVMは単に5つの提供されたオペランドをバッファリング。この時点で採取された手順は、セクション9.4.9で説明されています。
Decompression failure MUST occur if more than four state creation requests are made before the END-MESSAGE instruction is encountered. Decompression failure also occurs if the minimum_access_length does not lie between 6 and 20 inclusive, or if the state_retention_priority is 65535.
以上の4つの状態の作成要求が行われた場合END-MESSAGE命令に遭遇する前に解凍障害が発生しなければなりません。 minimum_access_lengthは6と20との間で包括的に存在しない場合、またはstate_retention_priorityが65535であれば減圧障害も発生します。
The STATE-FREE instruction informs the receiving endpoint that the sender no longer wishes to use a particular state item.
STATE-FREE命令は、送信者がもはや特定の状態項目を使用したい受信エンドポイントに通知します。
STATE-FREE (%partial_identifier_start, %partial_identifier_length)
STATE-FREE（％部分的識別子_start、％部分的識別子の長さ）
Note that the STATE-FREE instruction does not automatically delete a state item, but instead reclaims the memory taken by the state item within a certain compartment, which is generally not known before the END-MESSAGE instruction is reached. So just as for the STATE-CREATE instruction, when a STATE-FREE instruction is encountered the UDVM simply buffers the two supplied operands until the END-MESSAGE instruction is reached. The steps taken at this point are described in Section 9.4.9.
STATE-FREE命令は自動的に状態項目を削除しないことに注意してください、代わりにEND-MESSAGE命令に到達する前に、一般的に知られていない特定のコンパートメント内に状態項目で撮影したメモリを再利用。 END-MESSAGE命令に到達するまで、これだけSTATE-CREATE命令の場合と同様に、STATE-FREE命令が遭遇したときUDVMは単に2つの付属のオペランドをバッファリング。この時点で採取された手順は、セクション9.4.9で説明されています。
Decompression failure MUST occur if more than four state free requests are made before the END-MESSAGE instruction is encountered. Decompression failure also occurs if partial_identifier_length does not lie between 6 and 20 inclusive.
以上の4つの状態の自由の要求が行われた場合END-MESSAGE命令に遭遇する前に解凍障害が発生しなければなりません。 partial_identifier_lengthは6と20包括の間に存在しない場合、解凍の失敗にも発生します。
The OUTPUT instruction provides successfully decompressed data to the dispatcher.
OUTPUT命令は、ディスパッチャに正常に解凍されたデータを提供します。
OUTPUT (%output_start, %output_length)
OUTPUT（％のoutput_start、％のOUTPUT_LENGTH）
The operands define the starting memory address and length of the byte string to be provided to the dispatcher. Note that the OUTPUT instruction can be used to output a partially decompressed message; each time the instruction is encountered it provides a new byte string that the dispatcher appends to the end of any bytes previously passed to the dispatcher via the OUTPUT instruction.
オペランドはディスパッチャに提供されるバイト文字列の開始メモリアドレスと長さを定義します。出力指示を出力する部分解凍メッセージを使用することができることに留意されたいです。命令に遭遇するたびに、それは、ディスパッチャが以前に出力命令を経由してディスパッチャに渡される任意のバイトの最後に追加した新しいバイト文字列を提供します。
The string of data is byte copied from the UDVM memory obeying the rules of Section 8.4.
データの文字列は、セクション8.4の規則に従うUDVMメモリからコピーされたバイトです。
Decompression failure occurs if the cumulative number of bytes provided to the dispatcher exceeds 65536 bytes.
ディスパッチャに提供バイトの累積数が65536バイトを超える場合に減圧障害が発生しました。
Since there is technically a difference between outputting a 0-byte decompressed message, and not outputting a decompressed message at all, the OUTPUT instruction needs to distinguish between the two cases. Thus, if the UDVM terminates before encountering an OUTPUT instruction it is considered not to have outputted a decompressed message. If it encounters one or more OUTPUT instructions, each of which provides 0 bytes of data to the dispatcher, then it is considered to have outputted a 0-byte decompressed message.
0バイトの解凍メッセージを出力し、すべてで解凍メッセージを出力しないとの差が技術的に存在するので、出力命令は、2つのケースを区別する必要があります。このように、UDVMは、それが解凍メッセージを出力していないと考えられる出力命令に遭遇する前に終了した場合。それは、ディスパッチャへのデータの0バイトを提供し、それぞれが1つのまたは複数の出力命令を、遭遇した場合、0バイトの解凍メッセージを出力していると考えられます。
The END-MESSAGE instruction successfully terminates the UDVM and forwards the state creation and state free requests to the state handler together with any supplied feedback data.
END-MESSAGE命令が正常にUDVMを終了し、任意の供給フィードバックデータと共に状態ハンドラへの状態の作成と状態の自由の要求を転送します。
END-MESSAGE (%requested_feedback_location, %returned_parameters_location, %state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
END-MESSAGE（％のrequested_feedback_location％のreturned_parameters_location％のstate_length％のstate_address％のstate_instruction％のminimum_access_length、％のstate_retention_priority）
When the END-MESSAGE instruction is encountered, the decompressor dispatcher indicates to the application that a complete message has been decompressed. The application may return a compartment identifier, which the UDVM forwards to the state handler together with the state creation and state free requests and any supplied feedback data.
END-MESSAGE命令に遭遇すると、デコンプレッサディスパッチャは、完全なメッセージが解凍されたアプリケーションに示します。アプリケーションが一緒の状態の作成と状態の自由を要求し、任意の供給フィードバックデータと状態のハンドラにコンパートメント識別子、UDVMを前方に戻してもよいです。
The actual decompressed message is outputted separately using the OUTPUT instruction; this conserves memory at the UDVM because there is no need to buffer an entire decompressed message before it can be passed to the dispatcher.
実際の減圧メッセージが出力命令を使用して別々に出力されます。それがディスパッチャに渡すことができる前に、全体の解凍メッセージをバッファリングする必要がないので、これはUDVMでメモリを節約します。
The END-MESSAGE instruction may pass up to four state creation requests and up to four state free requests to the state handler. The requests are passed to the state handler in the same order as they are made; in particular it is possible for the state creation requests and the state free requests to be interleaved.
END-MESSAGE命令は、4つの状態の作成要求に渡すと、状態ハンドラに最大4つの状態の自由を要求します。リクエストは、それらが作られているのと同じ順序で状態ハンドラに渡されます。状態の作成要求と状態の自由の要求がインタリーブされるために特にそれが可能です。
The state creation requests are made by the STATE-CREATE instruction. Note however that the END-MESSAGE can make one state creation request itself using the supplied operands. If the specified minimum_access_length does not lie between 6 and 20 inclusive, or if the state_retention_priority is 65535 then the END-MESSAGE instruction fails to make a state creation request of its own (however decompression failure does not occur and the state creation requests made by the STATE-CREATE instruction are still valid).
状態の作成要求はSTATE-CREATE指示で作られています。 END-MESSAGEは、供給されたオペランドを使用して一つの状態作成要求自体を作ることができることに注意してください。指定されたminimum_access_lengthは6と20包括の間に存在しない、またはstate_retention_priorityは65535その後、END-MESSAGE命令は、自身の状態の作成要求を作るために失敗した場合（ただし解凍障害が発生していないとによって作られた状態の作成を要求した場合STATE-CREATE命令）がまだ有効です。
Note that there is a maximum limit of four state creation requests per instance of the UDVM. Therefore, decompression failure occurs if the END-MESSAGE instruction makes a state creation request and four instances of the STATE-CREATE instruction have already been encountered.
UDVMのインスタンスごとに4つの状態の作成要求の最大限界があることに留意されたいです。 END-MESSAGE命令は、状態の作成要求を行い、STATE-CREATE命令の4つのインスタンスが既に遭遇した場合はそのため、減圧障害が発生しました。
When creating a state item it is necessary to give the state_length, state address, state_instruction and minimum_access_length; these are supplied as operands in the STATE-CREATE instruction (or the END-MESSAGE instruction). A complete item of state also requires a state_value and a state_identifier, which are derived as follows:
状態項目を作成する場合にはstate_length、状態アドレス、state_instructionとminimum_access_lengthを与える必要があります。これらは、STATE-CREATE指示（またはEND-MESSAGE命令）におけるオペランドとして供給されます。状態の完全な項目は、以下のように誘導され、state_valueとstate_identifierを必要とします。
The UDVM byte copies a string of state_length bytes from the UDVM memory beginning at state_address (obeying the rules of Section 8.4). This is the state_value.
UDVMバイトコピー（セクション8.4のルールに従う）state_addressから始まるUDVMメモリからstate_lengthバイトの文字列。これはstate_valueです。
The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the byte string formed by concatenating the state_length, state_address, state_instruction, minimum_access_length and state_value (in the order given). This is the state_identifier.
UDVMは、次に（所定の順序で）state_length、state_address、state_instruction、minimum_access_lengthとstate_valueを連結することによって形成されたバイト列上に20バイトのSHA-1ハッシュ[RFC-3174]を算出します。これはstate_identifierです。
The state_retention_priority is not part of the state item itself, but instead determines the order in which state will be deleted when the compartment exceeds its allocated state memory. The state_retention_priority is supplied as an operand in the STATE-CREATE or END-MESSAGE instruction and is passed to the state handler as part of each state creation request.
state_retention_priority状態アイテム自体の一部ではなく、区画が割り当てられた状態メモリを超えたときに状態が削除される順序を決定します。 state_retention_priorityはSTATE-CREATEまたはEND-MESSAGE命令のオペランドとして供給され、各状態の作成要求の一部として、状態ハンドラに渡されます。
The state free requests are made by the STATE-FREE instruction. Each STATE-FREE instruction supplies the values partial_identifier_start and partial_identifier_length; upon reaching the END-MESSAGE instruction these values are used to byte copy a partial state identifier from the UDVM memory. If no state item matching the partial state identifier can be found or if more than one state item in the compartment matches the partial state identifier, then the state free request is ignored (this does not cause decompression failure to occur). Otherwise, the state handler frees the matched state item as specified in Section 6.2.
状態の自由の要求はSTATE-FREE命令で作られています。各STATE-FREE命令は、値のpartial_identifier_startとpartial_identifier_lengthを提供します。 END-MESSAGE命令に達すると、これらの値は、UDVMメモリからパーシャル状態識別子をコピーするバイトするために使用されています。パーシャル状態識別子に一致する状態項目が見つからないか、区画内の複数の状態項目が部分状態識別子と一致する場合、状態フリー要求は無視されている場合（これは減圧障害を発生させません）。そうでなければ、状態ハンドラは、セクション6.2で指定されるようにマッチした状態項目を解放します。
As well as forwarding the state creation and state free requests, the END-MESSAGE instruction may also pass feedback data to the state handler. Feedback data is used to inform the receiving endpoint about the capabilities of the sending endpoint, which can help to improve the overall compression ratio and to reduce the working memory requirements of the endpoints.
同様の状態の生成と状態の自由の要求を転送するよう、END-MESSAGE命令は、状態ハンドラにフィードバックデータを渡すことができます。フィードバックデータは、全体の圧縮率を改善し、エンドポイントのワーキングメモリ要件を減らすのに役立つことができ、送信エンドポイントの機能に関する受信側のエンドポイントに通知するために使用されています。
Two types of feedback data are available: requested feedback and returned feedback. The format of the requested feedback data is given in Figure 12. As outlined in Section 3.2, the requested feedback data can be used to influence the contents of the returned feedback data in the reverse direction.
フィードバックデータの2種類がありますフィードバックを要求し、フィードバックを返していました。セクション3.2に概説されるように要求されたフィードバックデータのフォーマットは図12に与えられ、要求されたフィードバックデータは、逆方向に戻されたフィードバックデータの内容に影響を与えるために使用することができます。
The returned feedback data is itself subdivided into a returned feedback item and a list of returned SigComp parameters. The returned feedback item is of sufficient importance to warrant its own field in the SigComp header as described in Section 7.1. The returned SigComp parameters are illustrated in Figure 13.
返されたフィードバックデータ自体が返されたフィードバック項目と返されたSigCompパラメータのリストに分割されています。返されたフィードバック項目は、セクション7.1に記載したようにSigCompヘッダに独自のフィールドを保証するために十分に重要です。返さのSigCompパラメータは、図13に示されています。
Note that the formats of Figure 12 and Figure 13 are only for local presentation of the feedback data on the interface between the UDVM and state handler. The formats do not mandate any bits on the wire; the compressor can transmit the data in any form provided that it is loaded into the UDVM memory at the correct addresses.
図12と図13のフォーマットは、UDVM状態ハンドラとの間のインターフェイス上のフィードバックデータの局所的な提示のためだけであることに留意されたいです。フォーマットは、ワイヤ上の任意のビットを強制しません。コンプレッサは、それが正しいアドレスでUDVMメモリにロードされていれば、任意の形式でデータを送信することができます。
Moreover, the responsibility for ensuring that feedback data arrives successfully over an unreliable transport lies with the sender. The receiving endpoint always uses the last received value for each field in the feedback data, even if the values are out of date due to packet loss or misordering.
また、フィードバックデータが正常に信頼性の低いトランスポート上で到着することを保証する責任は、送信側です。受信側のエンドポイントは、常に値がパケット損失や誤った順序に古くなっている場合でも、フィードバックデータ内の各フィールドの最後に受信した値を使用しています。
If the requested_feedback_location operand is set to 0, then no feedback request is made; otherwise, it points to the starting memory address of the requested feedback data as shown in Figure 12.
requested_feedback_locationオペランドが0に設定されている場合、何のフィードバック要求は行われません。図12に示すように、それ以外の場合は、要求されたフィードバックデータの開始メモリアドレスを指し示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| |
: requested feedback item : if Q = 1
| |
+---+---+---+---+---+---+---+---+
Figure 12: Format of requested feedback data
図12：要求されたフィードバックデータのフォーマット
The reserved bits may be used in future versions of SigComp, and are set to 0 in Version 0x01. Non-zero values should be ignored by the receiving endpoint.
予約ビットは、SigCompの将来のバージョンで使用することができ、バージョン0×01を0に設定されています。非ゼロ値は、受信エンドポイントによって無視されるべきです。
The Q-bit indicates whether a requested feedback item is present or not. The compressor can set the requested feedback item to an arbitrary value, which will then be transmitted unmodified in the reverse direction as a returned feedback item. See Chapter 5 for further details of how the requested feedback item is returned.
Qビットは、要求されたフィードバック項目が存在するか否かを示しています。圧縮機は、返さフィードバックアイテムとして逆方向に修飾されていない送信される任意の値に要求されたフィードバック項目を設定することができます。要求されたフィードバック項目が返される方法の詳細は、第5章を参照してください。
The format of the requested feedback item is identical to the format of the returned feedback item illustrated in Figure 4.
要求されたフィードバック・アイテムのフォーマットは図4に示さ返さフィードバックアイテムのフォーマットと同一です。
The compressor sets the S-bit to 1 if it does not wish (or no longer wishes) to save state information at the receiving endpoint and also does not wish to access state information that it has previously saved. Consequently, if the S-bit is set to 1 then the receiving endpoint can reclaim the state memory allocated to the remote compressor and set the state_memory_size for the compartment to 0.
それは希望（またはもはやたい）していない場合の圧縮機は、受信エンドポイントでの状態情報を保存するようにしても、それは以前に保存した状態情報にアクセスすることを希望していない1にSビットをセットしていません。 Sビットが1に設定されている場合、結果として、その後、受信エンドポイントは遠隔圧縮機に割り当てられた状態メモリを解放し、0に区画するためstate_memory_sizeを設定することができます。
The compressor may change its mind and switch the S-bit back to 0 in a later message. However, the receiving endpoint is under no obligation to use the original state_memory_size for the compartment; it may choose to allocate less memory to the compartment or possibly none at all.
圧縮機は、その心を変更し、それ以降のメッセージに0に戻るSビットを切り替えてもよいです。しかし、受信エンドポイントは、区画の元state_memory_sizeを使用する義務の下にあります。それは全くのコンパートメントまたは多分noneに少ないメモリを割り当てることもできます。
Similarly the compressor sets the I-bit to 1 if it does not wish (or no longer wishes) to access any of the locally available state items offered by the receiving endpoint. This can help to conserve bandwidth because the list of locally available state items no longer needs to be returned in the reverse direction. It may also conserve memory at the receiving endpoint, as the state handler can delete any locally available state items that it determines are no longer required by any remote endpoint. Note that the compressor can set the I-bit back to 0 in a later message, but it cannot access any locally available state items that were previously offered by the receiving endpoint unless they are subsequently re-announced.
それは希望（またはもはやたい）受信エンドポイントにより提供される局所的に利用可能な状態のいずれかにアクセスすることをしない場合同様に、圧縮機1へのIビットをセットしません。局所的に利用可能な状態項目のリストは、もはや逆方向に戻す必要があるので、これは、帯域幅を節約するために役立つことはできません。状態ハンドラは、それがもはや任意のリモートエンドポイントによって要求される決定する任意の局所的に利用可能な状態の項目を削除することができるように、それはまた、受信エンドポイントでメモリを節約することができます。コンプレッサは、後でメッセージに0に戻ってIビットを設定することができますが、それは彼らがその後再アナウンスされていない限り、以前に受信エンドポイントによって提供された任意の局所的に利用可能な状態の項目にアクセスすることはできません。
If the returned_parameters_location operand is set to 0, then no SigComp parameters are returned; otherwise, it points to the starting memory address of the returned parameters as shown in Figure 13.
returned_parameters_locationオペランドが0に設定されている場合、何のSigCompパラメータが返されません。図13に示すように、それ以外の場合は、返されたパラメータの開始メモリアドレスを指し示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
Figure 13: Format of returned SigComp parameters
図13：返されたSigCompパラメータのフォーマット
The first byte encodes the SigComp parameters cycles_per_bit, decompression_memory_size and state_memory_size as per Section 3.3.1. The byte can be set to 0 if the three parameters are not included in the feedback data. (This may be useful to save bits in the compressed message if the remote endpoint is already satisfied all necessary information has reached the endpoint receiving the message.)
最初のバイトは、セクション3.3.1に従ってのSigCompパラメータcycles_per_bit、decompression_memory_sizeとstate_memory_sizeをコードします。三つのパラメータは、フィードバックデータに含まれていない場合、バイトは0に設定することができます。 （リモートエンドポイントは、すべての必要な情報がメッセージを受信したエンドポイントに到達した既に満たされている場合、これは圧縮されたメッセージのビットを保存するために有用であり得ます。）
The second byte encodes the SigComp_version as per Section 3.3.2. Similar to the first byte, the second byte can be set to 0 if the parameter is not included in the feedback data.
2番目のバイトは3.3.2項に従ってSigComp_versionをコードしています。パラメータは、フィードバックデータに含まれていない場合、最初のバイトと同様、第2バイトは0に設定することができます。
The remaining bytes encode a list of partial state identifiers for the locally available state items offered by the sending endpoint. Each state item is encoded as a 1-byte length field, followed by a partial state identifier containing as many bytes as indicated in the length field. The sender can choose to send as few as 6 bytes if it believes that this is sufficient for the receiver to determine which state item is being offered.
残りのバイトは、送信エンドポイントによって提供される局所的に利用可能な状態の項目のための部分的な状態識別子のリストをコードします。各状態項目は、長さフィールドに示されているようバイト数を含む部分状態識別子に続く、1バイトの長さフィールドとして符号化されます。送信者は、受信機が提供されている状態の項目を決定するために、これは十分であると考えているかのように、数6のようにバイトを送信することができます。
The list of state identifiers is terminated by a byte in the position where the next length field would be expected that is set to a value below 6 or above 20. Note that upgraded SigComp versions may append additional items of data after the final length field.
状態識別子のリストは、6以下またはSigCompのバージョンが最終的な長さフィールドの後にデータの追加項目を追加できるアップグレード20注上記の値に設定される次の長さフィールドは、予想される位置のバイトで終了されます。
The overall security goal of the SigComp architecture is to not create risks that are in addition to those already present in the application protocols. There is no intention for SigComp to enhance the security of the application, as it always can be circumvented by not using compression. More specifically, the high-level security goals can be described as:
SigCompのアーキテクチャの全体的なセキュリティ目標は、アプリケーションプロトコルに既に存在しているものに加えているリスクを作成しないことです。それは常に圧縮を使用しないことによって回避することができるようにSigCompは、アプリケーションのセキュリティを強化するための意図はありません。具体的には、高レベルのセキュリティ目標は、次のように説明することができます。
This section identifies the potential security risks associated with SigComp, and explains how each risk is minimized by the scheme.
このセクションでは、SigCompのに関連する潜在的なセキュリティリスクを識別し、それぞれのリスクはスキームによって最小化される方法を説明します。
- Attacking SigComp by snooping into state of other users:
- 他のユーザーの状態にスヌープでのSigCompを攻撃：
State is accessed by supplying a state identifier, which is a cryptographic hash of the state being referenced. This implies that the referencing message already needs knowledge about the state. To enforce this, a state item cannot be accessed without supplying a minimum of 48 bits from the hash. This also minimizes the probability of an accidental state collision. A compressor can, using the minimum_access_length operand of the STATE-CREATE and END-MESSAGE instructions, increase the number of bits that need to be supplied to access the state, increasing the protection against attacks.
状態は、状態の暗号ハッシュが参照されている状態識別子を供給することによってアクセスされます。これは、参照元のメッセージがすでに状態についての知識が必要であることを意味します。これを強制するために、状態の項目は、ハッシュから48ビットの最小値を供給することなくアクセスすることができません。また、これは偶然の状態の衝突の可能性を最小限に抑えることができます。圧縮機は、STATE-CREATEとEND-MESSAGE命令のminimum_access_lengthオペランドを使用して、攻撃に対する保護を増大させる、状態にアクセスするために供給される必要があるビットの数を増加させることができます。
Generally, ways to obtain knowledge about the state identifier (e.g., passive attacks) will also easily provide knowledge about the referenced state, so no new vulnerability results.
一般に、状態識別子（例えば、受動的攻撃）についての知識を得るための方法も容易に参照状態についての知識を提供していないので、新たな脆弱性の結果であろう。
An endpoint needs to handle state identifiers with the same care it would handle the state itself.
エンドポイントは、状態自体を扱うのと同じ注意を払って状態識別子を処理する必要があります。
The SigComp approach assumes that there is appropriate integrity protection below and/or above the SigComp layer. The state creation mechanism provides some additional potential to compromise the integrity of the messages; however, this would most likely be detectable at the application layer.
SigCompのアプローチは、以下及び/又はSigCompの層の上の適切な完全性保護があることを前提としています。状態の生成メカニズムは、メッセージの完全性を損なうためにいくつかの追加の可能性を提供します。しかし、これは最も可能性の高いアプリケーション層で検出可能になります。
- Attacking SigComp by faking state or making unauthorized changes to state:
- 状態を偽造または状態への不正な変更を加えることでのSigCompを攻撃：
State cannot be destroyed by a malicious sender unless it can send messages that the application identifies as belonging to the same compartment the state was created under; this adds additional security risks only when the application allows the installation of SigComp state from a message where it would not have installed state itself.
それは、アプリケーションが状態の下に作成されたのと同じコンパートメントに属するものとして識別したメッセージを送信することができない限り、国家は、悪意のある送信者によって破壊することはできません。これは、アプリケーションが、それは状態自体をインストールしていないとのメッセージからのSigComp状態のインストールを許可する場合にのみ、追加のセキュリティリスクを追加します。
Faking or changing state is only possible if the hash allows intentional collision.
ハッシュは、意図的な衝突を許可する場合は偽造や状態を変更することのみ可能です。
- Use of SigComp as a tool in a DoS attack to another target:
- 別のターゲットへのDoS攻撃におけるツールとしてのSigCompの使用：
SigComp cannot easily be used as an amplifier in a reflection attack, as it only generates one decompressed message per incoming compressed message. This message is then handed to the application; the utility as a reflection amplifier is therefore limited by the utility of the application for this purpose.
それだけ受信圧縮メッセージごとに圧縮解除メッセージを生成するようにSigCompを容易に、反射攻撃における増幅器として使用することができません。このメッセージは、アプリケーションに渡されます。反射アンプとしての有用性は、したがって、この目的のためのアプリケーションの有用性によって制限されます。
However, it must be noted that SigComp can be used to generate larger messages as input to the application than have to be sent from the malicious sender; this therefore can send smaller messages (at a lower bandwidth) than are delivered to the application. Depending on the reflection characteristics of the application, this can be considered a mild form of amplification. The application MUST limit the number of packets reflected to a potential target - even if SigComp is used to generate a large amount of information from a small incoming attack packet.
しかし、悪質な送信者から送信されるように持っているよりもSigCompのアプリケーションへの入力として大きなメッセージを生成するのに使用することができることに留意しなければなりません。従って、これはアプリケーションに配信されるよりも（低い帯域幅で）小さなメッセージを送信することができます。アプリケーションの反射特性に依存し、これは増幅の軽症型と考えることができます。アプリケーションは、潜在的なターゲットに反射したパケットの数を制限しなければならない - のSigCompが小さい着信攻撃パケットから大量の情報を生成するために使用されても。
- Attacking SigComp as the DoS target by filling it with state:
- 状態でそれを充填することにより、DoS攻撃の標的としてのSigCompを攻撃。
Excessive state can only be installed by a malicious sender (or a set of malicious senders) with the consent of the application. The system consisting of SigComp and application is thus approximately as vulnerable as the application itself, unless it allows the installation of SigComp state from a message where it would not have installed application state itself.
過度の状態は、アプリケーションの同意を得て、悪意のある送信者（または悪意のある送信者のセット）によってインストールすることができます。それがアプリケーション状態自体をインストールしていないメッセージからのSigComp状態のインストールを許可しない限りにSigComp及びアプリケーションからなるシステムは、このようにアプリケーション自体とほぼ同じ脆弱です。
If this is desirable to increase the compression ratio, the effect can be mitigated by making use of feedback at the application level that indicates whether the state requested was actually installed - this allows a system under attack to gracefully degrade by no longer installing compressor state that is not matched by application state.
これは、圧縮率を高めることが望ましい場合、効果は、実際にインストールされた状態が要求されたかどうかを示すことをアプリケーション・レベルでフィードバックを利用することによって軽減することができる - これは、攻撃対象のシステムが正常にもはや圧縮状態をインストールすることによって分解することができアプリケーションの状態にマッチしていません。
Obviously, if a stream-based transport is used, the streams themselves constitute state that has to be handled in the same way that the application itself would handle a stream-based transport; if an application is not equipped for stream-based transport, it should not allow SigComp connections on a stream-based transport. For the alternative SigComp usage described as "continuous mode" in Section 4.2.1, an attacker could create any number of active UDVMs unless there is some DoS protection at a lower level (e.g., by using TLS in appropriate configurations).
ストリームベースのトランスポートが使用される場合、明らかに、ストリーム自体は、アプリケーション自体がストリームベースのトランスポートを処理するのと同じ方法で処理されなければならない状態を構成しています。アプリケーションは、ストリームベースの輸送のために装備されていない場合、それはストリームベースのトランスポート上のSigComp接続を許可するべきではありません。下位レベルでいくつかのDoS保護（例えば、適切な構成でTLSを使用して、）がない限り、セクション4.2.1に「連続モード」として説明代替のSigCompの使用のために、攻撃者がアクティブUDVMsの任意の数を作成することができます。
- Attacking the UDVM by faking state or making unauthorized changes to state:
- 状態を偽造または状態への不正な変更を加えることで、UDVMを攻撃：
This is covered in Section 10.2.2.
これは、10.2.2項に覆われています。
- Attacking the UDVM by sending it looping code:
- コードをループし、それを送信することにより、UDVMを攻撃：
The application sets an upper limit to the number of "UDVM cycles" that can be used per compressed message and per input bit in the compressed message. The damage inflicted by sending packets with looping code is therefore limited, although this may still be substantial if a large number of UDVM cycles are offered by the UDVM. However, this would be true for any decompressor that can receive packets over an unsecured transport.
アプリケーションは、圧縮されたメッセージに圧縮されたメッセージごとに、入力ビットごとに使用することができる「UDVMサイクル」の数に上限を設定します。 UDVMサイクルの多数UDVMによって提供されている場合、これは依然としてかなりのかもしれないが、コードのループを持つパケットを送信することによって被害は、従って、制限されています。しかし、これは、無担保のトランスポート上でパケットを受信できる任意のデコンプレッサのための真のだろう。
SigComp requires a 1-byte name space, the SigComp_version, which has been created by the IANA. Upgraded versions of SigComp must be backwards-compatible with Version 0x01, described in this document. Adding additional UDVM instructions and assigning values to the reserved UDVM memory addresses are two possible upgrades for which this is the case.
SigCompのは、1バイトの名前空間、IANAによって作成されたSigComp_versionが必要です。 SigCompののアップグレードバージョンでは、この文書で説明するバージョンは0x01、との下位互換性がなければなりません。追加UDVM命令を追加し、予約UDVMメモリアドレスに値を割り当てることはこのような場合であるために2つの可能なアップグレードです。
Following the policies outlined in [RFC-2434], the IANA policy for assigning a new value for the SigComp_version shall require a Standards Action. Values are thus assigned only for Standards Track RFCs approved by the IESG.
[RFC-2434]で概説された方針に続き、SigComp_versionの新しい値を割り当てるためのIANAポリシーは、標準アクションを要求しなければなりません。値は、これだけIESGによって承認された標準化過程のRFCのために割り当てられています。
Thanks to
おかげ
Abigail Surtees Mark A West Lawrence Conroy Christian Schmidt Max Riegel Lars-Erik Jonsson Stefan Forsgren Krister Svanbro Miguel Garcia Christopher Clanton Khiem Le Ka Cheong Leung Robert Sugar
アビゲイル・サーティースマーク・A西ローレンスコンロイクリスチャン・シュミットマックスリーゲルラース・エリックジョンソンステファンForsgrenクリスターSvanbroミゲル・ガルシア・クリストファー・クラントンKhiemルのKaチョン・レオンロバート・シュガー
for valuable input and review.
貴重な入力とレビューのために。
[RFC-1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC-1662]、STD 51、RFC 1662、1994年7月シンプソン、W.、 "HDLC様のフレーミングにおけるPPP"。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC-3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC-3174]イーストレイクは、第三、D.とP.ジョーンズは、RFC 3174、2001年9月、 "米国は、ハッシュアルゴリズム1（SHA1）を固定します"。
[RFC-1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC-1951]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月。
[RFC-2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC-2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC-2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC-2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC-2326] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル（RTSP）"、RFC 2326、1998年4月。
[RFC-2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-2434] Alvestrand、H.、およびT. Narten氏、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC-2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwartzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC-2960]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwartzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.及びV.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[RFC-3261] 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.
[RFC-3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、「SIP：セッション開始プロトコル」、RFC 3261、2002年6月。
[RFC-3321] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu, Z. and R. Price, "Signaling Compression (SigComp) - Extended Operations", RFC 3321, January 2003.
[RFC-3321]ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.-C.、劉、Z.及びR.価格、 "シグナリング圧縮（SigCompの） - 拡張操作"、RFC 3321 、2003年1月。
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
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
カルステンボルマンUniversitaetブレーメンTZI POSTFACH 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024 EMail: cabo@tzi.org
電話：+49 421 218 7024 Eメール：cabo@tzi.org
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
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
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039
志剛劉ノキア・リサーチセンター6000接続のドライブアーヴィング、TX 75039
Phone: +1 972 894-5935 EMail: zhigang.c.liu@nokia.com
電話：+1 972 894-5935 Eメール：zhigang.c.liu@nokia.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
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機能のための基金は現在、インターネット協会によって提供されます。