[要約] RFC 3320は、SigCompと呼ばれるシグナリング圧縮技術に関する規格です。この規格の目的は、ネットワークの帯域幅を節約し、シグナリングメッセージの効率を向上させることです。
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)
シグナリング圧縮（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.
Copyright（c）The Internet Society（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.
このドキュメントでは、セッション開始プロトコル（SIP）（RFC 3261）やリアルタイムストリーミングプロトコル（RTSP）（RFC 2326）などのアプリケーションプロトコルによって生成されたメッセージを圧縮するためのソリューションであるシグナリング圧縮（SIGCOMP）を定義します。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の減圧機能は、減圧アルゴリズムを実行するタスクのために最適化されたユニバーサルDecompressor仮想マシン（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メッセージの形式、および減圧機能を提供するUniversal Decompressor Virtual Machine（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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. コンプレッサーにアプリケーションメッセージを提供します。2。減圧装置のディスパッチャーから減圧されたメッセージを受信します3.減圧メッセージのコンパートメント識別子の決定。
Bytecode
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.
アプリケーションの1つのインスタンス、SigComp層、およびSigCompメッセージの送信および/または受信のための輸送層。
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. Decompressor Dispatcher-アプリケーションに向けたインターフェイス。Decompressor DispatcherはSigCompメッセージを受信し、Universal Decompressor Virtual Machine（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. 1つ以上のコンプレッサー - アプリケーションメッセージをSigCompメッセージに変換するエンティティ。個別のコンプレッサーは、アプリケーションによって提供されたコンパートメント識別子を使用して、コンパートメントごとに呼び出されます。コンプレッサーは、コンプレッサーディスパッチャーからアプリケーションメッセージを受信し、メッセージを圧縮し、コンプレッサーディスパッチャーにSigCompメッセージを返します。各コンプレッサーは、データをエンコードするために特定のアルゴリズムを選択します（たとえば、デフレート）。
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の個別のインスタンスが1人あたりのベースで呼び出されることに注意してください。ただし、減圧プロセス中に、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メッセージの間に保存されている情報であり、データを1人あたりにアップロードする必要性を回避します。セキュリティ目的では、アプリケーションの許可を得て新しい状態を作成することのみが可能です。州の作成と検索については、第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を使用する選択は両方方向に独立して行うことができ、一方向に圧縮は必ずしも逆方向に圧縮を意味するわけではありません。さらに、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.
SigCompのエンドポイントは、アーキテクチャが異なるエンドポイントからのメッセージを干渉する1つのエンドポイントから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).
すべてのSIGCOMPメッセージには、UTF-8エンコードされたテキストメッセージ[RFC-2279]では発生しないプレフィックス（最初のバイトの5つの最も重要なビットが1に設定されています）が含まれているため、このエンコード（またはASCIIエンコードを使用するアプリケーションの場合）同じポートで、マルチプレックスの非圧縮アプリケーションメッセージと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に供給します。各コンパートメントには、状態情報を保存するために別のコンプレッサーと一定量のメモリが割り当てられているため、アプリケーションは個別のリモートエンドポイントに異なるコンパートメントを割り当てる必要があります。ただし、ローカルエンドポイントが同じリモートエンドポイントに関連するいくつかのコンパートメントを確立することができます（これは、メモリを無駄にし、全体的な圧縮比を減らす可能性があるため、可能な限り回避する必要がありますが、メッセージを誤って非難することはありません）。この場合、コンプレッサーが異なるコンパートメントを割り当てることを期待したときに、減圧器が複数のメッセージを1つのコンパートメントに詰め込まない場合にのみ、信頼できるステートフル操作が可能です。
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メッセージは、最初にコンプレッサーディスパッチャーを介して送信され、その後、トランスポートレイヤーと最後に減圧装置ディスパッチャーが続きます。
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. EndPoint Bにメッセージを送信するコンプレッサーは、フィードバックリクエストをSigCompメッセージにPiggybackにバックします。
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.
5. コンプレッサーは、要求されたフィードバックデータを返して、sigcompメッセージにピギーバックをエンドポイントにします。
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に送信します）。
9. The compressor makes use of the returned feedback data.
9. コンプレッサーは、返されたフィードバックデータを使用します。
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メッセージ：
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).
特定のアプリケーションは、A-Prioriに必須として追加のリソースを提供することに同意する場合があります（たとえば、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バイトの減圧_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サイクルでのコストは、第9章に記載されています。エンドポイントは、最低16 Cycles_Per_bitを提供する必要があります。
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.
3つのパラメーター値のそれぞれは、以下の限られたセットから選択する必要があります。これにより、SigCompフィードバックメカニズムを使用してパラメーターを送信用に効率的にエンコードできるようにする必要があります。
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: Encoding: cycles_per_bit: Encoding: state_memory_size (bytes):
Cycles_per_bitパラメーターは2ビットを使用してエンコードされ、Decompression_memory_sizeとstate_memory_sizeは両方とも3ビットを使用してエンコードされます。ビットエンコーディングとそれらの対応する値は次のとおりです。エンコード：cycles_per_bit：encoding：state_memory_size（bytes）：
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は、ビットパターン000を使用できないことを除いて、State_memory_sizeと同じ方法でエンコードされます（エンドポイントは0バイトのDecompression_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.
SigCompを後方互換的な方法でアップグレードする最も簡単な方法は、バージョン0x01と互換性のある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 Stateアイテムは、SigCompメッセージの間に保持されるデータの項目です。状態項目は、減圧プロセスの一部として取得してUDVMメモリにロードすることができます。多くの場合、同じ情報を1人あたりのベースでアップロードする必要がないため、圧縮比を大幅に改善できます。
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 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.
Decompressor Dispatcherは、輸送層からメッセージを受信し、各メッセージの減圧バージョンをアプリケーションに渡します。
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が無担保輸送層を介して実行できるようにするために、Decompressor Dispatcherは、新しい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の特定のインスタンスで1つ以上の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が呼び出されると、第7章のSIGCOMPメッセージを使用して初期化されます。その後、メッセージはUDVMによって減圧され、Decompressor Dispatcherに返され、受信アプリケーションに渡されます。UDVMは、基礎となるトランスポートがメッセージベースであるかストリームベースであるかを認識していないため、常に解凍されたデータをストリームとして出力していることに注意してください。予想される形式（つまり、ストリームまたは明確な境界メッセージとして）でアプリケーションに減圧されたメッセージを提供することは、ディスパッチャーの責任です。ディスパッチャーは、UDVM命令の終了メッセージが呼び出されたときに減圧されたメッセージの終わりに到達したことを知っています（セクション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メッセージが終了する前にアプリケーションメッセージの一部がアプリケーションに渡されることを期待することにより、戦略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: Occurs in data stream: Action:
ストリームベースのトランスポートの場合、ディスパッチャーは、0xffのインスタンスのために圧縮データストリームを解析し、次のアクションを実行することによりメッセージを区切ります。データストリームで発生します：アクション：
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
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.)
組み合わせ0xff01から0xff7fは、レコードマーキングスキームの最悪の拡張を制限するのに役立ちます。1（0xff01）は、バイトの組み合わせに続いて127（0xff7f）バイトになります。（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では、原因の減圧障害を引用して保護されていない組み合わせ0xff80から0xfffeの発生。この場合、減圧器はストリームベースのトランスポートを閉じる必要があります。
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).
ディスパッチャーは、コンパートメント識別子をUDVMに渡します。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の重要な特徴は、減圧機能がUniversal Decompressor Virtual Machine（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.
コンプレッサーに掲載されている全体的な要件は、透明性の要件です。つまり、コンプレッサーは、UDVMが特定のSigCompメッセージを誤って減圧させるバイトコードを送信してはなりません。
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. 堅牢性のために、コンプレッサーがアプリケーションメッセージよりも整合性チェック（必ずしも暗号化強度ではない）を提供して、成功した減圧が発生したことを確認することをお勧めします。CRC検証のためにUDVM命令が提供されています。また、別の命令を使用して、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.
4. トランスポートがストリームベースであるが、アプリケーションが独自の内部メッセージの境界を定義する場合、コンプレッサーは各アプリケーションメッセージを正確に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.
エンドポイントがこれらのパラメーターを受信したくないことを示していない場合を除き、コンプレッサーはローカルSigCompパラメーターをリモートエンドポイントにアップロードする必要があります。達成）。SigCompパラメーターは、セクション9.4.9で説明されているように、リモートエンドポイントの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メッセージを解凍するために必要なすべてのデータが受信エンドポイントで利用可能であることを確認する必要があります。これを確保する1つの方法は、必要なすべての情報をすべてのSigCompメッセージに送信することです（メッセージを解凍するBytecodeを含む）。ただし、この方法の圧縮率は比較的低くなります。
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メッセージによってアクセスでき、データを1人あたりにアップロードする必要性を回避できます。
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フィードバックメカニズムを使用してState_memory_sizeパラメーターをチェックすることで実現できます（詳細については、セクション9.4.9を参照）。
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 State Handlerの動作を定義します。州ハンドラーの機能は、受信した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 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).
各状態項目には、状態へのアクセスに使用されるstate_identifierが含まれています。UDVMを初期化するために、SigCompメッセージヘッダーに1つの状態識別子を提供できます（第7章を参照）。追加の状態項目は、状態アクセス命令を使用して取得できます。UDVMは、状態作成と終了の指示を使用して、新しい状態項目の作成をリクエストすることもできます（詳細については、第9章を参照）。
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. 状態ハンドラーは、有効なコンパートメント識別子を伴わないすべての州の作成要求を拒否する必要があります。状態の記憶がないために状態作成要求が失敗した場合、対応する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_Valueから最初の（State_memory_size -64）バイトを除くすべてのステートハンドラーが削除されます。state_lengthを（state_memory_size -64）に設定し、セクション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が含まれている場合、State Handlerは、要求された状態項目が確立された状態項目と同一であるかどうかをチェックし、これが当てはまる場合、状態作成要求を成功します。そうでない場合は、州の作成要求に失敗しました（ただし、これが発生する確率は消えてしまいます）。
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メッセージ間で保持されるため、全体の状態の一部であると見なされ、有効なコンパートメント識別子を伴う場合にのみ転送できます。この場合、Stateハンドラーは、指定されたコンパートメントのピアコンパートメントに関連するメッセージを送信する責任のあるコンプレッサーにフィードバックデータを転送します。
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メッセージ全体をバッファするのに十分なメモリを使用できる必要があります。したがって、メッセージの長さがnバイトの場合、UDVMメモリサイズは（decompression_memory_size -n）に設定され、最大65536バイトまで設定されます。
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メッセージの2つのバリアントを図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
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.
正確に1つの状態項目が一致しているが、状態項目には部分状態識別子の長さよりも大きい最小値を含む場合には、減圧障害も発生します。これにより、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.
UDVMメモリの最初の32バイトは、図5に示すように特別な値に初期化されます。
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は、値16、32、64、または128を取得する2バイト整数として表されます。Sigcomp_versionは、セクション3.3.2に従って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.
アドレス10〜31は予約されており、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（取得した状態項目の一部である）に含まれるメモリアドレスで命令の実行を開始します。残りのSIGCOMPメッセージは、UDVMが要求するまで減圧装置ディスパッチャーによって保持されることに注意してください。
(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 Bytecodeがこれらの場所を自由に使用できることを意味します。それらが必ずしもゼロに初期化されているわけではないことに注意する必要があります。）
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メッセージ自体の一部としてSigCompメッセージを解凍するために必要なバイトコードが提供されます。12ビットCODE_LENフィールドは、アップロードされたUDVMバイトコードのサイズ（0〜4095バイトを含む）を指定します。最初のバイトには8つの最も重要なビットがあり、2番目のバイトの最も重要なビットで4つの最も有意なビットが続きます。2番目のバイトの残りのビットは、バイトコードがコピーされる開始メモリアドレスを指定する4ビット宛先フィールドとして解釈されます。宛先フィールドは次のようにエンコードされています。
Encoding: Destination address:
エンコーディング：宛先アドレス：
0000 reserved
0001 2 * 64 = 128
0010 3 * 64 = 196
0011 4 * 64 = 256
: :
1111 16 * 64 = 1024
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メモリは図5に従って初期化されます。ただし、6〜9のアドレスが包括的であることを除き、状態アイテムがアクセスされないために0に設定されています。次に、UDVMは、宛先フィールドで指定されたメモリアドレスで命令の実行を開始します。上記のように、残りのSigCompメッセージは、UDVMが必要とするまで減圧装置ディスパッチャーによって保持されます。
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の減圧機能は、Universal Decompressor Virtual Machine（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を作成する動機は、特定のアプリケーションメッセージを圧縮する方法を選択する際に柔軟性を提供することです。少数の事前に関連するアルゴリズムの1つを選択するのではなく、コンプレッサー実装者は、選択したアルゴリズムを選択する自由を持っています。圧縮データは、元のデータを抽出できる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レジスタは、特別なタスクを備えた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の前に保存されます。したがって、たとえば、BYTE_COPY_LEFTのMSBはアドレス64に保存され、LSBはアドレス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スタートアップでゼロになることが保証されており、Operand Types Reference（$）およびMultityPe（％）で効率的にアドレス指定可能です。
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.
Decompressor Dispatcherは、入力命令のいずれかを介して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に設定されている場合、個々のバイト内のビットがMSBの入力命令にLSB順序に渡されることを示します。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レジスタは、バイト自体が入力命令に渡される順序を変更できないことに注意してください（バイトは常に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
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.
1つ以上の入力命令の後、ディスパッチャーはバイトの一部を保持できることに注意してください（以前はp = 0の場合はLSBであったもの、またはMSB、p = 1の場合）。入力命令が遭遇し、最後の入力命令以降に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の整数として解釈します。LSB Order（0に設定）またはLSBからMSB Order（ビット設定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.) 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.
Fビットが0に設定されている場合、入力ビット命令は、最初に到着するMSBSとして受信したビットを解釈し、1に設定されている場合、最初にLSBSに到着するBITを解釈します。Hビットは、入力ハフマン命令に対して同じ関数を実行します。これらの2つのビットを異なる値に設定して、2つの命令に異なるビット注文を使用することが可能であることに注意してください（特定のアルゴリズムは実際にこれを必要とします。たとえば、DEFLATE [RFC-1951]）。（上記のPビットの破棄ルールとは異なり、入力命令間でFまたはHビットを変更するための特別な考慮事項はないことに注意してください。）減圧障害は、入力ビットまたは入力-Huffman命令に遭遇した場合に発生します。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 stack [0] stack_location 2 stack [1] stack_location 4 stack [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および71の2バイトワードの略語です。表記stack_fillは、stack_locationおよびstack_locationでの2バイトワードの略語です。[n]は、stack_location 2*n 2およびstack_location 2*n 3での2バイトワードの略語です（いつものように、算術は2^16です。）
The stack is used by the CALL, RETURN, PUSH and POP instructions.
スタックは、通話、返品、プッシュ、ポップの指示によって使用されます。
"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]にコピーし、stack_fillを1で増やすための略語です。
"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 [stack_fill]に保存された値を使用するための略語です。stack_fillがポップ操作の開始時にゼロの場合、減圧の故障が発生します。スタックからポップ値をポップして返します。
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にアクセスして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から/アドレスmからコピーされた場合、次のバイトは次のように計算されます。
Set k := m + 1 (modulo 2^16)
If k = byte_copy_right then set n := byte_copy_left, else set n := 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、コピー、コピーリテラル、コピーオフセット、Memset、入力バイト、状態アクセス、出力、終了メッセージ
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.) 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命令は、このシーケンスが実装に不合理な負担をもたらす場合に概念的なままであるように設計されていることに注意してください。）典型的な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バイトコードを図8から図10に示し、バイトコードで表される整数値を示します。
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の前に示されていることに注意してください。また、Kの連続した「n」でマークされたビットの文字列は、0から2^k -1の整数nとして解釈されます（LSBの前に示すnのMSBを使用）。
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:
bytecode：オペランド値：範囲：
0nnnnnnn N 0 - 127
10nnnnnn nnnnnnnn N 0 - 16383
11000000 nnnnnnnn nnnnnnnn N 0 - 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.
2番目のオペランドタイプはリファレンス（$）です。これは、UDVMメモリの他の場所にある2バイト値にアクセスするために常に使用されます。参照オペランドのバイトコードは、オペランドの実際の値を含むメモリアドレスとして解釈される0から65535の包括的整数であるようにデコードされます。
Bytecode: Operand value: Range:
bytecode：オペランド値：範囲：
0nnnnnnn memory[2 * N] 0 - 65535
10nnnnnn nnnnnnnn memory[2 * N] 0 - 65535
11000000 nnnnnnnn nnnnnnnn memory[N] 0 - 65535
Figure 9: Bytecode for a reference ($) operand
図9：参照（$）オペランドのByteCode
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バイト値を参照するため、参照オペランドの範囲は常に0〜65535です。
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.
3番目の種類のオペランドはマルチタイプ（％）です。これは、実際の値とメモリアドレスの両方をエンコードするために使用できます。MultityPe Operandは、小整数値（正と負の両方）および2のパワーの効率的なエンコードも提供します。
Bytecode: Operand value: Range:
bytecode：オペランド値：範囲：
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
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:
4番目のオペランドタイプはアドレス（@）です。このオペランドは、マルチタイプオペランドとしてデコードされ、その後にさらなるステップが続きます。アドレスオペランドを含むUDVM命令のメモリアドレスが追加され、正しいオペランド値が得られます。したがって、図10のオペランド値がDの場合、アドレスの実際のオペランド値は次のように計算されます。
operand_value = (memory_address_of_instruction + D) modulo 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がジャンプ命令に遭遇した場合）、そのメモリに含まれる命令を連続的に実行します。次に実行される命令が利用可能なメモリの外側にある場合、減圧障害が発生します（セクション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サイクルの数は、SigCompヘッダーのビット数に1000に初期化されます（セクション7で説明されています）。次に、この合計にCycles_per_bitを掛けます。命令が実行されるたびに、利用可能なUDVMサイクルの数は第9章で指定された量によって減少します。さらに、UDVMが入力命令のいずれかを使用して圧縮データのnビットを正常に要求する場合、利用可能なUDVMサイクルの数は増加します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
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は、末端命令に遭遇したときに命令の実行を停止します。
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:
減圧の障害の理由には、以下が含まれます。
1. A SigComp message contains an invalid header as per Chapter 7.
1. SigCompメッセージには、第7章に従って無効なヘッダーが含まれています。
2. A SigComp message is larger than the decompression_memory_size.
2. sigcompメッセージは、decompression_memory_sizeよりも大きいです。
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は、メモリサイズを超えてメモリアドレスから読み取りまたは書き込みを試みます。
5. An unknown instruction is encountered.
5. 未知の指示に遭遇します。
6. An unknown operand is encountered.
6. 未知のオペランドに遭遇します。
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. UDVMが正常に処理できない命令が発生します（たとえば、コール命令が以前に発生していない場合の返品命令）。
8. A request to access some state information fails.
8. 州の情報にアクセスするためのリクエストは失敗します。
9. A manual decompression failure is triggered using the DECOMPRESSION-FAILURE instruction.
9. 減圧命令を使用して、手動の減圧障害がトリガーされます。
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: Instruction: Bytecode value: Cost in UDVM cycles:
図11に、命令のエンコードに使用されるさまざまな命令とバイトコード値を示します。UDVMサイクルでの各命令のコストも与えられます：命令：bytecode値：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
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.
ソート命令の場合、式の天井（log2（k））は、k <= 2^iのような最小値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以上のバイトが続きます。命令は、それぞれの場合に4つのオペランドタイプのセクション8.5のどれが使用されるかを指定します。たとえば、追加命令の後に2つのオペランドが続きます。
ADD ($operand_1, %operand_2)
追加（$ 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.
Bytecodeに変換すると、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.
命令の説明が式の「and」という式を使用するたびに、意図されたセマンティクスは、「および「その後」の作業の前に「そして」の作業が「そして」の後に説明された作業の前に完了したという意図されたセマンティクスです。
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、または、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) 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.)
（$ operand_1、％operand_2）または（$ operand_1、％operand_2）not（$ operand_1）lshift（$ operand_1、％operand_2）rshift（$ operand_1、％operand_2）操作が完了した後、最初のオペランドの値は結果を上書きします。（このオペランドは参照であるため、上書きされたオペランドで指定されたメモリアドレスの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)
The ADD, SUBTRACT, MULTIPLY, DIVIDE and REMAINDER instructions perform arithmetic on 2-byte words.
追加、減算、乗算、分割、および残りの命令は、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)
追加（$ operand_1、％operand_2）減算（$ operand_1、％operand_2）乗算（$ operand_1、％operand_2）divide（$ operand_1、％operand_2）残り（$ 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)
Decompression failure occurs if a DIVIDE or REMAINDER instruction encounters an operand_2 that is zero.
除算または残りの命令がゼロのOperand_2に遭遇する場合、減圧の故障が発生します。
The SORT-ASCENDING and SORT-DESCENDING instructions sort lists of 2- byte words.
並べ替えと並べ替えの命令は、2バイト単語のリストをソートします。
SORT-ASCENDING (%start, %n, %k) SORT-DESCENDING (%start, %n, %k)
ソートアッセンディング（％start、％n、％k）ソートデス（％start、％n、％k）
The start operand specifies the starting memory address of the block of data to be sorted.
Start Operandは、ソートするデータブロックの開始メモリアドレスを指定します。
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リストに分割されます。並べ替えの命令は、リストに特定の順列を適用し、最初のリストが昇順に分類される（各2バイト単語を符号なし整数として扱う）。同じ順列がすべてのnリストに適用されるため、最初のリスト以外のリストは必ずしも順序に分類されるわけではありません。
In the case that two words have the same value, the original ordering of the list is preserved.
2つの単語が同じ値を持っている場合、リストの元の順序が保持されます。
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:
たとえば、最初のリストにはソートされる整数のセットが含まれている場合がありますが、2番目のリストを使用して、ソートされたリストの整数がどこに表示されるかを追跡することができます。
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.
並べ替える命令は、上記のように動作しますが、最初のリストが降順の順序に分類されることを除きます。
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メモリをセットアップし、あるメモリの場所から別のメモリにバイト文字列をコピーするために、次の手順を使用します。
The LOAD instruction sets a 2-byte word to a certain specified value. The format of a LOAD instruction is as follows:
負荷命令は、特定の指定された値に2バイトワードを設定します。負荷命令の形式は次のとおりです。
LOAD (%address, %value)
ロード（％アドレス、％値）
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.
マルチロード命令は、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).
最初のオペランドは、隣接する2バイトの単語の開始アドレスを指定しますが、Operands value_0をValue_N-1に介してこれらの単語にロードする値を指定します（命令に表示されるのと同じ順序で）。
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バイトの単語のセットが、命令（オペランドを含む）自体が保持するメモリの位置、つまり命令が自己修正される場合に重複する場合、減圧の故障が発生します。（この制限により、命令実行の概念モデルで暗示されているように、データをコピーする前にすべてのオペランドをデコードする必要があるのではなく、マルチロードの段階的な段階的な実装が簡単になります。）
The PUSH and POP instructions read from and write to the UDVM stack (as defined in Section 8.3).
プッシュとポップの命令は、UDVMスタックから読み、書き込みます（セクション8.3で定義）。
PUSH (%value) POP (%address)
プッシュ（％値）ポップ（％アドレス）
The PUSH instruction pushes the value specified by its operand on the stack.
プッシュ命令は、スタック上のオペランドで指定された値をプッシュします。
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.)
ポップ命令はスタックから値をポップし、指定されたメモリアドレスに値をコピーします。（式は、「および「次に」という式は、値のコピーがスタック操作自体にとって重要ではないことを意味することに注意してください。
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.
コピー命令は、UDVMメモリのある部分から別の部分にバイトの文字列をコピーするために使用されます。
COPY (%position, %length, %destination)
コピー（％位置、％長さ、宛先％）
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)
コピーリテラル（％位置、％長さ、$宛先）
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).
コピーリテラル命令は、コピーが完了した後、宛先オペランドの値が次のデータのコピーがコピーされるアドレスに置き換えられることを除いて、コピー命令として動作します。より正確には、セクション8.4に従って導出された値nに置き換えられます。これは、コピーされる最後のバイトの宛先アドレスに設定されています。オペランドは変更されていません）。
A further version of the COPY-LITERAL instruction is given below:
コピーリテラル命令のさらなるバージョンを以下に示します。
COPY-OFFSET (%offset, %length, $destination)
コピーオフセット（％オフセット、％長さ、$宛先）
The COPY-OFFSET instruction behaves as a COPY-LITERAL instruction except that an offset operand is given instead of a position operand.
コピーオフセット命令は、ポジションオペランドの代わりにオフセットオペランドが与えられていることを除いて、コピーリテラル命令として動作します。
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.
byte_copy_leftで指定されたメモリアドレスに到達した場合、次のメモリアドレスは（byte_copy_right -1）modulo 2^16と見なされます。
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.
次に、コピーオフセット命令はコピーリテラル命令として動作し、ポジションオペランドの値を上記のステップで到達した最後のメモリアドレスとするようにします。
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、％offset）
The sequence of values used by the MEMSET instruction is specified by the following formula:
Memset命令で使用される値のシーケンスは、次の式で指定されています。
Seq[n] := (start_value + n * offset) modulo 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].
値はそれぞれ単一バイトとして解釈され、最初のバイトが値seq [0]を持つバイト文字列を形成するために連結され、2番目のバイトが値seq [1]を形成するために、値[0]からseq [長さ-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で説明されているように、MEMSET命令は、元のオペランドがまだUDVMメモリにまだ所定の位置にあるかのように実行されなければなりません。）
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 (@address)
ジャンプ（@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つのメモリアドレスのいずれかにジャンプします。
COMPARE (%value_1, %value_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.
value_1 <value_2の場合、UDVMはアドレス1で指定されたメモリアドレスで命令実行を継続します。value_1= value_2の場合、address_2で指定されたアドレスにジャンプします。value_1> value_2の場合、address_3で指定されたアドレスにジャンプします。
The CALL and RETURN instructions provide support for compression algorithms with a nested structure.
コールおよびリターンの命令は、ネストされた構造を持つ圧縮アルゴリズムのサポートを提供します。
CALL (@address) RETURN
（@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がコール命令に到達すると、コール命令の直後に命令のメモリアドレスを見つけ、スタックにこの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がリターン命令に到達すると、スタックから値をポップし、メモリアドレスで命令実行を継続します。
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)
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計算は、PPP [RFC-1662]の2バイトフレームチェックシーケンス（FCS）と一致する発電機多項式x^16 x^12 x^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].
CRC値は、[RFC-1662]の16ビットFCS計算で定義されたとおりに計算されます。
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).
減圧式の命令は、手動減圧の障害を引き起こします。これは、UDVMバイトコードがメッセージを正常に解凍できないことを発見した場合に役立ちます（たとえば、CRC命令を使用して）。
This instruction has no operands.
この命令にはオペランドはありません。
The INPUT-BYTES instruction requests a certain number of bytes of compressed data from the decompressor dispatcher.
入力バイト命令は、Decompressor Dispatcherから一定数の圧縮データを要求します。
INPUT-BYTES (%length, %destination, @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.
入力バイト（％長さ、宛先、@Address）長さのオペランドは、圧縮データの要求されたバイト数を示し、宛先オペランドはコピーする必要がある開始メモリアドレスを指定します。バイトコピーは、セクション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.
入力ビットまたは入力ハフマン命令が使用された後に入力バイトが発生し、ディスパッチャーが現在バイトの一部を保持している場合、データがUDVMに渡される前に分数を破棄する必要があります。渡される最初のバイトは、破棄されたデータの直後のバイトです。
The INPUT-BITS instruction requests a certain number of bits of compressed data from the decompressor dispatcher.
入力ビット命令は、Decompressor Dispatcherから一定数の圧縮データを要求します。
INPUT-BITS (%length, %destination, @address)
入力ビット（％長さ、％宛先、@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で説明されているように、0〜2^の長さ-1の範囲の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.
入力-Huffman命令は、Decompressor Dispatcherから変動する数の圧縮データを要求します。命令は最初に少数のビットを要求し、結果を特定の基準と比較します。基準が満たされていない場合、基準が達成されるまで追加のビットが要求されます。
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-HUFFMAN (%destination, @address, #n, %bits_1, %lower_bound_1, %upper_bound_1, %uncompressed_1, ... , %bits_n, %lower_bound_n, %upper_bound_n, %uncompressed_n)
入力ハフマン命令の後に、3つの必須オペランドとオペランドの追加セットが続きます。追加のセットはすべて、以下に示すように4つのオペランドが含まれています：入力-Huffman（％宛先、@address、#n、％bits_1、％lower_bound_1、％upper_bound_1、％unsupressed_1、...、％bits_n、％lower_bound_n、％apple_bound_n、％unsupredessid_n_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の場合、入力ハフマン命令は無視され、プログラムの実行が次の命令で再開されることに注意してください。減圧の故障は、（bits_1 ... bits_n）> 16の場合に発生します。
In all other cases, the behavior of the INPUT-HUFFMAN instruction is defined below:
他のすべての場合、入力ハフマン命令の動作を以下に定義します。
1. Set j := 1 and set H := 0.
1. J：= 1を設定し、H：= 0を設定します。
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.
2. bits_j圧縮ビットを要求します。セクション8.2で説明されているように、返されたビットを0から2^bits_j -1の整数kとして解釈します。
3. Set H := H * 2^bits_j + k.
3. h：= h * 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メッセージの終わりを超えているデータが要求された場合、入力Huffman命令を終了し、プログラムの実行をアドレスオペランドで指定したメモリアドレスに移動します。
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. （h <lower_bound_j）または（h> upper_bound_j）の場合、j：= j 1を設定します。次に、j> nが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）modulo 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が一致した状態項目の最小値よりも少ない場合、減圧障害も発生します。それ以外の場合、州のアイテムが州のハンドラーから返品されます。
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.
Operands 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 Operandが0に設定されている場合、State_Lengthの値は、状態の返されたアイテムから取得する必要があります。
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 Operandsは、戻った状態の項目に含まれるState_Valueからコピーする開始byteとバイト数を定義します。バイトがstate_valueの端からコピーされた場合、減圧の故障が発生します。State_Length Operandが0に設定されているが、State_Begin Operandはゼロではない場合、減圧障害が常に発生することに注意してください。
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 Operandには、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 OperandとState_instruction値の両方が0に設定されている場合にのみ発生することに注意してください。
The STATE-CREATE instruction requests the creation of a state item at the receiving endpoint.
国家作成の命令は、受信エンドポイントで州アイテムの作成を要求します。
STATE-CREATE (%state_length, %state_address, %state_instruction, %minimum_access_length, %state_retention_priority)
state-create（％state_length、％state_address、％state_instruction、％miniminal_access_length、％state_retention_priority）
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.
新しい状態項目は、有効なコンパートメント識別子がアプリケーションによって返されるまで作成できないことに注意してください。したがって、状態を作成する命令に遭遇すると、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つ以上の州の作成要求が行われた場合、減圧の故障が発生する必要があります。最低_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 (%partial_identifier_start, %partial_identifier_length)
ステートフリー（％partial_identifier_start、％partial_identifier_length）
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.
州のない命令は、状態アイテムを自動的に削除するのではなく、代わりに特定のコンパートメント内の状態アイテムが取得したメモリを取り戻すことに注意してください。したがって、国家が作成する指示と同様に、州のない命令に遭遇した場合、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つ以上の州の無料リクエストが行われた場合、減圧の故障が発生する必要があります。partial_identifier_lengthが6〜20の包括的に存在しない場合、減圧障害も発生します。
The OUTPUT instruction provides successfully decompressed data to the dispatcher.
出力命令は、ディスパッチャーに正常に解凍されたデータを提供します。
OUTPUT (%output_start, %output_length)
出力（％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.
終了命令は、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、％minimine_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.
終了命令に遭遇すると、減圧装置ディスパッチャーは、完全なメッセージが減圧されたことをアプリケーションに示します。アプリケーションは、コンパートメント識別子を返す場合があります。これは、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.
実際の解凍メッセージは、出力命令を使用して個別に出力されます。これにより、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.
終了命令は、最大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).
国家の作成要求は、国家作成の指示によって行われます。ただし、最終説明により、供給されたオペランドを使用して1つの状態作成要求自体を作成できることに注意してください。指定されたMinimum_Access_Lengthが6〜20の包括的にない場合、またはState_Retention_Priorityが65535の場合、最終説明は独自の状態作成要求を行うことに失敗します（ただし、減圧障害は発生せず、状態作成要求は状態作成命令はまだ有効です）。
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つの状態作成要求の最大制限があることに注意してください。したがって、最終説明の命令が州の作成要求を行うと、非減圧の故障が発生し、国家作成の命令の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アドレス、STATE_INSTRUCTION、およびMinimum_Access_Lengthを指定する必要があります。これらは、州を作成する命令（または最終説明）のオペランドとして提供されます。状態の完全な項目には、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バイトは、state_addressから始まるUDVMメモリからのstate_lengthバイトの文字列をコピーします（セクション8.4のルールに従う）。これは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、minimon_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は、州の作成または終了命令のオペランドとして提供され、各州の作成要求の一部として州ハンドラーに渡されます。
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.
州の無料リクエストは、州のない指示によって行われます。各ステートフリー命令は、partial_identifier_startおよびpartial_identifier_lengthの値を提供します。最終説明に到達すると、これらの値は、UDVMメモリから部分状態識別子をバイトするために使用されます。部分状態識別子を一致させる状態項目が見つからない場合、またはコンパートメント内の複数の状態アイテムが部分状態識別子と一致する場合、状態の自由要求は無視されます（これは減圧の失敗を発生させません）。それ以外の場合、State Handlerは、セクション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.
国家の作成と州の無料リクエストを転送するだけでなく、最終説明命令はフィードバックデータを州のハンドラーに渡すこともあります。フィードバックデータは、送信エンドポイントの機能について受信エンドポイントに通知するために使用されます。これは、全体的な圧縮比を改善し、エンドポイントの作業メモリ要件を削減するのに役立ちます。
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種類のフィードバックデータが利用可能です。要求されたフィードバックと返されたフィードバック。要求されたフィードバックデータの形式を図12に示します。セクション3.2で概説したように、要求されたフィードバックデータを使用して、返されたフィードバックデータの内容に逆方向に影響を与えることができます。
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.
request_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で使用でき、バージョン0x01では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.
コンプレッサーは、受信エンドポイントで州の情報を保存することを望まない（または希望しない）場合、Sビットを1に設定し、以前に保存した状態情報にアクセスすることも望まない。その結果、S-BITが1に設定されている場合、受信エンドポイントはリモートコンプレッサーに割り当てられた状態メモリを取り戻し、コンパートメントのstate_memory_sizeを0に設定できます。
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.
コンプレッサーは、心を変え、後のメッセージでSビットを0に戻す場合があります。ただし、受信エンドポイントは、コンパートメントに元のstate_memory_sizeを使用する義務がありません。それは、コンパートメントに少ないメモリを割り当てるか、おそらくまったくないことを選択するかもしれません。
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.
同様に、コンプレッサーは、受信エンドポイントが提供するローカルで利用可能な状態アイテムのいずれかにアクセスすることを望まない（または希望しない）場合、Iビットを1に設定します。これは、ローカルで利用可能な状態アイテムのリストを逆方向に返す必要がなくなるため、帯域幅を節約するのに役立ちます。また、状態ハンドラーは、リモートエンドポイントで必要とされなくなったと判断したローカルで利用可能な状態アイテムを削除できるため、受信エンドポイントでメモリを節約することもできます。コンプレッサーは、後のメッセージでiビットを0に戻すことができるが、その後再発行されない限り、受信エンドポイントによって以前に提供されていたローカルで利用可能な状態アイテムにアクセスできないことに注意してください。
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をエンコードします。3つのパラメーターがフィードバックデータに含まれていない場合、バイトを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バージョンは、最終長さフィールドの後に追加のデータを追加することができることに注意してください。
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はアプリケーションのセキュリティを強化する意図はありません。より具体的には、高レベルのセキュリティ目標は次のように説明できます。
1. Do not worsen security of existing application protocol
1. 既存のアプリケーションプロトコルのセキュリティを悪化させないでください
2. Do not create any new security issues
2. 新しいセキュリティの問題を作成しないでください
3. Do not hinder deployment of application security.
3. アプリケーションセキュリティの展開を妨げないでください。
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ビットを供給せずに状態アイテムにアクセスできません。これにより、偶発的な状態衝突の確率も最小限に抑えられます。コンプレッサーは、状態作成および終了命令の最小限の_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状態をインストールしていない場合に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は、回復攻撃のアンプとして簡単に使用することはできません。これは、着信圧縮メッセージごとに1つの減圧メッセージのみを生成するためです。このメッセージはアプリケーションに渡されます。したがって、反射アンプとしてのユーティリティは、この目的のためのアプリケーションの有用性によって制限されます。
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:
- SigcompをDOSターゲットとして攻撃して、状態で満たします。
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接続を許可しないでください。セクション4.2.1で「連続モード」と記載されている代替Sigcompの使用については、攻撃者は、低レベルでDOS保護がない限り、任意の数のアクティブなUDVMを作成できます（たとえば、適切な構成でTLSを使用することにより）。
- 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には、IANAによって作成された1バイトの名前スペース、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
アビゲイルサーティーはウェストローレンスマークコンロイクリスチャンシュミットマックスリーゲルラース - エリックジョンソンフォーファンフォーグレンクリスタースバンブロミゲルガルシアクリストファークラントンキーム
for valuable input and review.
貴重な入力とレビューのため。
[RFC-1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC-1662]シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Eastlake、3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[RFC-1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[RFC-1951] Deutsch、P。、「圧縮データ形式の仕様バージョン1.3」、RFC 1951、1996年5月。
[RFC-2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC -2026] Bradner、S。、「インターネット標準プロセス-Revision 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.、Rao、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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwartzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。V. Paxson、「Stream Control Transmission Protocol」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M. and E. Schooler、 "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] Hannu、H.、Christoffersson、J.、Forsgren、S.、Leung、K.C.、Liu、Z.、R。Price、「Signaling Compression（Sigcomp） - 拡張操作」、RFC 3321、2003年1月。
Richard Price Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom
リチャード・プライス・ローク・マナー・リサーチ・リミテッド・ロムシー、ハンツ、SO51 0ZNイギリス
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28334 Bremen, Germany
Carsten Bormann Universitaet Bremen Tzi Postfach 330440 D-28334ブレーメン、ドイツ
Phone: +49 421 218 7024 EMail: cabo@tzi.org Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea, Sweden
電話：49 421 218 7024メール：cabo@tzi.org Jan Christoffersson Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Hans Hannu Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving, TX 75039
Zhigang Liu Nokia Research Center 6000 Connection Drive Irving、TX 75039
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。