[要約] RFC 4464は、SigComp（Signaling Compression）のユーザーガイドであり、SigCompプロトコルの使用方法と目的を説明しています。SigCompは、シグナリングメッセージの圧縮を提供し、ネットワークの効率性を向上させることを目的としています。
Network Working Group A. Surtees
Request for Comments: 4464 M. West
Category: Informational Siemens/Roke Manor Research
May 2006
Signaling Compression (SigComp) Users' Guide
シグナリング圧縮（SIGCOMP）ユーザーガイド
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document provides an informational guide for users of the Signaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets.
このドキュメントは、シグナリング圧縮（SIGCOMP）プロトコルのユーザー向けの情報ガイドを提供します。このドキュメントの目的は、たとえば、圧縮アルゴリズムの選択と、紛失または誤ったパケットに対する堅牢性のレベルなど、SigCompの実装の決定を行う際にユーザーを支援することです。
Table of Contents
目次
1. Introduction ....................................................3
2. Overview of the User Guide ......................................3
3. UDVM Assembly Language ..........................................4
3.1. Lexical Level ..............................................4
3.2. Syntactic Level ............................................5
3.2.1. Expressions .........................................7
3.2.2. Instructions ........................................8
3.2.3. Directives ..........................................9
3.2.4. Labels .............................................10
3.3. Uploading the Bytecode to the UDVM ........................11
4. Compression Algorithms .........................................12
4.1. Well-known Compression Algorithms .........................12
4.1.1. LZ77 ...............................................12
4.1.2. LZSS ...............................................16
4.1.3. LZW ................................................18
4.1.4. DEFLATE ............................................21
4.1.5. LZJH ...............................................24
4.2. Adapted Algorithms ........................................28
4.2.1. Modified DEFLATE ...................................28
5. Additional SigComp Mechanisms ..................................31
5.1. Acknowledging a State Item ................................32
5.2. Static Dictionary .........................................33
5.3. CRC Checksum ..............................................34
5.4. Announcing Additional Resources ...........................35
5.5. Shared Compression ........................................37
6. Security Considerations ........................................38
7. Acknowledgements ...............................................38
8. Intellectual Property Right Considerations .....................38
9. Informative References .........................................38
Appendix A. UDVM Bytecode for the Compression Algorithms ..........40
A.1. Well-known Algorithms .....................................40
A.1.1. LZ77 ..............................................40
A.1.2. LZSS ..............................................40
A.1.3. LZW ...............................................40
A.1.4. DEFLATE ...........................................40
A.1.5. LZJH ..............................................41
A.2. Adapted Algorithms ........................................41
A.2.1. Modified DEFLATE ...................................41
This document provides an informational guide for users of the SigComp protocol, RFC 3320 [2]. The idea behind SigComp is to standardize a Universal Decompressor Virtual Machine (UDVM) that can be programmed to understand the output of many well-known compressors including DEFLATE [8] and LZW [7]. The bytecode for the chosen compression algorithm is uploaded to the UDVM as part of the compressed data.
このドキュメントは、SIGCOMPプロトコルRFC 3320 [2]のユーザー向けの情報ガイドを提供します。Sigcompの背後にあるアイデアは、DERLATE [8]やLZW [7]を含む多くのよく知られているコンプレッサーの出力を理解するようにプログラムできるユニバーサルディクプレッサー仮想マシン（UDVM）を標準化することです。選択した圧縮アルゴリズムのバイトコードは、圧縮データの一部としてUDVMにアップロードされます。
The basic SigComp RFC describes the actions that an endpoint must take upon receiving a SigComp message. However, the entity responsible for generating new SigComp messages (the SigComp compressor) is left as an implementation decision; any compressor can be used provided that it generates SigComp messages that can be successfully decompressed by the receiving endpoint.
基本的なSigcomp RFCは、SigCompメッセージの受信時にエンドポイントがとらなければならないアクションを説明しています。ただし、新しいSigCompメッセージ（SIGCOMPコンプレッサー）の生成を担当するエンティティは、実装決定として残されています。受信エンドポイントによって正常に解凍できるSigCompメッセージを生成する場合、任意のコンプレッサーを使用できます。
This document gives examples of a number of different compressors that can be used by the SigComp protocol. It also gives examples of how to use some of the mechanisms (such as acknowledgements) described in RFC 3321 [3].
このドキュメントは、SigCompプロトコルで使用できるさまざまなコンプレッサーの例を示しています。また、RFC 3321 [3]に記載されているメカニズム（謝辞など）の一部を使用する方法の例を示しています。
When implementing a SigComp compressor, the first step is to choose a compression algorithm that can encode the application messages into a (hopefully) smaller form. Since SigComp can upload bytecode for new algorithms to the receiving endpoint, arbitrary compression algorithms can be supported provided that suitable bytecode has been written for the corresponding decompressor.
SigCompコンプレッサーを実装するとき、最初のステップは、アプリケーションメッセージを（できれば）小さなフォームにエンコードできる圧縮アルゴリズムを選択することです。Sigcompは新しいアルゴリズムのBytecodeを受信エンドポイントにアップロードできるため、対応する抑制器に適切なバイトコードが記述されている場合、任意の圧縮アルゴリズムをサポートできます。
This document provides example bytecode for the following algorithms:
このドキュメントは、次のアルゴリズムのバイトコードの例を提供します。
1. LZ77 2. LZSS 3. LZW 4. DEFLATE 5. LZJH
1. LZ77 2. LZSS 3. LZW 4. DEFLATE 5. LZJH
Any of the above algorithms may be useful depending on the desired compression ratio, processing and memory requirements, code size, implementation complexity, and Intellectual Property (IPR) considerations.
上記のアルゴリズムのいずれかは、目的の圧縮比、処理とメモリの要件、コードサイズ、実装の複雑さ、知的財産（IPR）の考慮事項に応じて役立つ場合があります。
As well as encoding the application messages using the chosen algorithm, the SigComp compressor is responsible for ensuring that messages can be correctly decompressed even if packets are lost or misordered during transmission. The SigComp feedback mechanism can be used to acknowledge successful decompression at the remote endpoint.
選択したアルゴリズムを使用してアプリケーションメッセージをエンコードするだけでなく、SIGCOMPコンプレッサーは、送信中にパケットが失われたり誤って命じられていても、メッセージを正しく解凍できるようにする責任があります。SigCompフィードバックメカニズムを使用して、リモートエンドポイントでの減圧の成功を認識できます。
The following robustness techniques and other mechanisms specific to the SigComp environment are covered in this document:
このドキュメントでは、次の堅牢性技術とSigComp環境に固有のその他のメカニズムについて説明します。
1. Acknowledgements using the SigComp feedback mechanism 2. Static dictionary 3. Cyclic redundancy code (CRC) checksum 4. Announcing additional resources 5. Shared compression
1. SIGCOMPフィードバックメカニズムを使用した謝辞
Any or all of the above mechanisms can be implemented in conjunction with the chosen compression algorithm. An example subroutine of UDVM bytecode is provided for each of the mechanisms; these subroutines can be added to the bytecode for one of the basic compression algorithms. (Note: The subroutine or the basic algorithm may require minor modification to ensure they work together correctly.)
上記のメカニズムのいずれかまたはすべてを、選択した圧縮アルゴリズムと組み合わせて実装できます。各メカニズムに対してUDVM bytecodeのサブルーチンの例が提供されます。これらのサブルーチンは、基本的な圧縮アルゴリズムのいずれかのバイトコードに追加できます。（注：サブルーチンまたは基本的なアルゴリズムは、それらが正しく連携することを保証するためにマイナーな変更を必要とする場合があります。）
Writing UDVM programs directly in bytecode would be a daunting task, so a simple assembly language is provided to facilitate the creation of new decompression algorithms. The assembly language includes mnemonic codes for each of the UDVM instructions, as well as simple directives for evaluating integer expressions, padding the bytecode, and so forth.
UDVMプログラムをByteCodeで直接記述するのは困難な作業であるため、新しい減圧アルゴリズムの作成を促進するために簡単なアセンブリ言語が提供されます。アセンブリ言語には、各UDVM命令のニーモニックコード、および整数式を評価するための簡単な指令、バイトコードのパディングなどが含まれます。
The syntax of the UDVM assembly language uses the customary two-level description technique, partitioning the grammar into a lexical and a syntactic level.
UDVMアセンブリ言語の構文は、一般的な2レベルの説明手法を使用して、文法を語彙レベルと構文レベルに分割します。
On a lexical level, a string of assembly consists of zero or more tokens optionally separated by whitespace. Each token can be a text name, an instruction opcode, a delimiter, or an integer (specified as decimal, binary, or hex).
語彙レベルでは、アセンブリの文字列は、ゼロ以上のトークンで構成されています。各トークンは、テキスト名、命令オペコード、デリミッター、または整数（小数、バイナリ、またはヘックスとして指定）です。
The following ABNF description, RFC 4234 [1], specifies the syntax of a token:
次のABNF説明、RFC 4234 [1]は、トークンの構文を指定します。
token = (name / opcode / delimiter / dec / bin / hex)
name = (lowercase / "_") 0*(lowercase / digit / "_")
opcode = uppercase *(uppercase / digit / "-")
delimiter = "." / "," / "!" / "$" / ":" / "(" / ")" /
operator
dec = 1*(digit)
bin = "0b" 1*("0" / "1")
hex = "0x" 1*(hex-digit)
hex-digit = digit / %x41-46 / %x61-66
digit = %x30-39
uppercase = %x41-5a
lowercase = %x61-7a
operator = "+" / "-" / "*" / "/" / "%" / "&" / "|" /
"^" / "~" / "<<" / ">>"
When parsing for tokens, the longest match is applied, i.e., a token is the longest string that matches the <token> rule specified above.
トークンを解析するとき、最長の一致が適用されます。つまり、トークンは上記の<token>ルールに一致する最も長い文字列です。
The syntax of whitespace and comments is specified by the following ABNF:
Whitespaceとコメントの構文は、次のABNFによって指定されています。
ws = *(%x09 / %x0a / %x0d / %x20 / comment)
comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff)
(%x0a / %x0d)
Whitespace that matches <ws> is skipped between tokens, but serves to terminate the longest match for a token.
<WS>に一致する白文学は、トークンの間でスキップされますが、トークンの最長のマッチを終了するのに役立ちます。
Comments are specified by the symbol ";" and are terminated by the end of the line, for example:
コメントはシンボル「;」によって指定されます。たとえば、行の端までに終了します。
LOAD (temp, 1) ; This is a comment.
負荷（温度、1）;これはコメントです。
Any other input is a syntax error.
他の入力は構文エラーです。
When parsing on the lexical level, the string of assembly should be divided up into a list of successive tokens. The whitespace and comments should also be deleted. The assembly should then be parsed on the syntactic level as explained in Section 3.2.
語彙レベルで解析する場合、一連のアセンブリを連続したトークンのリストに分割する必要があります。Whitespaceとコメントも削除する必要があります。セクション3.2で説明されているように、アセンブリは構文レベルで解析する必要があります。
Once the string of assembly has been divided into tokens as per Section 3.1, the next step is to convert the assembly into a string of UDVM bytecode.
セクション3.1に従って、アセンブリの文字列がトークンに分割されたら、次のステップはアセンブリをUDVMバイトコードの文字列に変換することです。
On a syntactic level, a string of assembly consists of zero or more instructions, directives, or labels, each of which is itself built up from one or more lexical tokens.
構文レベルでは、一連のアセンブリは、ゼロ以上の指示、指示、またはラベルで構成されます。それぞれがそれぞれ1つ以上の語彙トークンから構築されています。
The following ABNF description specifies the syntax of the assembly language. Note that the lexical parsing step is assumed to have been carried out; so in particular, the boundaries between tokens are already known, and the comments and whitespace have been deleted:
次のABNF説明は、アセンブリ言語の構文を指定します。語彙解析ステップは実行されたと想定されることに注意してください。したがって、特に、トークン間の境界は既に知られており、コメントとホワイトスペースは削除されています。
assembly = *(instruction / directive / label)
instruction = opcode ["(" operand *("," operand) ")"]
operand = [["$"] expression]
; Operands can be left blank if they can
; be automatically inferred by the
; compiler, e.g., a literal operand
; that specifies the total number of
; operands for the instruction.
; When "$" is prepended to an operand,
; the corresponding integer is an
; address rather than the actual operand
; value. This symbol is mandatory for
; reference operands, optional for
; multitypes and addresses, and
; disallowed for literals.
label = ":" name
directive = padding / data / set / readonly /
unknown-directive
unknown-directive = name ["(" expression *("," expression) ")"]
; The parser can ignore unknown
; directives. The resulting bytecode
; may or may not generate the expected
; results.
padding = ("pad" / "align" / "at") "(" expression ")"
data = ("byte" / "word") "(" expression *(","
expression) ")"
readonly = "readonly" "(" "0" / "1" ")"
set = "set" "(" name "," expression ")"
expression = value / "(" expression operator expression ")"
value = dec / bin / hex / name / "." / "!"
; "." is the location of this
; instruction/directive, whereas "!" is
; the location of the closest
; DECOMPRESSION-FAILURE
The following sections define how to convert the instructions, labels and directives into UDVM bytecode:
次のセクションでは、手順、ラベル、およびディレクティブをUDVM bytecodeに変換する方法を定義します。
The operand values needed by particular instructions or directives can be given in the form of expressions. An expression can include one or more values specified as decimal, binary, or hex (binary values are preceded by "0b" and hex values are preceded by "0x"). The expression may also include one or more of the following operators:
特定の命令または指令で必要なオペランド値は、式の形式で指定できます。式には、小数、バイナリ、またはヘックスとして指定された1つ以上の値を含めることができます（バイナリ値の前には「0b」、16進値の前には「0x」があります）。式には、次の演算子の1つ以上が含まれる場合があります。
"+" Addition "-" Subtraction "*" Multiplication "/" Integer division "%" Modulo arithmetic (a%b := a modulo b) "&" Binary AND "|" Binary OR "^" Binary XOR "~" Binary XNOR "<<" Binary LSHIFT ">>" Binary RSHIFT
"" Addition " - "減算 "*"乗算 "/"整数分割 "％" modulo算術（a％b：= a modulo b）＆ "binary and" | "バイナリまたは「^」バイナリxor "〜" binary xnor "<<" binary lshift ">>" binary rshift
The operands for each operator must always be surrounded by parentheses so that the order in which the operators should be evaluated is clear. For example:
各オペレーターのオペランドは、オペレーターを評価する順序が明確になるように、常に括弧で囲まれている必要があります。例えば：
((1 + (2 * 3)) & (0xabcd - 0b00101010)) gives the result 3.
（（1（2 * 3））＆（0XABCD -0B00101010））結果3。
Expressions can also include the special values "." and "!". When the symbol "." is encountered, it is replaced by the location in the bytecode of the current instruction/directive. When the symbol "!" is encountered it is replaced by the location in the bytecode of the closest DECOMPRESSION-FAILURE instruction (i.e., the closest zero byte). This can be useful when writing UDVM instructions that call a decompression failure, for example:
式には、特別な値を含めることもできます。と "！"。シンボル「。」遭遇すると、現在の命令/指令のバイトコード内の場所に置き換えられます。シンボル「！」遭遇すると、最も近い減圧命令（つまり、最も近いゼロバイト）のバイトコード内の場所に置き換えられます。これは、減圧障害を呼び出すUDVMの指示を書くときに役立ちます。
INPUT-BYTES (1, temp, !)
input-bytes（1、temp、！）
The above instruction causes a decompression failure to occur if it tries to input data from beyond the end of the compressed message.
上記の命令により、圧縮メッセージの終わりを超えてデータを入力しようとした場合、減圧の失敗が発生します。
Note: When using "!" in the assembly language to generate bytecode, care must be taken to ensure that the address of the zero used at bytecode generation time will still contain zero when the bytecode is run. The readonly directive (see Section 3.2.3) can be used to do this.
注：「！」を使用する場合バイトコードを生成するためのアセンブリ言語では、バイトコードの生成時間で使用されるゼロのアドレスがバイトコードの実行時にゼロが含まれるように注意する必要があります。読み取り指令（セクション3.2.3を参照）を使用してこれを行うことができます。
It is also possible to assign integer values to text names: when a text name is encountered in an expression, it is replaced by the integer value assigned to it. Section 3.2.3 explains how to assign integer values to text names.
また、整数値をテキスト名に割り当てることもできます。式でテキスト名が遭遇した場合、それに割り当てられた整数値に置き換えられます。セクション3.2.3では、テキスト名に整数値を割り当てる方法について説明します。
A UDVM instruction is specified by the instruction opcode followed by zero or more operands. The instruction operands are enclosed in parentheses and separated by commas, for example:
UDVM命令は、命令opcodeに続いてゼロ以上のオペランドによって指定されます。命令手術は括弧で囲まれ、コンマで分離されています。
ADD ($3, 4)
追加（$ 3、4）
When generating the bytecode, the parser should replace the instruction opcode with the corresponding 1-byte value as per Figure 11 of SigComp [2].
バイトコードを生成する場合、パーサーは、SigComp [2]の図11に従って、命令オペコードを対応する1バイト値に置き換える必要があります。
Each operand consists of an expression that evaluates to an integer, optionally preceded by the symbol "$". This symbol indicates that the supplied integer value must be interpreted as the memory address at which the operand value can be found, rather than the actual operand value itself.
各オペランドは、オプションでシンボル「$」が先行する整数に対して評価する式で構成されています。この記号は、供給された整数値が、実際のオペランド値自体ではなく、オペランド値を見つけることができるメモリアドレスとして解釈する必要があることを示しています。
When converting each instruction operand to bytecode, the parser first determines whether the instruction expects the operand to be a literal, a reference, a multitype, or an address. If the operand is a literal, then, as per Figure 8 of SigComp, the parser inserts bytecode (usually the shortest) capable of encoding the supplied operand value.
各命令オペランドをByteCodeに変換するとき、パーサーは最初に、命令がオペランドがリテラル、参照、マルチタイプ、またはアドレスであることを期待するかどうかを決定します。オペランドが文字通りである場合、Sigcompの図8によると、パーサーは、供給されたオペランド値をエンコードできるバイトコード（通常は最短）を挿入します。
Since literal operands are used to indicate the total number of operands for an instruction, it is possible to leave a literal operand blank and allow its value to be inferred automatically by the assembler. For example:
文字通りのオペランドは、指示のためのオペランドの総数を示すために使用されるため、リテラルオペランドの空白を残し、アセンブラーによってその値を自動的に推測できるようにすることができます。例えば：
MULTILOAD (64, , 1, 2, 3, 4)
マルチロード（64、、1、2、3、4）
The missing operand should be given the value 4 because it is followed by a total of 4 operands.
不足しているオペランドには、合計4つのオペランドが続くため、値4を与えられる必要があります。
If the operand is a reference, then, as per Figure 9 of SigComp, the parser inserts bytecode (usually the shortest) capable of encoding the supplied memory address. Note that reference operands will always be preceded by the symbol "$" in assembly because they always encode memory addresses rather than actual operand values.
オペランドが参照である場合、SigCompの図9に従って、パーサーは、付属のメモリアドレスをエンコードできるバイトコード（通常は最短）を挿入します。参照オペランドの前には、実際のオペランド値ではなくメモリアドレスを常にエンコードするため、アセンブリのシンボル「$」が常に先行することに注意してください。
If the operand is a multitype, then the parser first checks whether the symbol "$" is present. If so, then, as per Figure 10 of SigComp, it inserts bytecode (usually the shortest) capable of encoding the supplied integer as a memory address. If not, then, as per Figure 10 of SigComp, it inserts bytecode (usually the shortest) that encodes the supplied integer as an operand value.
オペランドがマルチタイプの場合、パーサーは最初にシンボル「$」が存在するかどうかを確認します。その場合、SigCompの図10によると、付属の整数をメモリアドレスとしてエンコードできるBytecode（通常は最短）を挿入します。そうでない場合、SigCompの図10によると、付属の整数をオペランド値としてコードするBytecode（通常は最短）を挿入します。
If the operand is an address, then the parser checks whether the symbol "$" is present. If so, then the supplied integer is encoded as a memory address, just as for the multitype instruction above. If not, then the byte position of the opcode is subtracted from the supplied integer modulo 16, and the result is encoded as an operand value as per Figure 10 of SigComp.
オペランドがアドレスの場合、パーサーはシンボル「$」が存在するかどうかを確認します。その場合、上記のマルチタイプ命令と同様に、付属の整数はメモリアドレスとしてエンコードされます。そうでない場合は、オペコードのバイト位置が供給された整数Modulo 16から差し引かれ、結果はSigCompの図10に従ってオペランド値としてエンコードされます。
The length of the resulting bytecode is dependent on the parser in use. There can be several correct and usable representations of the same instruction.
結果のバイトコードの長さは、使用中のパーサーに依存します。同じ命令のいくつかの正確で使用可能な表現があります。
The assembly language provides a number of directives for evaluating expressions, moving instructions to a particular memory address, etc.
アセンブリ言語は、式を評価するための多くの指示、特定のメモリアドレスなどに指示を移動するための指示を提供します。
The directives "pad", "align", and "at" can be used to add padding to the bytecode.
ディレクティブ「パッド」、「アライン」、および「at」を使用して、バイトコードにパディングを追加できます。
The directive "pad (n)" appends n consecutive padding bytes to the bytecode. The actual value of the padding bytes is unimportant, so when the bytecode is uploaded to the UDVM, the padding bytes can be set to the initial values contained in the UDVM memory (this helps to reduce the size of a SigComp message).
指令「Pad（n）」は、n連続したパディングバイトをbytecodeに追加します。パディングバイトの実際の値は重要ではないため、バイトコードがUDVMにアップロードされると、パディングバイトはUDVMメモリに含まれる初期値に設定できます（これにより、SIGCOMPメッセージのサイズを縮小するのに役立ちます）。
The directive "align (n)" appends the minimum number of padding bytes to the bytecode such that the total number of bytes of bytecode generated so far is a multiple of n bytes. If the bytecode is already aligned to a multiple of n bytes, then no padding bytes are added.
指令「Align（n）」は、パディングバイトの最小数をバイトコードに追加して、これまでに生成されたバイトコードの総数がnバイトの倍数であるようにします。バイトコードがすでにnバイトの倍数に整列されている場合、パディングバイトは追加されていません。
The directive "at (n)" appends enough padding bytes to the bytecode such that the total number of bytes of bytecode generated so far is exactly n bytes. If more than n bytes have already been generated before the "at" directive is encountered then the assembly code contains an error.
指令「at（n）」は、これまでに生成されたバイトコードの総数が正確にNバイトであるように、バイトコードに十分なパディングバイトを追加します。「at」ディレクティブが発生する前にnバイト以上がすでに生成されている場合、アセンブリコードにはエラーが含まれます。
The directives "byte" and "word" can be used to add specific data strings to the bytecode.
ディレクティブ「バイト」と「単語」を使用して、特定のデータ文字列をbytecodeに追加できます。
The directive "byte (n[0],..., n[k-1])" appends k consecutive bytes to the bytecode. The byte string is supplied as expressions that evaluate to give integers n[0],..., n[k-1] from 0 to 255.
指令「バイト（n [0]、...、n [k-1]）」は、k連続バイトをbytecodeに追加します。バイト文字列は、0から255まで整数n [0]、...、n [k-1]を与えるように評価する式として提供されます。
The directive "word (n[0],..., n[k-1])" appends k consecutive 2-byte words to the bytecode. The word string is supplied as expressions that evaluate to give integers n[0],..., n[k-1] from 0 to 65535.
指令「単語（n [0]、...、n [k-1]）」は、k連続した2バイト単語をbytecodeに追加します。単語の文字列は、0から65535まで整数n [0]、...、n [k-1]を与えるように評価する式として提供されます。
The directive "set (name, n)" assigns an integer value n to a specified text name. The integer value can be supplied in the form of an expression.
ディレクティブ「セット（名前、n）」は、指定されたテキスト名に整数値nを割り当てます。整数値は、式の形で提供できます。
The directive "readonly (n)" where n is 0 or 1 can be used to indicate that an area of memory could be changed (0) or will not be changed (1) during the execution of the UDVM. This directive could be used, for example, in conjunction with "!" to ensure that the address of the zero used will still contain zero when the bytecode is executed. If no readonly directive is used, then any address containing zero can be used by "!" (i.e., by default, there is assumed to be a readonly (1) directive at Address 0) and it is up to the author of the assembly code to ensure that the address in question will still contain zero when the bytecode is executed. If the readonly directive is used, then bytes between a readonly (0) and readonly (1) pair are NOT to be used by "!". When a readonly directive has been used, the bytes obey that directive from that address to either another readonly directive or the end of UDVM memory, whichever comes first.
nは0または1である「readonly（n）」を使用して、UDVMの実行中にメモリの領域を変更できるか（1）（1）変更できないことを示すことができます。この指令は、たとえば、「！」と組み合わせて使用できます。使用されるゼロのアドレスがバイトコードの実行時にゼロを含むことを確認します。readonlyディレクティブが使用されない場合、ゼロを含むアドレスは「！」で使用できます。（つまり、デフォルトでは、アドレス0にreadonly（1）指令があると想定されています）。また、問題のアドレスにバイトコードが実行されたときにゼロが含まれていることを確認するのは、アセンブリコードの著者次第です。readonlyディレクティブを使用する場合、readonly（0）とreadonly（1）ペアの間のバイトは「！」で使用されません。Readonly指令が使用された場合、バイトはそのアドレスから別のReadonly指令またはUDVMメモリの終了のいずれか最初のいずれか最初のいずれかのいずれかのいずれかのいずれかのいずれかのいずれかのいずれかのどちらかのいずれかに従っています。
A label is a special directive used to assign memory addresses to text names.
ラベルは、メモリアドレスをテキスト名に割り当てるために使用される特別な指令です。
Labels are specified by a single colon followed by the text name to be defined. The (absolute) position of the byte immediately following the label is evaluated and assigned to the text name. For example:
ラベルは、単一のコロンで指定され、その後に定義するテキスト名が指定されます。ラベルの直後のバイトの（絶対）位置が評価され、テキスト名に割り当てられます。例えば：
:start
：始める
LOAD (temp, 1)
負荷（温度、1）
Since the label "start" occurs at the beginning of the bytecode, it is assigned the integer value 0.
ラベル「start」はbytecodeの先頭に発生するため、整数値0が割り当てられます。
Note that writing the label ":name" has exactly the same behavior as writing the directive "set (name, .)".
ラベルを書く「：name」は、ディレクティブ「セット（名前、。）」を書くのとまったく同じ動作を持っていることに注意してください。
Once the parser has converted a string of assembly into the corresponding bytecode, it must be copied to the UDVM memory beginning at Address 0 and then executed, beginning from the first UDVM instruction in the bytecode.
パーサーが一連のアセンブリを対応するバイトコードに変換したら、bytecodeでの最初のudvm命令から始まるアドレス0から始まり、実行されたUDVMメモリにコピーする必要があります。
SigComp provides the following message format for uploading bytecode to the UDVM:
Sigcompは、UDVMにBytecodeをアップロードするための次のメッセージ形式を提供します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| code_len |
+---+---+---+---+---+---+---+---+
| code_len | destination |
+---+---+---+---+---+---+---+---+
| |
: uploaded UDVM bytecode :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
The destination field should be set to the memory address of the first UDVM instruction. Note that if this address cannot be represented by the destination field, then the bytecode cannot be uploaded to the UDVM using the standard SigComp header. In particular, the memory address of the first UDVM instruction must always be a multiple of 64 bytes or the standard SigComp header cannot be used. Of course, there may be other ways to upload the bytecode to the UDVM, such as retrieving the bytecode directly via the INPUT-BYTES instruction.
宛先フィールドは、最初のUDVM命令のメモリアドレスに設定する必要があります。このアドレスを宛先フィールドで表すことができない場合、標準のSigCompヘッダーを使用してByteCodeをUDVMにアップロードできないことに注意してください。特に、最初のUDVM命令のメモリアドレスは常に64バイトの倍数でなければならないか、標準のSigCompヘッダーを使用できません。もちろん、入力バイト命令を介してバイトコードを直接取得するなど、バイトコードをUDVMにアップロードする他の方法があるかもしれません。
Additionally, all memory addresses between Address 0 and Address 31 inclusive are initialized to endpoint-specific values by the UDVM, so they must be specified as padding in the bytecode, or the standard SigComp header cannot be used. Memory addresses from Address 32 to Address (destination - 1) inclusive are initialized to 0, so they must be specified either as padding or as 0s if the bytecode is to be successfully uploaded using the standard SigComp header.
さらに、アドレス0とアドレス31の包括的な間のすべてのメモリアドレスは、UDVMによってエンドポイント固有の値に初期化されるため、バイトコードのパディングとして指定する必要があります。アドレス32からアドレス（宛先-1）へのメモリアドレスは0に初期化されるため、標準のSIGCOMPヘッダーを使用してバイトコードを正常にアップロードする場合は、パディングまたは0Sとして指定する必要があります。
The code_len field should be set to the smallest value such that all memory addresses beginning at Address (destination + code_len) are either as initialised by the UDVM (to 0) or as set by the bytecode at runtime.
code_lenフィールドは、アドレス（宛先code_len）から始まるすべてのメモリアドレスがudvm（〜0）によって初期化されるか、実行時にbytecodeによって設定されているように、最小値に設定する必要があります。
The "uploaded UDVM bytecode" should be set to contain the segment of bytecode that lies between Address (destination) and Address (destination + code_len - 1) inclusive.
「アップロードされたudvm bytecode」は、アドレス（宛先）とアドレス（宛先code_len -1）を含むアドレス（宛先code_len -1）の間にあるbytecodeのセグメントを含めるように設定する必要があります。
This section describes a number of compression algorithms that can be used by a SigComp compressor. In each case, the document provides UDVM bytecode for the corresponding decompression algorithm, which can be uploaded to the receiving endpoint as part of a SigComp message. Each algorithm (as written in this section) assumes that there is a 16K decompression memory size, there are 16 cycles per bit, and there is an 8K state memory size. Decompression will succeed with a smaller value for state memory size; however, the full state will not be created.
このセクションでは、SigCompコンプレッサーが使用できる多くの圧縮アルゴリズムについて説明します。いずれの場合も、ドキュメントは、対応する減圧アルゴリズムのUDVMバイトコードを提供します。これは、SigCompメッセージの一部として受信エンドポイントにアップロードできます。各アルゴリズム（このセクションで書かれているように）は、16K減圧メモリサイズがあり、ビットあたり16サイクルがあり、8K状態メモリサイズがあることを前提としています。減圧は、状態記憶サイズの値が少ないことで成功します。ただし、完全な状態は作成されません。
Section 4.1.1 covers a simple algorithm in some detail, including the steps required to compress and decompress a SigComp message. The remaining sections cover well-known compression algorithms that can be adapted for use in SigComp with minimal modification.
セクション4.1.1は、SigCompメッセージを圧縮および解凍するために必要な手順を含む、ある程度詳細に簡単なアルゴリズムをカバーします。残りのセクションでは、最小限の変更でSigcompで使用するために適応できるよく知られている圧縮アルゴリズムをカバーしています。
This section describes how to implement a very simple compression algorithm based on LZ77 [5].
このセクションでは、LZ77 [5]に基づいて非常に単純な圧縮アルゴリズムを実装する方法について説明します。
A compressed message generated by the simplified LZ77 scheme consists of a sequence of 4-byte characters, where each character contains a 2-byte position value followed by a 2-byte length value. Each pair of integers identifies a byte string in the UDVM memory; when concatenated, these byte strings form the decompressed message.
単純化されたLZ77スキームによって生成された圧縮メッセージは、4バイト文字のシーケンスで構成され、各文字には2バイトの位置値が含まれ、その後に2バイトの長さの値が含まれます。整数の各ペアは、UDVMメモリ内のバイト文字列を識別します。連結すると、これらのバイト文字列は減圧メッセージを形成します。
When implementing a bytecode decompressor for the simplified LZ77 scheme, the UDVM memory is partitioned into five distinct areas, as shown below:
単純化されたLZ77スキームのByteCode Decompressorを実装する場合、UDVMメモリは、以下に示すように、5つの異なる領域に分割されます。
0 64 128 256 512
| scratch-pad | variables | bytecode | dictionary | circular buffer |
+-------------+-----------+----------+------------+-----------------+
<-----------> <---------> <--------> <----------> <--------------->
64 bytes 64 bytes 128 bytes 256 bytes 512+ bytes
The first 128 bytes are used to hold the 2-byte variables needed by the LZ77 decompressor. Within this memory, the first 64 bytes are used as a scratch-pad, holding the 2-byte variables that can be discarded between SigComp messages. In contrast, the next 64 bytes (and in fact all of the UDVM memory starting from Address 64) should be saved after decompressing a SigComp message to improve the compression ratio of subsequent messages.
最初の128バイトは、LZ77分解器が必要とする2バイト変数を保持するために使用されます。このメモリ内では、最初の64バイトがスクラッチパッドとして使用され、SigCompメッセージ間で破棄できる2バイト変数を保持します。対照的に、次の64バイト（実際、アドレス64から始まるUDVMメモリのすべて）は、SigCompメッセージを減圧して後続のメッセージの圧縮比を改善した後に保存する必要があります。
The bytecode for the LZ77 decompressor is stored beginning at Address 128. A total of 128 bytes are reserved for the bytecode although the LZ77 decompressor requires less; this allows room for adding additional features to the decompressor at a later stage.
LZ77減圧装置のバイトコードは、アドレス128から保存されます。LZ77分解器の必要性は少なくなりますが、合計128バイトがバイトコードに予約されています。これにより、後の段階で減圧器に追加機能を追加する余地があります。
The next 256 bytes are initialized by the bytecode to contain the integers 0 to 255 inclusive. The purpose of this memory area is to provide a dictionary of all possible uncompressed characters; this is important to ensure that the compressor can always generate a sequence of position/length pairs that encode a given message. For example, a byte with value 0x41 (corresponding to the ASCII character "A") can be found at Address 0x0141 of the UDVM memory, so the compressed character 0x0141 0001 will decompress to give this ASCII character. Note that encoding each byte in the application message as a separate 4-byte compressed character is not recommended, however, as the resulting "compressed" message is four times as large as the original uncompressed message.
次の256バイトは、バイトコードによって初期化され、整数0〜255が包括的に含まれます。このメモリ領域の目的は、可能なすべての非圧縮文字の辞書を提供することです。これは、コンプレッサーが特定のメッセージをエンコードする位置/長さのペアのシーケンスを常に生成できるようにするために重要です。たとえば、値0x41のバイト（ASCII文字「A」に対応）は、UDVMメモリのアドレス0x0141にあるため、圧縮文字0x0141 0001が減圧されてこのASCII文字が得られます。ただし、結果の「圧縮」メッセージは元の非圧縮メッセージの4倍の大きさであるため、アプリケーションメッセージ内の各バイトを別の4バイト圧縮文字としてエンコードすることは推奨されません。
The compression ratio of LZ77 is improved by the remaining UDVM memory, which is used to store a history buffer containing the previously decompressed messages. Compressed characters can point to strings that have previously been decompressed and stored in the buffer, so the overall compression ratio of the LZ77 algorithm improves as the decompressor "learns" more text strings and is able to encode longer strings using a single compressed character. The buffer is circular, so older messages are overwritten by new data when the buffer becomes full.
LZ77の圧縮比は、以前に減圧されたメッセージを含む履歴バッファーを保存するために使用される残りのUDVMメモリによって改善されます。圧縮された文字は、以前に解凍されてバッファーに保存されていた文字列を指すことができるため、LZ77アルゴリズムの全体的な圧縮比は、圧縮機がより多くのテキスト文字列を「学習」し、単一の圧縮文字を使用して長い文字列をエンコードすることができます。バッファーは円形であるため、バッファがいっぱいになると、古いメッセージは新しいデータによって上書きされます。
The steps required to implement an LZ77 compressor and decompressor are similar, although compression is more processor-intensive as it requires a searching operation to be performed. Assembly for the simplified LZ77 decompressor is given below:
LZ77コンプレッサーと分解器を実装するために必要な手順は類似していますが、圧縮は検索操作を実行する必要があるため、プロセッサ集約型です。単純化されたLZ77減圧器のアセンブリを以下に示します。
; Variables that do not need to be stored after decompressing each ; SigComp message are stored here:
;それぞれを減圧した後に保存する必要のない変数。Sigcompメッセージはここに保存されます：
at (32)
で（32）
:position_value pad (2)
:length_value pad (2)
at (42)
set (requested_feedback_location, 0)
set（request_feedback_location、0）
; The UDVM registers must be stored beginning at Address 64:
;UDVMレジスタは、アドレス64から保存する必要があります。
at (64)
で（64）
; Variables that should be stored after decompressing a message are
; stored here. These variables will form part of the SigComp state
; item created by the bytecode:
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
set（returned_parameters_location、0）
align (64)
align（64）
:initialize_memory
：intialize_memory
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
set（udvm_memory_size、8192）set（state_length、（udvm_memory_size -64））
; The UDVM registers byte_copy_left and byte_copy_right are set to
; indicate the bounds of the circular buffer in the UDVM memory. A
; variable decompressed_pointer is also created and set pointing to
; the start of the circular buffer:
MULTILOAD (64, 3, circular_buffer, udvm_memory_size, circular_buffer)
MultiLoad（64、3、Circular_Buffer、udvm_memory_size、circular_buffer）
; The "dictionary" area of the UDVM memory is initialized to contain ; the values 0 to 255 inclusive:
;UDVMメモリの「辞書」領域は、封じ込められるように初期化されています。値0〜255包括的：
MEMSET (static_dictionary, 256, 0, 1)
memset（static_dictionary、256、0、1）
:decompress_sigcomp_message
：decompress_sigcomp_message
:next_character
：next_character
; The next character in the compressed message is read by the UDVM
; and the position and length integers are stored in the variables
; position_value and length_value, respectively. If no more
; compressed data is available, the decompressor jumps to the
; "end_of_message" subroutine:
INPUT-BYTES (4, position_value, end_of_message)
input-bytes（4、position_value、end_of_message）
; The position_value and length_value point to a byte string in the
; UDVM memory, which is copied into the circular buffer at the
; position specified by decompressed_pointer. This allows the string
; to be referenced by later characters in the compressed message:
COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
copy-literal（$ position_value、$ length_value、$ decompressed_pointer）
; The byte string is also outputted onto the end of the decompressed ; message:
;バイト文字列は、減圧の端に出力されます。メッセージ：
OUTPUT ($position_value, $length_value)
output（$ position_value、$ length_value）
; The decompressor jumps back to consider the next character in the ; compressed message:
;減圧器はジャンプして、次の文字を検討します。圧縮メッセージ：
JUMP (next_character)
ジャンプ（next_character）
:end_of_message
：end_of_message
; The decompressor saves the UDVM memory and halts:
;減圧器はUDVMメモリを保存して停止します。
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
end-message（requested_feedback_location、returned_parameters_location、state_length、64、decompress_sigcomp_message、6、0）
at (256)
で（256）
; Memory for the dictionary and the circular buffer are reserved by ; the following statements:
;辞書と円形バッファーのメモリは、次のように予約されています。次のステートメント：
:static_dictionary pad (256) :circular_buffer
：static_dictionaryパッド（256）：circular_buffer
The task of an LZ77 compressor is simply to discover a sequence of 4-byte compressed characters that the above bytecode will decompress to give the desired application message. As an example, a message compressed using the simplified LZ77 algorithm is given below:
LZ77コンプレッサーのタスクは、上記のバイトコードが減圧して目的のアプリケーションメッセージを提供する4バイトの圧縮文字のシーケンスを見つけるだけです。例として、単純化されたLZ77アルゴリズムを使用して圧縮されたメッセージを以下に示します。
0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001 0x0120 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016e 0x0001 0164 0001 0120 0001 016f 0001 0166 0001 0211 0005 0155 0001 0x016e 0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010a 0x0001
0x0154 0001 0168 0001 0165 0001 0120 0001 0152 0001 0165 0001 0173 0x0002 0161 0001 0175 0001 0172 0001 0161 0001 016E 0001 0174 0001 0x01200001020101010174017401017401740174017401740174 1 0003 0145 0001 016E 0x0001 0164 0001 0120 0001 016F 0001 0166 0001 0211 00050155 0001 0x016E 0001 0169 0001 0176 0001 0165 0001 0172 0002 0165 0001 010A 0x0001
The uncompressed message is "The Restaurant at the End of the Universe\n".
圧縮されていないメッセージは、「宇宙の終わりにあるレストラン\ n」です。
The bytecode for the LZ77 decompressor can be uploaded as part of the compressed message, as specified in Section 3.3. However, in order to improve the overall compression ratio, it is important to avoid uploading bytecode in every compressed message. For this reason, SigComp allows the UDVM to save an area of its memory as a state item between compressed messages. Once a state item has been created, it can be retrieved by sending the corresponding state identifier using the following SigComp message format:
セクション3.3で指定されているように、LZ77減圧装置のバイトコードは、圧縮メッセージの一部としてアップロードできます。ただし、全体的な圧縮比を改善するには、すべての圧縮メッセージにバイトコードをアップロードしないようにすることが重要です。このため、SigCompはUDVMが圧縮メッセージ間の状態アイテムとしてそのメモリの領域を保存することを許可します。状態項目が作成されたら、次のSigCompメッセージ形式を使用して対応する状態識別子を送信することで取得できます。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 1 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item : if T = 1
| |
+---+---+---+---+---+---+---+---+
| |
: partial state identifier :
| |
+---+---+---+---+---+---+---+---+
| |
: remaining SigComp message :
| |
+---+---+---+---+---+---+---+---+
The partial_state_identifier field must contain the first 6 bytes of the state identifier for the state item to be accessed (see [2] for details of how state identifiers are derived).
partial_state_identifierフィールドには、状態項目にアクセスするための状態識別子の最初の6バイトを含める必要があります（状態識別子の導出方法の詳細については、[2]を参照）。
Note that the partial_state_identifier field could be 9 or 12 bytes and that in these cases, bits 6 and 7 of the first byte of the message would be 10 or 11, respectively.
Partial_state_Identifierフィールドは9または12バイトであり、これらの場合、メッセージの最初のバイトのビット6と7はそれぞれ10または11になることに注意してください。
This section provides UDVM bytecode for the simple but effective LZSS compression algorithm [6].
このセクションでは、単純だが効果的なLZSS圧縮アルゴリズム[6]のUDVMバイトコードを提供します。
The principal improvement offered by LZSS over LZ77 is that each compressed character begins with a 1-bit indicator flag to specify whether the character is a literal or an offset/length pair. A literal value is simply a single uncompressed byte that is appended directly to the decompressed message.
LZ77よりもLZSSが提供する主な改善は、各圧縮文字が1ビットインジケーターフラグから始まり、文字がリテラル/オフセット/長さのペアかを指定することです。リテラル値は、単に非圧縮されていないバイトで、減圧メッセージに直接追加されます。
An offset/length pair contains a 12-bit offset value from 1 to 4096 inclusive, followed by a 4-bit length value from 3 to 18 inclusive. Taken together, these values specify one of the previously received text strings in the circular buffer, which is then appended to the end of the decompressed message.
オフセット/長さのペアには、1〜4096の12ビットオフセット値が含まれ、その後に3〜18の4ビットの長さ値が含まれます。まとめると、これらの値は、以前に受け取ったテキスト文字列の1つを円形バッファーに指定し、その後、減圧メッセージの最後に追加されます。
Assembly for an LZSS decompressor is given below:
LZSS分解器のアセンブリを以下に示します。
at (32) readonly (0)
at（32）readonly（0）
:index pad (2)
:length_value pad (2)
:old_pointer pad (2)
at (42)
で（42）
set (requested_feedback_location, 0)
set（request_feedback_location、0）
at (64)
で（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
set（returned_parameters_location、0）
align (64) readonly (1)
align（64）readonly（1）
:initialize_memory
：intialize_memory
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
set（udvm_memory_size、8192）set（state_length、（udvm_memory_size -64））
MULTILOAD (64, 4, circular_buffer, udvm_memory_size, 0, circular_buffer)
MultiLoad（64、4、Circular_Buffer、udvm_memory_size、0、circular_buffer）
:decompress_sigcomp_message
：decompress_sigcomp_message
:next_character
：next_character
INPUT-HUFFMAN (index, end_of_message, 2, 9, 0, 255, 16384, 4, 4096, 8191, 1) COMPARE ($index, 8192, length, end_of_message, literal)
input-huffman（index、end_of_message、2、9、0、255、16384、4、4096、8191、1）比較（$ index、8192、length、end_of_message、literal）
:literal
：リテラル
set (index_lsb, (index + 1)) OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (next_character)
set（index_lsb、（index 1））output（index_lsb、1）copy-literal（index_lsb、1、$ decompressed_pointer）ジャンプ（next_character）
:length
：長さ
INPUT-BITS (4, length_value, !) ADD ($length_value, 3) LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($index, $length_value, $decompressed_pointer) OUTPUT ($old_pointer, $length_value) JUMP (next_character)
input-bits（4、length_value、！）add（$ length_value、3）load（old_pointer、$ decompressed_pointer）コピーオフセット（$ index、$ length_value、$ decompressiond_pointer）output（$ old_pointer、$ length_value）ジャンプ（next_character）（next_character）
:end_of_message
：end_of_message
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
end-message（requested_feedback_location、returned_parameters_location、state_length、64、decompress_sigcomp_message、6、0）
readonly (0) :circular_buffer
readonly（0）：circular_buffer
An example of a message compressed using the LZSS algorithm is given below:
LZSSアルゴリズムを使用して圧縮されたメッセージの例を以下に示します。
0x279a 0406 e378 b200 6074 1018 4ce6 1349 b842
0x279a 0406 E378 B200 6074 1018 4CE6 1349 B842
The uncompressed message is "Oh no, not again!".
圧縮されていないメッセージは「ああ、もう一度ではない！」です。
This section provides UDVM bytecode for the well-known LZW compression algorithm LZW [7]. This algorithm is used in a number of standards including the GIF image format.
このセクションでは、よく知られているLZW圧縮アルゴリズムLZWのUDVMバイトコードを提供します[7]。このアルゴリズムは、GIF画像形式を含む多くの標準で使用されます。
LZW compression operates in a similar manner to LZ77 in that it maintains a circular buffer of previously received decompressed data, and each compressed character references exactly one byte string from the circular buffer. However, LZW also maintains a "codebook" containing 1024 position/length pairs that point to byte strings that LZW believes are most likely to occur in the uncompressed data.
LZW圧縮は、LZ77と同様の方法で動作します。これは、以前に受信された減圧データの円形バッファーを維持し、各圧縮文字は円形バッファーからちょうど1つのバイト文字列を参照しています。ただし、LZWは、LZWが非圧縮データで発生する可能性が最も高いバイト文字列を指す1024の位置/長さのペアを含む「コードブック」も維持しています。
The byte strings stored in the LZW codebook can be referenced by sending a single 10-bit value from 0 to 1023 inclusive. The UDVM extracts the corresponding text string from the codebook and appends it to the end of the decompressed message. It then creates a new codebook entry containing the current text string and the next character to occur in the decompressed message.
LZWコードブックに保存されているバイト文字列は、0〜1023インクルーシブに単一の10ビット値を送信することで参照できます。UDVMは、コードブックから対応するテキスト文字列を抽出し、減圧メッセージの最後に追加します。次に、現在のテキスト文字列と、減圧メッセージで発生する次の文字を含む新しいコードブックエントリを作成します。
Assembly for an LZW decompressor is given below:
LZW分解器のアセンブリを以下に示します。
at (32)
で（32）
:length_value pad (2)
:position_value pad (2)
:index pad (2)
at (42)
で（42）
set (requested_feedback_location, 0)
set（request_feedback_location、0）
at (64)
で（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:codebook_next pad (2)
:current_length pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
set（returned_parameters_location、0）
align (64)
align（64）
:initialize_memory
：intialize_memory
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
set（udvm_memory_size、8192）set（state_length、（udvm_memory_size -64））
MULTILOAD (64, 6, circular_buffer, udvm_memory_size, 0, codebook, 1, static_dictionary)
MultiLoad（64、6、Circular_Buffer、udvm_memory_size、0、codebook、1、static_dictionary）
:initialize_codebook
：intialize_codebook
; The following instructions are used to initialize the first 256 ; entries in the LZW codebook with single ASCII characters:
;次の指示は、最初の256を初期化するために使用されます。単一のASCII文字を備えたLZWコードブックのエントリ：
set (index_lsb, (index + 1)) set (current_length_lsb, (current_length + 1))
set（index_lsb、（index 1））set（current_length_lsb、（current_length 1））
COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) ADD ($index, 1) COMPARE ($index, 256, initialize_codebook, next_character, 0)
copy-literal（current_length_lsb、3、$ codebook_next）copy-literal（index_lsb、1、$ decompressed_pointer）add（$ index、1）compare（$ index、256、initialize_codebook、next_character、0）
:decompress_sigcomp_message
：decompress_sigcomp_message
:next_character
：next_character
; The following INPUT-BITS instruction extracts 10 bits from the ; compressed message:
;次の入力ビット命令は、から10ビットを抽出します。圧縮メッセージ：
INPUT-BITS (10, index, end_of_message)
入力ビット（10、index、end_of_message）
; The following instructions interpret the received bits as an index
; into the LZW codebook and extract the corresponding
; position/length pair:
set (length_value_lsb, (length_value + 1))
set（length_value_lsb、（length_value 1））
MULTIPLY ($index, 3) ADD ($index, codebook) COPY ($index, 3, length_value_lsb)
乗算（$ index、3）add（$ index、codebook）copy（$ index、3、length_value_lsb）
; The following instructions append the selected text string to the
; circular buffer and create a new codebook entry pointing to this
; text string:
LOAD (current_length, 1) ADD ($current_length, $length_value) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
load（current_length、1）add（$ current_length、$ length_value）copy-literal（current_length_lsb、3、$ codebook_next）copy-literal（$ position_value、$ length_value、$ decompressed_pointer）
; The following instruction outputs the text string specified by the ; position/length pair:
;次の命令は、次のように指定されたテキスト文字列を出力します。位置/長さのペア：
OUTPUT ($position_value, $length_value) JUMP (next_character)
output（$ position_value、$ length_value）Jump（next_character）
:end_of_message
：end_of_message
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
end-message（requested_feedback_location、returned_parameters_location、state_length、64、decompress_sigcomp_message、6、0）
:static_dictionary pad (256) :circular_buffer
：static_dictionaryパッド（256）：circular_buffer
at (4492)
で（4492）
:codebook An example of a message compressed using the LZW algorithm is given below:
：コードブックLZWアルゴリズムを使用して圧縮されたメッセージの例を以下に示します。
0x14c6 f080 6c1b c6e1 9c20 1846 e190 201d 0684 206b 1cc2 0198 6f1c 0x9071 b06c 42c6 8195 111a 4731 a021 02bf f0
0x14C6 F080 6C1B C6E1 9C20 1846 E190 201D 0684 206B 1CC2 0198 6F1C 0X9071 B06C 42C6 8195 111A 4731 A021 02BF F00
The uncompressed message is "So long and thanks for all the fish!\n".
圧縮されていないメッセージは「とても長く、すべての魚に感謝します！\ n」です。
This section provides UDVM bytecode for the DEFLATE compression algorithm. DEFLATE is the algorithm used in the well-known "gzip" file format.
このセクションでは、デフレート圧縮アルゴリズムのUDVMバイトコードを提供します。DEFLATEは、よく知られている「GZIP」ファイル形式で使用されるアルゴリズムです。
The following bytecode will decompress the DEFLATE compressed data format [8] with the following modifications:
次のバイトコードは、次の変更を使用して、デフレート圧縮データ形式[8]を減圧します。
1. The DEFLATE compressed data format separates blocks of compressed data by transmitting 7 consecutive zero bits. Each SigComp message is assumed to contain a separate block of compressed data, so the end-of-block bits are implicit and do not need to be transmitted at the end of a SigComp message.
1. DEFLATE圧縮データ形式は、7つの連続したゼロビットを送信することにより、圧縮データのブロックを分離します。各Sigcompメッセージは圧縮データの個別のブロックが含まれていると想定されるため、ブロックの終わりのビットは暗黙的であり、SigCompメッセージの最後に送信する必要はありません。
2. This bytecode supports only DEFLATE block type 01 (data compressed with fixed Huffman codes).
2. このバイトコードは、ブロックタイプ01（固定されたハフマンコードで圧縮されたデータ）のみをサポートします。
Assembly for the DEFLATE decompressor is given below:
DEFLATE減圧器のアセンブリを以下に示します。
at (32) readonly (0)
at（32）readonly（0）
:index pad (2)
:extra_length_bits pad (2)
:length_value pad (2)
:extra_distance_bits pad (2)
:distance_value pad (2)
at (42)
で（42）
set (requested_feedback_location, 0)
set（request_feedback_location、0）
at (64)
で（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
:length_table pad (116)
:distance_table pad (120)
set (returned_parameters_location, 0)
set（returned_parameters_location、0）
align (64)
align（64）
readonly (1) :initialize_memory
Readonly（1）：initialize_memory
set (udvm_memory_size, 8192)
set (state_length, (udvm_memory_size - 64))
set (length_table_start, (((length_table - 4) + 65536) / 4))
set (length_table_mid, (length_table_start + 24))
set (distance_table_start, (distance_table / 4))
MULTILOAD (64, 122, circular_buffer, udvm_memory_size, 5, circular_buffer,
MultiLoad（64、122、Circular_Buffer、udvm_memory_size、5、circular_buffer、
0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0, 10, 1, 11, 1, 13, 1, 15, 1, 17, 2, 19, 2, 23, 2, 27, 2, 31, 3, 35, 3, 43, 3, 51, 3, 59, 4, 67, 4, 83, 4, 99, 4, 115, 5, 131, 5, 163, 5, 195, 5, 227, 0, 258,
0、3、0、4、0、5、0、6、7、0、8、0、9、0、10、1、11、13、1、15、1、17、2、2、19、2、23、2、27、2、31、3、35、3、43、3、51、3、59、4、67、4、83、4、99、4、115、5、131、5、163、5、195、5、227、0、258、
0, 1, 0, 2, 0, 3, 0, 4, 1, 5, 1, 7, 2, 9, 2, 13, 3, 17, 3, 25, 4, 33, 4, 49, 5, 65, 5, 97, 6, 129, 6, 193, 7, 257, 7, 385, 8, 513, 8, 769, 9, 1025, 9, 1537, 10, 2049, 10, 3073, 11, 4097, 11, 6145, 12, 8193, 12, 12289, 13, 16385, 13, 24577)
0、1、0、2、0、3、0、4、5、1、7、2、9、2、2、3、3、17、3、25、4、33、4、49、5、5、65、5、97、6、129、6、193、7、257、7、385、8、513、8、769、9、1025、9、1537、10、2049、10、3073、11、4097、11、6145、12、8193、12、12289、13、16385、13、24577）
:decompress_sigcomp_message
：decompress_sigcomp_message
INPUT-BITS (3, extra_length_bits, !)
入力ビット（3、extra_length_bits、！）
:next_character INPUT-HUFFMAN (index, end_of_message, 4, 7, 0, 23, length_table_start, 1, 48, 191, 0, 0, 192, 199, length_table_mid, 1, 400, 511, 144) COMPARE ($index, length_table_start, literal, end_of_message, length_distance)
：next_character input-huffman（index、end_of_message、4、7、0、23、length_table_start、1、48、191、0、0、192、199、length_table_mid、1、400、511、144）比較（$ index、length_table_start、リテラル、end_of_message、length_distance）
:literal
：リテラル
set (index_lsb, (index + 1))
set（index_lsb、（index 1））
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (next_character)
output（index_lsb、1）copy-literal（index_lsb、1、$ decompressed_pointer）Jump（next_character）
:length_distance
：length_distance
; this is the length part
;これが長さの部分です
MULTIPLY ($index, 4) COPY ($index, 4, extra_length_bits) INPUT-BITS ($extra_length_bits, extra_length_bits, !) ADD ($length_value, $extra_length_bits)
Multiply（$ index、4）copy（$ index、4、extra_length_bits）input-bits（$ extra_length_bits、extra_length_bits、！）add（$ length_value、$ extra_length_bits）
; this is the distance part
;これが距離部分です
INPUT-HUFFMAN (index, !, 1, 5, 0, 31, distance_table_start) MULTIPLY ($index, 4) COPY ($index, 4, extra_distance_bits)
input-huffman（index、！、1、5、0、31、distance_table_start）倍数（$ index、4）copy（$ index、4、extra_distance_bits）
INPUT-BITS ($extra_distance_bits, extra_distance_bits, !) ADD ($distance_value, $extra_distance_bits) LOAD (index, $decompressed_pointer) COPY-OFFSET ($distance_value, $length_value, $decompressed_pointer) OUTPUT ($index, $length_value) JUMP (next_character)
input-bits（$ extra_distance_bits、extra_distance_bits、！）add（$ distance_value、$ extra_distance_bits）load（index、$ decompressiond_pointer）copy-offset（$ distance_value、$ length_value、$ decompressiond_pointer）output（$ length_value）jums（next_character））
:end_of_message
：end_of_message
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
end-message（requested_feedback_location、returned_parameters_location、state_length、64、decompress_sigcomp_message、6、0）
readonly (0) :circular_buffer An example of a message compressed using the DEFLATE algorithm is given below:
readonly（0）：circular_buffer deflateアルゴリズムを使用して圧縮されたメッセージの例を以下に示します。
0xf3c9 4c4b d551 28c9 4855 08cd cb2c 4b2d 2a4e 5548 cc4b 5170 0532 0x2b4b 3232 f3d2 b900
0xf3c9 4c4b D551 28C9 4855 08CD CB2C 4B2D 2A4E 5548 CC4B 5170 0532 0x2B4B 3232 F3D2 B900
The uncompressed message is "Life, the Universe and Everything\n".
圧縮されていないメッセージは、「人生、宇宙、すべて\ n」です。
This section provides UDVM bytecode for the LZJH compression algorithm. LZJH is the algorithm adopted by the International Telecommunication Union (ITU-T) Recommendation V.44 [9].
このセクションでは、LZJH圧縮アルゴリズムのUDVMバイトコードを提供します。LZJHは、国際電気通信連合（ITU-T）推奨v.44 [9]で採用されたアルゴリズムです。
Assembly for the LZJH decompressor is given below:
LZJH分解器のアセンブリを以下に示します。
at (32) readonly (0)
at（32）readonly（0）
; The following 2-byte variables are stored in the scratch-pad memory
; area because they do not need to be saved after decompressing a
; SigComp message:
:length_value pad (2)
:position_value pad (2)
:index pad (2)
:extra_extension_bits pad (2)
:codebook_old pad (2)
at (42)
で（42）
set (requested_feedback_location, 0)
set（request_feedback_location、0）
at (64)
で（64）
; UDVM_registers
;udvm_registers
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
：input_bit_orderパッド（2）
; The following 2-byte variables are saved as state after ; decompressing a SigComp message:
;次の2バイト変数は、状態として保存されます。Sigcompメッセージの減圧：
:current_length pad (2)
:decompressed_pointer pad (2)
:ordinal_length pad (2)
:codeword_length pad (2)
:codebook_next pad (2)
set (returned_parameters_location, 0)
set（returned_parameters_location、0）
align (64) readonly (1)
align（64）readonly（1）
:initialize_memory
：intialize_memory
; The following constants can be adjusted to configure the LZJH
; decompressor. The current settings are as recommended in the V.44
; specification (given that a total of 8K UDVM memory is available):
set (udvm_memory_size, 8192) ; sets the total memory for LZJH set (max_extension_length, 8) ; sets the maximum string extension set (min_ordinal_length, 7) ; sets the minimum ordinal length set (min_codeword_length, 6) ; sets the minimum codeword length
set（udvm_memory_size、8192）;LZJHセットの合計メモリを設定します（max_extension_length、8）;最大文字列拡張セット（min_ordinal_length、7）を設定します。最小順序長セット（min_codeword_length、6）を設定します。最小コードワードの長さを設定します
set (codebook_start, 4492) set (first_codeword, (codebook_start - 12)) set (state_length, (udvm_memory_size - 64))
set（codebook_start、4492）set（first_codeword、（codebook_start -12））set（state_length、（udvm_memory_size -64））
MULTILOAD (64, 8, circular_buffer, udvm_memory_size, 7, 0, circular_buffer, min_ordinal_length, min_codeword_length, codebook_start)
MultiLoad（64、8、Circular_Buffer、udvm_memory_size、7、0、circular_buffer、min_ordinal_length、min_codeword_length、codebook_start）
:decompress_sigcomp_message
：decompress_sigcomp_message
:standard_prefix
：Standard_Prefix
; The following code decompresses the standard 1-bit LZJH prefix
; that specifies whether the next character is an ordinal or a
; codeword/control value:
INPUT-BITS (1, index, end_of_message) COMPARE ($index, 1, ordinal, codeword_control, codeword_control)
input-bits（1、index、end_of_message）比較（$ index、1、ordinal、codeword_control、codeword_control）
:prefix_after_codeword
：prefix_after_codeword
; The following code decompresses the special LZJH prefix that only
; occurs after a codeword. It specifies whether the next character
; is an ordinal, a codeword/control value, or a string extension:
INPUT-HUFFMAN (index, end_of_message, 2, 1, 1, 1, 2, 1, 0, 1, 0) COMPARE ($index, 1, ordinal, string_extension, codeword_control)
input-huffman（index、end_of_message、2、1、1、1、2、1、0、1、0）比較（$ index、1、ordinal、string_extension、codeword_control）
:ordinal
：序数
; The following code decompresses an ordinal character and creates
; a new codebook entry consisting of the ordinal character and the
; next character to be decompressed:
set (index_lsb, (index + 1)) set (current_length_lsb, (current_length + 1))
set（index_lsb、（index 1））set（current_length_lsb、（current_length 1））
INPUT-BITS ($ordinal_length, index, !) OUTPUT (index_lsb, 1) LOAD (current_length, 2) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (standard_prefix)
input-bits（$ ordinal_length、index、！）output（index_lsb、1）load（current_length、2）copy-literal（current_length_lsb、3、 $ codebook_next）copy-lsb（index_lsb、1、$ decompressiond_pointer）ジャンプ（Standard_Prefix）
:codeword_control
：codeword_control
; The following code decompresses a codeword/control value:
;次のコードは、コードワード/コントロール値を減圧します。
INPUT-BITS ($codeword_length, index, !) COMPARE ($index, 3, control_code, initialize_memory, codeword)
input-bits（$ codeword_length、index、！）compare（$ index、3、control_code、initialize_memory、codeword）
:codeword
：Codeword
; The following code interprets a codeword as an index into the LZJH
; codebook. It extracts the position/length pair from the specified
; codebook entry; the position/length pair points to a byte string
; in the circular buffer, which is then copied to the end of the
; decompressed message. The code also creates a new codebook entry
; consisting of the byte string plus the next character to be
; decompressed:
set (length_value_lsb, (length_value + 1))
set（length_value_lsb、（length_value 1））
MULTIPLY ($index, 3) ADD ($index, first_codeword) COPY ($index, 3, length_value_lsb) LOAD (current_length, 1) ADD ($current_length, $length_value) LOAD (codebook_old, $codebook_next) COPY-LITERAL (current_length_lsb, 3, $codebook_next) COPY-LITERAL ($position_value, $length_value, $decompressed_pointer) OUTPUT ($position_value, $length_value) JUMP (prefix_after_codeword)
乗算（$ index、3）add（$ index、first_codeword）copy（$ index、3、length_value_lsb）load（current_length、1）add（$ current_length、$ length_value）load（codebook_old、$ codebook_next）copy-literal（current_length_lsb、3、$ codebook_next）copy-literal（$ position_value、$ length_value、$ decompressed_pointer）output（$ position_value、$ length_value）Jump（prefix_after_codeword）
:string_extension
：string_extension
; The following code decompresses a Huffman-encoded string extension:
;次のコードは、ハフマンエンコードされた文字列拡張機能を減圧します。
INPUT-HUFFMAN (index, !, 4, 1, 1, 1, 1, 2, 1, 3, 2, 1, 1, 1, 13, 3, 0, 7, 5) COMPARE ($index, 13, continue, extra_bits, extra_bits)
input-huffman（index、！、4、1、1、1、1、2、1、3、2、1、1、1、13、3、0、7、5）比較（$ index、13、継続、extra_bits、extra_bits）
:extra_bits
：extra_bits
INPUT-BITS (max_extension_length, extra_extension_bits, !) ADD ($index, $extra_extension_bits)
input-bits（max_extension_length、extra_extension_bits、！）add（$ index、$ extra_extension_bits）
:continue
：続く
; The following code extends the most recently created codebook entry ; by the number of bits specified in the string extension:
;次のコードは、最近作成されたコードブックエントリを拡張します。文字列延長で指定されたビットの数によって：
COPY-LITERAL ($position_value, $length_value, $position_value) COPY-LITERAL ($position_value, $index, $decompressed_pointer) OUTPUT ($position_value, $index) ADD ($index, $length_value) COPY (index_lsb, 1, $codebook_old) JUMP (standard_prefix)
copy-literal（$ position_value、$ length_value、$ position_value）copy-literal（$ position_value、$ index、$ decompressiond_pointer）output（$ position_value、$ index）add（$ index、$ length_value）copy（index_lsb、1、$ codebook_old）ジャンプ（Standard_Prefix）
:control_code
：control_code
; The code can handle all of the control characters in V.44 except
; for ETM (Enter Transparent Mode), which is not required for
; message-based protocols such as SigComp.
COMPARE ($index, 1, !, flush, stepup)
比較（$ index、1、！、フラッシュ、ステップアップ）
:flush
：流す
; The FLUSH control character jumps to the beginning of the next ; complete byte in the compressed message:
;フラッシュコントロール文字は次の始まりにジャンプします。圧縮メッセージの完全なバイト：
INPUT-BYTES (0, 0, 0) JUMP (standard_prefix)
input-bytes（0、0、0）ジャンプ（Standard_Prefix）
:stepup
：ステップアップ
; The STEPUP control character increases the number of bits used to ; encode an ordinal value or a codeword:
;ステップアップ制御文字は、使用したビット数を増やします。順序の値またはコードワードをエンコードします。
INPUT-BITS (1, index, !) COMPARE ($index, 1, stepup_ordinal, stepup_codeword, 0)
入力ビット（1、インデックス、！）比較（$ index、1、stepup_ordinal、stepup_codeword、0）
:stepup_ordinal
：stepup_ordinal
ADD ($ordinal_length, 1) JUMP (ordinal)
add（$ ordinal_length、1）Jump（ordinal）
:stepup_codeword
：stepup_codeword
ADD ($codeword_length, 1) JUMP (codeword_control)
add（$ codeword_length、1）Jump（codeword_control）
:end_of_message
：end_of_message
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
end-message（requested_feedback_location、returned_parameters_location、state_length、64、decompress_sigcomp_message、6、0）
readonly (0) :circular_buffer
readonly（0）：circular_buffer
An example of a message compressed using the LZJH algorithm is given below:
LZJHアルゴリズムを使用して圧縮されたメッセージの例を以下に示します。
0x5c09 e6e0 cadc c8d2 dcce 40c2 40f2 cac2 e440 c825 c840 ccde 29e8 0xc2f0 40e0 eae4 e0de e6ca e65c 1403
0x5C09 E6E0 CADC CADC C8D2 DCCE 40C2 40F2 CAC2 E440 C825 C840 CCDE 29E8 0XC2F0 40E0 EAE4 E0DE E6CA E65C 1403
The uncompressed message is "...spending a year dead for tax purposes.\n".
圧縮されていないメッセージは、「...税目的で1年を費やす」です。\ n」。
Alternative algorithms can also be used with SigComp. This section shows a modified version of the DEFLATE [8] algorithm. The two-stage encoding of DEFLATE is replaced by a single step with a discrete Huffman code for each symbol. The literal/length symbol probabilities are dependent upon whether the previous symbol was a literal or a match. Bit handling is also simpler, in that all bits are input using the INPUT-HUFFMAN instruction and the value of the H bit does not change so all bits are input, read, and interpreted in the same order.
代替アルゴリズムは、SigCompでも使用できます。このセクションは、DEFLATE [8]アルゴリズムの変更されたバージョンを示しています。2段階のデフレートのエンコードは、各シンボルの個別のハフマンコードを備えた単一のステップに置き換えられます。リテラル/長さのシンボル確率は、前のシンボルがリテラルなものなのか一致しているのかに依存します。ビット処理も簡単です。すべてのビットは入力ハフマン命令を使用して入力され、Hビットの値は変更されないため、すべてのビットが入力、読み取り、同じ順序で解釈されます。
Assembly for the algorithm is given below. String matching rules are the same as for the other LZ-based algorithms, with the alternative encoding of the literals and length/distance pairs.
アルゴリズムのアセンブリを以下に示します。文字列マッチングルールは、他のLZベースのアルゴリズムと同じであり、リテラルと長さ/距離ペアの代替エンコードがあります。
at (32) readonly (0)
at（32）readonly（0）
:index pad (2)
:distance_value pad (2)
:old_pointer pad (2)
at (42)
で（42）
set (requested_feedback_location, 0)
set（request_feedback_location、0）
at (64)
で（64）
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:decompressed_pointer pad (2)
set (returned_parameters_location, 0)
set（returned_parameters_location、0）
at (128) readonly (1)
at（128）readonly（1）
:initialize_memory
：intialize_memory
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
set（udvm_memory_size、8192）set（state_length、（udvm_memory_size -64））
MULTILOAD (64, 4, circular_buffer, udvm_memory_size, 0, circular_buffer)
MultiLoad（64、4、Circular_Buffer、udvm_memory_size、0、circular_buffer）
:decompress_sigcomp_message
：decompress_sigcomp_message
:character_after_literal
：character_after_literal
INPUT-HUFFMAN (index, end_of_message, 16, 5, 0, 11, 46, 0, 12, 12, 256, 1, 26, 32, 257, 1, 66, 68, 32, 0, 69, 94, 97, 0, 95, 102, 264, 0, 103, 103, 511, 2, 416, 426, 35, 0, 427, 465, 58, 0, 466, 481, 272, 1, 964, 995, 288, 3, 7968, 7988, 123, 0, 7989, 8115, 384, 1, 16232, 16263, 0, 0, 16264, 16327, 320, 1, 32656, 32767, 144)
input-huffman（index、end_of_message、16、5、0、11、46、0、12、12、256、1、26、32、257、1、66、68、32、0、69、94、97、0、95、102、264、0、103、103、511、2、416、426、35、0、427、465、58、0、466、481、272、1、964、995、288、3、7968、7988、123、0、7989、8115、384、1、16232、16263、0、0、16264、16327、320、1、32656、32767、144）
COMPARE ($index, 256, literal, distance, distance)
比較（$ index、256、リテラル、距離、距離）
:character_after_match
：character_after_match
INPUT-HUFFMAN (index, end_of_message, 16, 4, 0, 0, 511, 1, 2, 9, 256, 1, 20, 22, 32, 0, 23, 30, 264, 1, 62, 73, 46, 0, 74, 89, 272, 2, 360, 385, 97, 0, 386, 417, 288, 1, 836, 874, 58, 0, 875, 938, 320, 1, 1878, 1888, 35, 0, 1889, 2015, 384, 1, 4032, 4052, 123, 1, 8106, 8137, 0, 1, 16276, 16379, 144, 1, 32760, 32767, 248)
input-huffman（index、end_of_message、16、4、0、511、1、2、9、256、1、20、22、32、0、23、30、264、1、62、73、46、0、74、89、272、2、360、385、97、0、386、417、288、1、836、874、58、0、875、938、320、1、1878、1888、35、0、1889、2015、384、1、4032、4052、123、1、8106、8137、0、1、16276、16379、144、1、32760、32767、248）
COMPARE ($index, 256, literal, distance, distance)
比較（$ index、256、リテラル、距離、距離）
:literal
：リテラル
set (index_lsb, (index + 1))
set（index_lsb、（index 1））
OUTPUT (index_lsb, 1) COPY-LITERAL (index_lsb, 1, $decompressed_pointer) JUMP (character_after_literal)
output（index_lsb、1）copy-literal（index_lsb、1、$ decompressed_pointer）Jump（character_after_literal）
:distance
：距離
SUBTRACT ($index, 253) INPUT-HUFFMAN (distance_value, !, 9, 9, 0, 7, 9, 0, 8, 63, 129, 1, 128, 135, 1, 0, 136, 247, 17, 0, 248, 319, 185, 1, 640, 1407, 257, 2, 5632, 6655, 1025, 1, 13312, 15359, 2049, 2, 61440, 65535, 4097)
subtract（$ index、253）input-huffman（distance_value、！、9、9、0、7、9、9、0、8、63、129、1、128、135、1、0、136、247、17、0、248、319、185、1、640、1407、257、2、5632、6655、1025、1、13312、15359、2049、2、61440、65535、4097）
LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($distance_value, $index, $decompressed_pointer) OUTPUT ($old_pointer, $index) JUMP (character_after_match)
load（old_pointer、$ decompressiond_pointer）copy-offset（$ distance_value、$ index、$ decompressed_pointer）output（$ old_pointer、$ index）jump（character_after_match）
:end_of_message
：end_of_message
END-MESSAGE (requested_feedback_location, returned_parameters_location, state_length, 64, decompress_sigcomp_message, 6, 0)
end-message（requested_feedback_location、returned_parameters_location、state_length、64、decompress_sigcomp_message、6、0）
readonly (0) :circular_buffer
readonly（0）：circular_buffer
An example of a message compressed using the modified DEFLATE algorithm is given below:
変更されたデフレートアルゴリズムを使用して圧縮されたメッセージの例を以下に示します。
0xd956 b132 cd68 5424 c5a9 6215 8a70 a64d af0a 5499 3621 509b 3e4c 0x28b4 a145 b362 653a d0a6 498b 5a6d 2970 ac4c 930a a4ca 74a4 c268 0x0c
0xD956 B132 CD68 5424 C5A9 6215 8A70 A64D AF0A 5499 3621 509B 3E4C 0x28B4 A145 B362 653A D0A6 498B 5A6D 2970 AC4C
The uncompressed message is "Arthur leapt to his feet like an author hearing the phone ring".
圧縮されていないメッセージは、「アーサーが電話の指輪を聞いている著者のように彼の足に飛び込んだ」です。
This section covers the additional mechanisms that can be employed by SigComp to improve the overall compression ratio, including the use of acknowledgements, dictionaries, and sharing state between two directions of a compressed message flow.
このセクションでは、SigCompが使用して、謝辞、辞書の使用、圧縮メッセージフローの2つの方向間の状態を共有するなど、全体的な圧縮比を改善できる追加のメカニズムをカバーしています。
An example of assembly code is provided for these mechanisms. Depending on the mechanism and basic algorithm in use, the assembly code for either the mechanism or the basic algorithm may require modification (e.g., if the algorithm uses 'no more input' to jump to end_of_message, following end_of_message with an input instruction for CRC will not work). In any case, these are examples and there may be alternative ways to make use of the mechanisms.
これらのメカニズムについては、アセンブリコードの例が提供されています。使用中のメカニズムと基本的なアルゴリズムに応じて、メカニズムまたは基本アルゴリズムのアセンブリコードが変更が必要になる場合があります（たとえば、アルゴリズムが「もう入力なし」を使用してEND_OF_MESSAGEにジャンプします。うまくいかない）。いずれにせよ、これらは例であり、メカニズムを利用する代替方法がある場合があります。
When each of the compression algorithms described in Section 4 has successfully decompressed the current SigComp message, the contents of the UDVM memory are saved as a SigComp state item. Subsequent messages can access this state item by uploading the correct state identifier to the receiving endpoint, which avoids the need to upload the bytecode for the compression algorithm on a per-message basis. However, before a state item can be accessed, the compressor must first ensure that it is available at the receiving endpoint.
セクション4で説明されている各圧縮アルゴリズムが現在のSIGCOMPメッセージを正常に減圧した場合、UDVMメモリの内容はSigComp状態のアイテムとして保存されます。後続のメッセージは、正しい状態識別子を受信エンドポイントにアップロードすることにより、この状態項目にアクセスできます。これにより、圧縮アルゴリズムのバイトコードを1人あたりベースでアップロードする必要がなくなります。ただし、状態アイテムにアクセスする前に、コンプレッサーは最初に受信エンドポイントで利用可能であることを確認する必要があります。
For each SigComp compartment, the receiving endpoint maintains a list of currently available states (where the total amount of state saved does not exceed the state_memory_size for the compartment). The SigComp compressor should maintain a similar list containing the states that it has instructed the receiving endpoint to save.
各SIGCOMPコンパートメントについて、受信エンドポイントは現在利用可能な状態のリストを維持しています（節約された状態の合計量は、コンパートメントのState_memory_sizeを超えません）。SigCompコンプレッサーは、受信エンドポイントを保存するように指示した状態を含む同様のリストを維持する必要があります。
As well as tracking the list of state items that it has saved at the remote endpoint, the compressor also maintains a flag for each state item indicating whether or not the state can safely be accessed. State items should not be accessed until they have been acknowledged (e.g., by using the SigComp feedback mechanism as per Section 5.1).
リモートエンドポイントで保存した状態アイテムのリストを追跡するだけでなく、コンプレッサーは、状態に安全にアクセスできるかどうかを示す各状態アイテムのフラグも維持します。状態項目は、認められるまでアクセスしないでください（たとえば、セクション5.1に従ってSigCompフィードバックメカニズムを使用して）。
State items are deleted from the list when adding a new piece of state when the total state_memory_size for the compartment is full. The state to be deleted is determined according to age and retention priority as discussed in SigComp [2]. The SigComp compressor should not attempt to access any state items that have been deleted in this manner, as they may no longer be available at the receiving endpoint.
コンパートメントの合計State_memory_sizeがいっぱいになったときに、新しい状態を追加するときに、状態アイテムがリストから削除されます。削除される状態は、Sigcomp [2]で説明されているように、年齢と保持の優先順位に従って決定されます。SigCompコンプレッサーは、受信エンドポイントで利用できなくなる可能性があるため、この方法で削除された状態アイテムにアクセスしようとしないでください。
SigComp [2] defines a feedback mechanism to allow the compressor to request feedback from the decompressor, to give the compressor indication that a message has been received and correctly decompressed and that state storage has been attempted. (Note: This mechanism cannot convey the success or failure of individual state creation requests.) In order to invoke the feedback mechanism, the following fields must be reserved in the UDVM memory:
Sigcomp [2]は、コンプレッサーが減圧器からフィードバックを要求できるようにするためのフィードバックメカニズムを定義し、コンプレッサーにメッセージが受信され、正しく減圧され、状態ストレージが試行されたことを示します。（注：このメカニズムは、個々の州の作成要求の成功または失敗を伝えることはできません。）フィードバックメカニズムを呼び出すために、次のフィールドをUDVMメモリに予約する必要があります。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| 1 | requested_feedback_length | if Q = 1
+---+---+---+---+---+---+---+---+
| |
: requested_feedback_field : if Q = 1
| |
+---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Section 4 by
replacing the line "set (requested_feedback_location, 0)" with the
following assembly:
:requested_feedback_location pad (1)
:requested_feedback_length pad (1)
:requested_feedback_field pad (12)
:hash_start pad (8)
When a SigComp message is successfully decompressed and saved as state, the following bytecode instructs the receiving endpoint to return the first 6 bytes of the corresponding state identifier. The bytecode can be added to any of the compression algorithms of Section 4 immediately following the ":end_of_message" label:
SigCompメッセージが正常に解凍され、状態として保存された場合、次のバイトコードは、対応する状態識別子の最初の6バイトを返すように受信エンドポイントに指示します。バイトコードは、「：end_of_message」ラベルの直後のセクション4の圧縮アルゴリズムのいずれかに追加できます。
:end_of_message
：end_of_message
set (hash_length, (state_length + 8))
set（hash_length、（state_length 8））
LOAD (requested_feedback_location, 1158) MULTILOAD (hash_start, 4, state_length, 64, decompress_sigcomp_message, 6) SHA-1 (hash_start, hash_length, requested_feedback_field)
load（request_feedback_location、1158）multiload（hash_start、4、state_length、64、decompress_sigcomp_message、6）sha-1（hash_start、hash_length、requested_feedback_field）
The receiving endpoint then returns the state identifier in the "returned feedback field" of the next SigComp message to be transmitted in the reverse direction.
受信エンドポイントは、次のSigCompメッセージの「返されたフィードバックフィールド」の状態識別子を返し、逆方向に送信します。
When the state identifier is returned, the compressor can set the availability flag for the corresponding state to 1.
状態識別子が返されると、コンプレッサーは対応する状態の可用性フラグを1に設定できます。
Certain protocols that can be compressed using SigComp offer a fixed, mandatory state item known as a static dictionary. This dictionary contains a number of text strings that commonly occur in messages generated by the protocol in question. The overall compression ratio can often be improved by accessing the text phrases from this static dictionary rather than by uploading them as part of the compressed message.
SigCompを使用して圧縮できる特定のプロトコルは、静的辞書として知られる固定された必須の状態アイテムを提供します。この辞書には、問題のプロトコルによって生成されたメッセージで一般的に発生する多くのテキスト文字列が含まれています。全体的な圧縮比は、圧縮メッセージの一部としてアップロードするのではなく、この静的辞書からテキストフレーズにアクセスすることにより、多くの場合改善できます。
As an example, a static dictionary is provided for the protocols SIP and SDP, RFC 3485 [4]. This dictionary is designed for use by a wide range of compression algorithms including all of the ones covered in Section 4.
例として、プロトコルSIPおよびSDP、RFC 3485 [4]に静的辞書が提供されています。この辞書は、セクション4でカバーされているすべてのものを含む、幅広い圧縮アルゴリズムによって使用されるように設計されています。
In any of the compression algorithms of Section 4, the static dictionary can be accessed by inserting the following instruction immediately after the ":initialize_memory" label:
セクション4の圧縮アルゴリズムのいずれかで、「：initialize_memory」ラベルの直後に次の命令を挿入することにより、静的辞書にアクセスできます。
STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)
state-access（dictionary_id、6、0、024、0）
The parameters of STATE-ACCESS instruction will depend on the compression algorithm in use.
状態アクセス命令のパラメーターは、使用中の圧縮アルゴリズムに依存します。
The following lines should also be inserted immediately after the END-MESSAGE instruction:
次の行も、終了命令の直後に挿入する必要があります。
:dictionary_id
：dictionary_id
byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
バイト（0xfb、0xe5、0x07、0xdf、0xe5、0xe6）
The text strings contained in the static dictionary can then be accessed in exactly the same manner as the text strings from previously decompressed messages (see Section 5.1 for further details).
静的辞書に含まれるテキスト文字列は、以前に減圧されたメッセージのテキスト文字列とまったく同じ方法でアクセスできます（詳細については、セクション5.1を参照）。
Note that in some cases it is sufficient to load only part of the static dictionary into the UDVM memory. Further information on the contents of the SIP and SDP static dictionary can be found in the relevant document, RFC 3485 [4].
場合によっては、静的辞書の一部のみをUDVMメモリにロードするだけで十分であることに注意してください。SIPおよびSDP静的辞書の内容の詳細については、関連するドキュメントRFC 3485 [4]にあります。
The acknowledgement scheme of Section 5.1 is designed to indicate the successful decompression of a message. However, it does not guarantee that the decompressed message is identical to the original message, since decompression of a corrupted message could succeed but with some characters being incorrect. This could lead to an incorrect message being passed to the application or unexpected contents of state to be stored. In order to prevent this happening, a CRC check could be used.
セクション5.1の謝辞スキームは、メッセージの減圧の成功を示すように設計されています。ただし、破壊されたメッセージの減圧が成功する可能性があるが、一部の文字が正しくないため、減圧メッセージが元のメッセージと同一であることを保証するものではありません。これにより、誤ったメッセージがアプリケーションに渡されるか、保存する状態の予期しない内容に渡される可能性があります。これを防ぐために、CRCチェックを使用できます。
If an additional CRC check is required, then the following bytecode can be inserted after the ":end_of_message" label:
追加のCRCチェックが必要な場合、「：end_of_message」ラベルの後に次のバイトコードを挿入できます。
INPUT-BYTES (2, index, !) CRC ($index, 64, state_length, !)
input-bytes（2、index、！）crc（$ index、64、state_length、！）
The bytecode extracts a 2-byte CRC from the end of the SigComp message and compares it with a CRC calculated over the UDVM memory. Decompression failure occurs if the two CRC values do not match.
ByteCodeは、SigCompメッセージの端から2バイトCRCを抽出し、UDVMメモリで計算されたCRCと比較します。2つのCRC値が一致しない場合、減圧障害が発生します。
A definition of the CRC polynomial used by the CRC instruction can be found in SigComp [2].
CRC命令で使用されるCRC多項式の定義は、SigComp [2]に記載されています。
If a particular endpoint is able to offer more processing or memory resources than the mandatory minimum, the SigComp feedback mechanism can be used to announce that these resources are available to the remote endpoint. This may help to improve the overall compression ratio between the two endpoints.
特定のエンドポイントが必須の最小値よりも多くの処理またはメモリリソースを提供できる場合、SigCompフィードバックメカニズムを使用して、これらのリソースがリモートエンドポイントで利用可能であることを発表できます。これは、2つのエンドポイント間の全体的な圧縮比を改善するのに役立つ場合があります。
Additionally, if an endpoint has any pieces of state that may be useful for the remote endpoint to reference, it can advertise the identifiers for the states. The remote endpoint can then make use of any that it also knows about (i.e., knows the contents of), for example, a dictionary or shared mode state (see Section 5.5).
さらに、エンドポイントにリモートエンドポイントが参照するために役立つ可能性のある状態がある場合、州の識別子を宣伝できます。リモートエンドポイントは、辞書や共有モード状態などについても知っている（つまり、内容を知っている）ものを利用できます（セクション5.5を参照）。
The values of the following SigComp parameters can be announced using the SigComp advertisement mechanism:
次のSigCompパラメーターの値は、SigComp広告メカニズムを使用して発表できます。
cycles_per_bit decompression_memory_size state_memory_size SigComp_version state identifiers
cycles_per_bit decompression_memory_size state_memory_size sigcomp_version状態識別子
As explained in SigComp, in order to announce the values of these parameters, the following fields must be reserved in the UDVM memory:
Sigcompで説明されているように、これらのパラメーターの値を発表するには、UDVMメモリに次のフィールドを予約する必要があります。
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 :
| |
+---+---+---+---+---+---+---+---+
These fields can be reserved in any of the algorithms of Section 4 by replacing the line "set (returned_parameters_location, 0)" with the following piece of assembly:
これらのフィールドは、セクション4のアルゴリズムのいずれかで、「set（returned_parameters_location、0）」を次のアセンブリに置き換えることにより、次の部分に予約できます。
:adverts_len pad (1)
:adverts_len_lsb pad (1)
:returned_parameters_location pad (1)
:returned_sigcomp_version pad (1)
:state_ids pad (x)
where x is enough space for the number state identifiers that the endpoint wishes to advertise.
Xは、エンドポイントが宣伝したい数の状態識別子に十分なスペースです。
When a SigComp message is successfully decompressed and saved as state, the following bytecode announces to the receiving endpoint that additional resources and pieces of state are available at the sending endpoint:
Sigcompメッセージが正常に解凍され、状態として保存されると、次のバイトコードが受信エンドポイントに、送信エンドポイントで追加のリソースと状態が利用可能であることを発表します。
:end_of_message
：end_of_message
LOAD (returned_parameters_location, N) INPUT-BYTES (1, adverts_len_lsb, done) INPUT-BYTES ($adverts_len, state_ids, done)
load（returned_parameters_location、n）input-bytes（1、adverts_len_lsb、done）input-bytes（$ adverts_len、state_ids、done）
:done
：終わり
Note that the integer value "N" should be set equal to the amount of resources available at the sending endpoint. N should be expressed as a 2-byte integer with the most significant bits corresponding to the cycles_per_bit parameter and the least significant bits corresponding to the SigComp_version parameter.
整数値「n」は、送信エンドポイントで利用可能なリソースの量に等しく設定する必要があることに注意してください。nは、Cycles_Per_bitパラメーターに対応する最も重要なビットとSigComp_versionパラメーターに対応する最も重要なビットを持つ2バイト整数として表現する必要があります。
The length of the state identifiers followed by the state identifiers in the format shown are appended to the end of the compressed message.
表示された形式の状態識別子がそれに続く状態識別子の長さは、圧縮メッセージの最後に追加されます。
This section provides bytecode for implementing the SigComp shared compression mechanism, RFC 3321 [3]. If two endpoints A and B are communicating via SigComp, shared compression allows the messages sent from Endpoint A to Endpoint B to be compressed relative to the messages sent from Endpoint B to Endpoint A (and vice versa). This may improve the overall compression ratio by reducing the need to transmit the same information in both directions.
このセクションでは、SigComp共有圧縮機構RFC 3321 [3]を実装するためのByteCodeを提供します。2つのエンドポイントAとBがSIGCOMPを介して通信している場合、共有圧縮により、エンドポイントAからエンドポイントBに送信されたメッセージが、エンドポイントBからエンドポイントA（および逆）に送信されたメッセージと比較して圧縮されます。これにより、同じ情報を両方向に送信する必要性を減らすことにより、全体的な圧縮率が改善される可能性があります。
As described in RFC 3321 [3], two steps must be taken to implement shared compression at an endpoint.
RFC 3321 [3]で説明されているように、エンドポイントで共有圧縮を実装するには、2つのステップを取る必要があります。
First, it is necessary to announce to the remote endpoint that shared compression is available. This is done by announcing the state identifier as an available piece of state. This can be done using the returned_parameters_location announcement as in Section 5.4.
まず、共有圧縮が利用可能であることをリモートエンドポイントに発表する必要があります。これは、状態識別子を利用可能な状態として発表することによって行われます。これは、セクション5.4のように、returned_parameters_locationアナウンスを使用して実行できます。
Second, assuming that such an announcement is received from the remote endpoint, then the state created by shared compression needs to be accessed by the message sent in the opposite direction. This can be done in a similar way to accessing the static dictionary (see Section 5.2), but using the appropriate state identifier, for example, by using the INPUT-BYTES instruction as below:
第二に、そのような発表がリモートエンドポイントから受け取られていると仮定すると、共有圧縮によって作成された状態は、反対方向に送信されたメッセージによってアクセスする必要があります。これは、静的辞書にアクセスするために同様の方法で実行できます（セクション5.2を参照）が、たとえば、以下の入力バイト命令を使用する場合、適切な状態識別子を使用して：
:shared_state_id pad (6)
：shared_state_idパッド（6）
:access_shared_state
：Access_shared_state
INPUT-BYTES (6, shared_state_id, !) STATE-ACCESS (shared_state_id, 6, 0, 0, $decompressed_start, 0)
input-bytes（6、shared_state_id、！）state-access（shared_state_id、6、0、0、$ decompressed_start、0）
This document describes implementation options for the SigComp protocol [2]. Consequently, the security considerations for this document match those of SigComp.
このドキュメントは、SigCompプロトコルの実装オプションについて説明しています[2]。その結果、このドキュメントのセキュリティ上の考慮事項は、Sigcompのセキュリティと一致します。
Thanks to Richard Price, Carsten Bormann, Adam Roach, Lawrence Conroy, Christian Schmidt, Max Riegel, Lars-Erik Jonsson, Jonathan Rosenberg, Stefan Forsgren, Krister Svanbro, Miguel Garcia, Christopher Clanton, Khiem Le, Ka Cheong Leung, and Zoltan Barczikay for valuable input and review.
リチャード・プライス、カルステン・ボーマン、アダム・ローチ、ローレンス・コンロイ、クリスチャン・シュミット、マックス・リーゲル、ラース・エリック・ジョンソン、ジョナサン・ローゼンバーグ、ステファン・フォーグレン、クリスター・スバンブロ、ミゲル・ガルシア、クリストファー・クレントン、キーメムレ貴重な入力とレビューのため。
Special thanks to Pekka Pessi and Cristian Constantin, who served as committed working group document reviewers.
献身的なワーキンググループのドキュメントレビュー担当者を務めたPekka PessiとCristian Constantinに感謝します。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[2] Price、R.、Bormann、C.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「Signaling Compression（Sigcomp）」、RFC 3320、2003年1月。
[3] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu, Z., and R. Price, "Signaling Compression (SigComp) - Extended Operations", RFC 3321, January 2003.
[3] Hannu、H.、Christoffersson、J.、Forsgren、S.、Leung、K.C.、Liu、Z.、およびR. Price、「Signaling Compression（Sigcomp） - 拡張作戦」、RFC 3321、2003年1月。
[4] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.B. Roach, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003.
[4] Garcia-Martin、M.、Bormann、C.、Ott、J.、Price、R。、およびA.B.Roach、「セッション開始プロトコル（SIP）およびセッション説明プロトコル（SDP）シグナリング圧縮のための静的辞書（SIGCOMP）」、RFC 3485、2003年2月。
[5] Ziv, J. and A. Lempel, "A universal algorithm for sequential data compression", IEEE 23:337-343, 1977.
[5] Ziv、J。およびA. Lempel、「シーケンシャルデータ圧縮のための普遍的なアルゴリズム」、IEEE 23：337-343、1977。
[6] Storer, J., "Data Compression: Methods and Theory", Computer Science Press ISBN 0-88175-161-8, 1998.
[6] Storer、J。、「データ圧縮：方法と理論」、コンピューターサイエンスプレスISBN 0-88175-161-8、1998。
[7] Nelson, M., "LZW Data Compression", Dr Dobb's Journal, October 1989.
[7] ネルソン、M。、「LZWデータ圧縮」、Dobb博士ジャーナル、1989年10月。
[8] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[8] Deutsch、P。、「圧縮データ形式の仕様バージョン1.3」、RFC 1951、1996年5月。
[9] "Data Compression Procedures", ITU-T Recommendation V.44, November 2000.
[9] 「データ圧縮手順」、ITU-T推奨v.44、2000年11月。
The following sections list the UDVM bytecode generated for each compression algorithm of Section 4.
次のセクションには、セクション4の各圧縮アルゴリズムに対して生成されたUDVMバイトコードを示します。
Note that the different assemblers can output different bytecode for the same piece of assembly code, so a valid assembler can produce results different from those presented below. However, the following bytecode should always generate the same decompressed messages on any UDVM.
異なるアセンブラーは、同じアセンブリコードの異なるバイトコードを出力できるため、有効なアセンブラーは以下に示すものとは異なる結果を生成できることに注意してください。ただし、次のBytecodeは、常にudvmで同じ減圧メッセージを生成する必要があります。
0x0f86 0389 8d89 1588 8800 011c 0420 0d13 5051 2222 5051 16f5 2300 0x00bf c086 a08b 06
0x0F86 0389 8D89 1588 8800 011C 0420 0D13 5051 2222 5051 16F5 2300 0x00BF C086 A08B 06
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 0x2252 5116 9fd2 2300 00bf c086 a089 06
0x0f86 04a0 c48d 00a0 c41e 2031 0209 00a0 ff8e 048c bfff 0117 508d 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 0x2252 5116 9fd2 2300 00bf c086 a089 06
0x0f86 06a1 ce8d 00b1 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x88f4 079f 681d 0a24 2508 1203 0612 b18f 1252 0321 0ea0 4801 0624 0x5013 a049 0323 1351 5025 2251 5016 9fde 2300 00bf c086 a09f 06
0x0F86 06A1 CE8D 00B1 8F01 A0CE 13A0 4903 2313 2501 2506 1201 1752 0x88F4 079F 681D 0A24 2508 1203 0612 B18F 1252 0321 0EA0 DE 2300 00BF C086 A09F 06
0x0f86 7aa2 528d 05a2 5200 0300 0400 0500 0600 0700 0800 0900 0a01 0x0b01 0d01 0f01 1102 1302 1702 1b02 1f03 2303 2b03 3303 3b04 a043 0x04a0 5304 a063 04a0 7305 a083 05a0 a305 a0c3 05a0 e300 a102 0001 0x0002 0003 0004 0105 0107 0209 020d 0311 0319 0421 0431 05a0 4105 0xa061 06a0 8106 a0c1 07a1 0107 a181 08a2 0108 a301 09a4 0109 a601 0x0aa8 010a ac01 0bb0 010b b801 0c80 2001 0c80 3001 0d80 4001 0d80 0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 a0bf 0000 a0c0 0xa0c7 8040 2901 a190 a1ff a090 1750 8040 1109 a046 1322 2101 1321 0x0123 169f d108 1004 1250 0422 1d51 229f d706 1251 1e20 9fcf 0105 0x001f 2f08 1004 1250 0426 1d53 26f6 0614 530e 2063 1454 5223 2250 0x5216 9f9e 2300 00bf c086 a1de 06
0x0F86 7AA2 528D 05A2 5200 0300 0400 0500 0600 0700 0800 0900 0A01 0x0B01 0D01 0F01 1102 1302 1702 1B02 1F03 2303 2B03 3303 A305 A0C3 05A0 E300 A102 0001 0x0002 0003 0004 0105 0107 0209 020D 0311 0319 0421 043105a0 4105 0xa061 06A0 8106 A0C1 07A1 0107 A181 08A2 0108 A301 09A4 0109 A601 0X0AA8 010A AC01 0BB0 010B B801 0C80 2001 0C80 504 0700 1780 4011 0130 A0BF 0000 A0C0 0XA0C7 8040 2901 A190 A1FF A090 1750 8040 1109A046 1322 2101 1321 0x0123 169F D108 100410041004 1250 0422 1D51 229F D706 1251 1E20 9FCF 0105 0x001F 2F08 1004 1250 0426 1D53 26F6 0614 530E 2063 1454 5232232523252325232523252325232525232525232522325412121212121212121212121212212122169P2168F216 E 06
0x0f86 08a1 5b8d 0700 a15b 0706 b18f 1d01 24a0 c317 5201 1a31 311e 0x24a0 b802 0101 0102 0100 0100 1752 0107 a04e 1e1d 6524 f822 2501 0x0ea0 4602 13a0 4703 2713 2501 2416 9fcd 1d66 24e1 1752 03a0 639f 0xb808 0812 0306 12b1 8312 5203 210e a046 0106 2350 0e28 6713 a047 0x0327 1351 5024 2251 5016 9fa8 1e24 9fb1 0401 0101 0102 0103 0201 0x0101 0d03 0007 0517 520d 0d06 061d 0826 f706 1253 1351 5011 1351 0x5224 2251 5206 1250 1225 0154 169f 6617 5201 9fdb 070f 1c00 009e 0xce16 9f57 1d01 24fa 1752 0107 0d9e c206 2501 169f 6506 2601 169f 0x7623 0000 bfc0 86a0 8e06
0x0F86 08A1 5B8D 0700 A15B 0706 B18F 1D01 24A0 C317 5201 1A31 311E 0x24A0 B802 0101 0102 0100 FCD 1D66 24E1 1752 03A0 639F 0XB808 0812 0306 12B1 8312 5203 210E A046 0106 2350 0E286713 A047 0x0327 1351 5024 2251 5016 9FA8 1E24 9FB1 0401 0101 0102 0103 0201 0x0101 0D03 0007 0517 F 6617 5201 9FDB 070F 1C00 009E 0XCE16 9F57 1D01 24FA 1752 0107 0D9E C206 2501169F 6506 2601 169F 0x7623 0000 BFC0 86A0 8E06
0x0f86 04a1 d38d 00a1 d31e 20a1 4010 0500 0b2e 000c 0c88 011a 20a1 0x0101 a042 a044 2000 a045 a05e a061 00a0 5fa0 66a1 0800 a067 a067 0xa1ff 02a1 a0a1 aa23 00a1 aba1 d13a 00a1 d2a1 e1a1 1001 a3c4 a3e3 0xa120 03bf 20bf 34a0 7b00 bf35 bfb3 a180 0180 3f68 803f 8700 0080 0x3f88 803f c7a1 4001 807f 9080 7fff a090 1750 88a0 79a0 83a0 831e 0x20a0 c810 0400 00a1 ff01 0209 8801 1416 2000 171e a108 013e a049 0x2e00 a04a a059 a110 02a1 68a1 81a0 6100 a182 a1a1 a120 01a3 44a3 0x6a3a 00a3 6ba3 aaa1 4001 a756 a760 2300 a761 a7df a180 01af c0af 0xd4a0 7b01 bfaa bfc9 0001 803f 9480 3ffb a090 0180 7ff8 807f ffa0 0xf817 5088 0610 1022 2101 1321 0123 169f 1107 10a0 fd1e 229f d909 0x0900 0709 0008 3fa0 8101 87a0 8701 00a0 88a0 f711 00a0 f8a1 3fa0 0xb901 a280 a57f a101 02b6 00b9 ffa4 0101 8034 0080 3bff a801 0290 0x00ff b001 0e24 6314 5150 2322 5250 169f 3b23 0000 bfc0 86a0 8906
0x0F86 04A1 D38D 00A1 D31E 20A1 4010 0500 0B2E 000C 0C88 011A 20A1 0X0101 A042 A044 2000 A045 A05E A061 00A0 5FA0 66A1 3A 00A1 D2A1 E1A1 1001 A3C4 A3E3 0XA120 03BF 20BF 34A0 7B00 BF35 BFB3 A180 0180 3F68 803F8700 0080 0x3F88 803F C7A1 4001 807F 9080 7FFF A090 1750 88A0 79A0 83A0 831E 0x20A0 C810 0400 00A1 FF01 0209 8801 1416 2000 171E A108 013E A049 A049 A049 A049 A01EA01E 1 81A0 6100 A182 A1A1 A120 01A3 44A3 0x6A3A 00A3 6BA3 AAA1 4001 A756 A760 2300 A761A7DF A180 01AF C0AF 0XD4A0 7B01 BFAA BFC9 0001 803F 9480 3FFB A090 0180 7FF8 807F FFA0 0XF817 5088 0610 1022 2101 1321 0123 169f 0 8101 87A0 8701 00A0 88A0 F711 00A0 F8A1 3FA0 0XB901 A280 A57F A101 02B6 00B9 FFA40101 8034 0080 3BFF A801 0290 0x00FF B001 0E24 6314 5150 2322 5250 169F 3B23 0000 BFC0 86A0 8906
Authors' Addresses
著者のアドレス
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey、Hants So51 0Zn UK
Phone: +44 (0)1794 833131
EMail: abigail.surtees@roke.co.uk
URI: http://www.roke.co.uk
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey、Hants SO51 0ZN UK
Phone: +44 (0)1794 833311
EMail: mark.a.west@roke.co.uk
URI: http://www.roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。