Network Working Group A. Surtees
Request for Comments: 4464 M. West
Category: Informational Siemens/Roke Manor Research
May 2006
Signaling Compression (SigComp) Users' Guide
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).
著作権（C）インターネット協会（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の実装を決定する際、例えば、圧縮アルゴリズム及び紛失またはmisorderedパケットに対するロバスト性のレベルの選択をユーザーを支援することです。
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の背後にある考え方は、DEFLATE [8]とLZWなど、多くのよく知られているコンプレッサーの出力を理解するようにプログラムすることができるユニバーサルデコンプレッサ仮想マシン（UDVM）を標準化することである[7]。選択された圧縮アルゴリズムのためのバイトコードは、圧縮データの一部として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プロトコルによって使用することができる異なる圧縮機の多数の例を与えます。また、[3] RFC 3321に記載され（例えば、肯定応答など）機構の一部を使用する方法の例を与えます。
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は、受信エンドポイントに新しいアルゴリズムのためのバイトコードをアップロードすることができるので、任意の圧縮アルゴリズムは、適切なバイトコードは、対応する減圧装置のために書かれていることを条件に支持することができます。
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の圧縮機は、パケットが送信中に失われたりmisorderedされている場合でもメッセージを正しく解凍することができることを保証する責任があります。 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
追加リソース5.共有圧縮を発表4.のSigCompフィードバックメカニズム3.巡回冗長符号（CRC）チェックサムを前記静的辞書を使用して1謝辞
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バイトコードの例サブルーチンは、機構のそれぞれに設けられています。これらのサブルーチンは、基本的な圧縮アルゴリズムのいずれかのバイトコードに追加することができます。 （注：サブルーチンや基本的なアルゴリズムは、彼らが正常に一緒に働くことを確認するためにマイナーな修正が必要な場合があります。）
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プログラムを書くことは、困難な作業になります。アセンブリ言語は、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アセンブリ言語の構文は、字句および構文レベルに文法を分割、慣用二レベル記述の技術を使用します。
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).
字句レベルでは、アセンブリの列は、必要に応じて空白で区切られたゼロ以上のトークンから構成されています。各トークンは、テキスト名、命令オペコード、デリミタ、または（小数、バイナリ、または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 = "+" / "-" / "*" / "/" / "%" / "&" / "|" / "^" / "~" / "<<" / ">>"
トークン=（名前/オペコード/区切り文字/ 12月/ binに/進）名=（小文字/ "_"）0 *（小文字/数字/ "_"）オペコード=大文字*（大文字/数字/ " - "）区切り文字= "" / "" / "！" / "$" / "：" / "（" / "）" /演算子12月= 1 *（桁）ビン= "0B" 1 *（ "0" / "1"）の六角= "0X" 1 *（16進数桁）ヘキサ桁=桁/％x41-46 /％x61-66桁=％x30-39大文字=％のx41-5a小文字=％のx61-7a演算子= "+" / " - " / "*" / "/" / "％" / "＆" / "|" / "^" / "〜" / "<<" / ">>"
When parsing for tokens, the longest match is applied, i.e., a token is the longest string that matches the <token> rule specified above.
トークンを解析する場合、最長一致が適用され、すなわち、トークンは、上記指定された<トークン>ルールと一致する最も長い文字列です。
The syntax of whitespace and comments is specified by the following ABNF:
空白やコメントの構文は以下のABNFによって指定されています。
ws = *(%x09 / %x0a / %x0d / %x20 / comment) comment = ";" *(%x00-09 / %x0b-0c / %x0e-ff) (%x0a / %x0d)
= *（％X09 /％X0A / x0d％/％X20 / komment）komment = "？" *（％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.
LOAD（TEMP、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.
字句レベルで解析するとき、アセンブリの列が連続したトークンのリストに分割されなければなりません。空白やコメントも削除する必要があります。 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
アセンブリ= *（命令/ディレクティブ/ラベル）命令=オペコード[ "（" オペランド*（ "" オペランド） "）"]オペランド= [[ "$"]表現]。オペランドは、彼らができれば空白のままにすることができます。自動で推測され、コンパイラ、例えば、リテラルオペランド。それはの合計数を指定します。命令のオペランド。 ; 「$」はオペランドの前に付加されている場合、。対応する整数です。実際のオペランドではなく、対処します。値。この記号は必須です。参照オペランドのためのオプション。 multitypesとアドレス、および;リテラルのために許可されていません。ラベル= "：" 名ディレクティブ=パディング/データ/ /読み取り専用設定/未知のディレクティブ不明ディレクティブ=名[ "（" 表現*（ "" 表現） "）"];パーサは不明無視することができます。ディレクティブ。結果として得られるバイトコード。または期待を生成しない場合があります。結果。パディング=（ "パッド" / / "AT"、 "整列"） "（" 発現 "）" データ=（ "バイト" / "単語"） "（" 発現（* "" 発現） "）、" 読み取り専用= "読み取り専用 " "（"、 "0"/ "1" "）" "（" 名前"、」表現 "）" 式=値/ "（" 発現オペレータ発現を "）" "設定" =設定値= DEC / binに/六角/名前/ "" / "！" ; ""この場所です。命令/ディレクティブのに対し、「！」です。最も近くの場所。圧縮解除-FAILURE
The following sections define how to convert the instructions, labels and directives into UDVM bytecode:
次のセクションでは、UDVMバイトコードに指示、ラベルやディレクティブを変換する方法を定義します。
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:
特定の命令またはディレクティブが必要とするオペランドの値は、式の形で与えることができます。発現は小数、バイナリ、またはヘキサ（バイナリ値が「0B」によって先行され、進値が「0X」が先行している）として指定された1つ以上の値を含むことができます。式はまた、以下の演算子の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
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:
式には、また、特別な値を含めることができます「」そして、 "！"。ときに記号「」遭遇し、それが現在の命令/ディレクティブのバイトコード内の位置によって置き換えられています。ときにシンボル「！」それは最も近い圧縮解除-FAILURE命令（すなわち、最も近いゼロバイト）のバイトコード内の位置によって置き換えられる遭遇します。例えば、解凍失敗を呼び出す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命令はゼロ以上のオペランドが続く命令オペコードによって指定されます。命令オペランドは、括弧で囲まれ、例えば、コンマで区切られています。
ADD ($3, 4)
ADD（$ 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.
バイトコードに各命令オペランドを変換するとき、パーサは最初の命令は、オペランドがリテラル、参照、マルチタイプ、またはアドレスであることを期待するかどうかを判断します。オペランドがリテラルである場合、次に、の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)
MULTILOAD（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の通り、それはバイトコードを挿入した場合は（通常は最短の）メモリアドレスとして供給された整数をコードすることができます。そうでない場合、次に、のSigCompの図10の通り、それはオペランド値として供給される整数をコードバイトコード（通常最も短い）を挿入します。
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.
オペランドがアドレスである場合には、記号「$」は存在しているパーサーかどうかをチェックします。もしそうであれば、供給された整数は、単に上記マルチタイプ命令の場合と同様に、メモリアドレスとして符号化されます。そうでない場合には、命令コードのバイト位置は、供給された整数値モジュロ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).
指令「パッド（n）は、」バイトコードのn個の連続パディングバイトを追加します。パディングバイトの実際の値は重要ではないので、バイトコードをUDVMにアップロードされたときに、パディングバイト（これはのSigCompメッセージのサイズを低減するのに役立つ）UDVMメモリに含まれている初期値に設定することができます。
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.
「（N）の」ディレクティブは、これまでに生成されたバイトコードのバイト数の合計が正確にnバイトになるようにバイトコードに十分なパディングバイトを追加します。ディレクティブ「に」遭遇する前に、複数のnバイトが既に生成されている場合は、アセンブリコードは、エラーが含まれています。
The directives "byte" and "word" can be used to add specific data strings to the 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個の連続バイトを付加します。バイト文字列は整数を与えるために評価される式として供給されたn [0]、...、N [K-1] 0から255まで。
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バイトワードを付加します。単語列は整数を与える評価式として供給されるN [0]、...、N [K-1]は0から65535まで。
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）」指令はnは0または1であり（0）メモリの領域を変更することができることを示すために使用することができ、またはUDVMの実行中（1）変更することはないであろう。このディレクティブはと併せて、例えば、使用することができ、「！」バイトコードが実行されるときに使用さゼロのアドレスはまだゼロが含まれていることを確認します。何の読み取り専用ディレクティブが使用されていない場合は、ゼロを含む任意のアドレスを使用することができ、「！」 （すなわち、デフォルトでは、アドレス0に読み取り専用（1）指令があると仮定される）、それは、バイトコードが実行されるときに当該アドレスが依然としてゼロを含むであろうことを保証するために、アセンブリコードの作成者次第です。読み取り専用ディレクティブが使用されている場合は、それまでに使用してはならない読み取り専用（0）および読み取り専用（1）ペア間のバイト「！」。読み取り専用ディレクティブが使用されている場合は、バイトはそのアドレスから別の読み取り専用ディレクティブまたはいずれか早い方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:
ラベルは定義するテキスト名に続いて1つのコロンによって指定されています。すぐにラベル次のバイトの（絶対）位置が評価され、テキスト名に割り当てられます。例えば：
:start
：開始
LOAD (temp, 1)
LOAD（TEMP、1）
Since the label "start" occurs at the beginning of the bytecode, it is assigned the integer value 0.
ラベル「スタート」は、バイトコードの先頭で発生するので、それは整数値0が割り当てられます。
Note that writing the label ":name" has exactly the same behavior as writing the directive "set (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.
パーサーは、対応するバイトコードにアセンブリの文字列を変換した後、それは、バイトコードの最初のUDVM命令から始まる、アドレス0から始まるUDVMメモリにコピーして実行されなければなりません。
SigComp provides the following message format for uploading bytecode to the UDVM:
SigCompはUDVMにバイトコードをアップロードするため、次のメッセージフォーマットを提供します：
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ヘッダを使用してUDVMにアップロードすることができないことに留意されたいです。特に、第1 UDVM命令のメモリアドレスは常に64バイトまたは標準のSigCompヘッダ使用することができないの倍数でなければなりません。もちろん、このようなINPUT-BYTES命令を介して直接バイトコードを取得すると、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によって値固有のエンドポイントに初期化されるので、それらを使用することができないバイトコードにパディング、または標準のSigCompヘッダとして指定しなければなりません。 （先 - 1）アドレスへのアドレス32からメモリアドレス包括的には0に初期化されるので、バイトコードが正常に標準のSigCompヘッダを使用してアップロードする場合、それらはパディングとして、または0のいずれかとして指定されなければなりません。
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）で始まるすべてのメモリアドレス（0）UDVMによって初期化として、または実行時にバイトコードによって設定されたいずれかであるような最小の値に設定されるべきです。
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バイトコードは、」アドレス（宛先）と住所（1先+ code_len）の間にあるバイトコードのセグメントを含むように設定する必要があります。
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の圧縮機で使用できる圧縮アルゴリズムの数を記載しています。各場合において、文書は、のSigCompメッセージの一部として受信エンドポイントにアップロードすることができ、対応する解凍アルゴリズム用UDVMバイトコードを提供します。各アルゴリズムは、（このセクションで記述されたように）ビット当たり16サイクルがあり、16K減圧メモリサイズがあることを前提とし、及び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方式によって生成された圧縮されたメッセージは、各文字が2バイトの長さの値に続く2バイトの位置値を含む4バイト文字のシーケンスから成ります。整数の各ペアはUDVMメモリ内のバイト列を識別します。連結されたとき、これらのバイト列は、解凍メッセージを形成します。
When implementing a bytecode decompressor for the simplified LZ77 scheme, the UDVM memory is partitioned into five distinct areas, as shown below:
簡略LZ77スキームのバイトコードデコンプレッサを実装する場合、以下に示すように、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圧縮解除のためのバイトコードは、LZ77圧縮解除が少ない必要が128バイトの合計バイトコードのために予約されているアドレス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のバイトは255包括的に整数値0を含むように、バイトコードによって初期化されています。このメモリ領域の目的は、すべての可能な圧縮されていない文字の辞書を提供することです。これは、圧縮機が常に所定のメッセージをエンコード位置/長さのペアの配列を生成することができることを確実にするために重要です。例えば、値0×41のバイトは、（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)
：position_valueパッド（2）：length_valueパッド（2）（42）で
set (requested_feedback_location, 0)
セット（requested_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:
;メッセージを解凍した後、格納すべき変数です。ここに保存されました。これらの変数は、SigCompの状態の一部を形成します。バイトコードによって作成されたアイテム：
:byte_copy_left pad (2) :byte_copy_right pad (2) :decompressed_pointer pad (2)
：パッドbyte_copy_left（2）：byte_copy_rightパッド（2）：decompressed_pointerパッド（2）
set (returned_parameters_location, 0)
セット（returned_parameters_location、0）
align (64)
（64）を整列させます
:initialize_memory
：メモリを初期化します
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
設定された設定（udvm_memory_size、8192）（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:
; UDVMはbyte_copy_leftとbyte_copy_rightに設定されているレジスタ。 UDVMメモリ内の循環バッファの境界を示しています。 A;変数decompressed_pointerも作成してを指して設定されています。循環バッファの開始：
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:
;圧縮されたメッセージ内の次の文字はUDVMによって読み取られます。位置および長整数変数に格納されています。それぞれposition_valueとlength_value、。これ以上の場合は、圧縮されたデータが利用可能である、デコンプレッサはにジャンプします。 "end_of_message" サブルーチン：
INPUT-BYTES (4, position_value, end_of_message)
INPUTバイト（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:
;でバイト列にposition_valueとlength_valueポイント。円形のバッファにコピーされたUDVMメモリ。 decompressed_pointerで指定された位置。これは文字列を許可します。圧縮されたメッセージの後の文字が参照します：
COPY-LITERAL ($position_value, $length_value, $decompressed_pointer)
COPYリテラル（$ 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)
JUMP（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 0×0002 0161 0001 0175 0001 0172 0001 0161 0001 016e 0001 0174 0001 0001 0161 0001 020d 0002 0174 0001 0201 0003 0145 0001 016eは0x0001 0164 0001 0120 0001 0x0120 0001 0166 0001 0211 0005 016F 0155 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フィールドは（状態識別子が導出される方法の詳細については、[2]を参照のこと）、アクセスする状態項目の状態識別子の最初の6つのバイトを含まなければなりません。
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圧縮アルゴリズムにUDVMバイトコードを提供する[6]。
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.
オフセット/長さのペアは3から18まで含めた4ビット長の値に続く1 4096から12ビットのオフセット値包含し、含まれています。まとめると、これらの値は、その後、解凍メッセージの最後に追加された循環バッファ内の以前に受信されたテキスト文字列のいずれかを指定します。
Assembly for an LZSS decompressor is given below:
LZSS圧縮解除のためのアセンブリは、以下の通りであります：
at (32) readonly (0)
（32）に読み取り専用（0）
:index pad (2) :length_value pad (2) :old_pointer pad (2)
：インデックスパッド（2）：length_valueパッド（2）：old_pointerパッド（2）
at (42)
（42）で
set (requested_feedback_location, 0)
セット（requested_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)
：パッドbyte_copy_left（2）：byte_copy_rightパッド（2）：input_bit_orderパッド（2）：decompressed_pointerパッド（2）
set (returned_parameters_location, 0)
セット（returned_parameters_location、0）
align (64) readonly (1)
（1）読み取り専用（64）を整列させます
:initialize_memory
：メモリを初期化します
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
設定された設定（udvm_memory_size、8192）（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-ハフマン（インデックス、end_of_message、2、9、0、255、16384、4、4096、8191、1）COMPARE（$インデックス、8192、長さ、end_of_message、リテラル）
:literal
：リテラル
set (index_lsb, (index + 1))
セット（index_lsb、（インデックス+ 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
：長さ
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）COPY-OFFSET（$インデックス、$ length_value、$ decompressed_pointer）OUTPUT（$ old_pointer、$ 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）
readonly (0) :circular_buffer
読み取り専用（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圧縮は、それが以前に受信した非圧縮データ、及び循環バッファから正確に1つのバイトのストリング各圧縮文字参照の円形のバッファを維持することで、LZ77と同様に動作します。しかし、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符号帳に格納されたバイト列1023包括的に0から単一の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)
：length_valueパッド（2）：position_valueパッド（2）：インデックスパッド（2）
at (42)
（42）で
set (requested_feedback_location, 0)
セット（requested_feedback_location、0）
at (64)
（64）で、
:byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2)
：byte_copy_leftパッド（2）：byte_copy_rightパッド（2）：パッドinput_bit_order（2）
:codebook_next pad (2) :current_length pad (2) :decompressed_pointer pad (2)
：codebook_nextパッド（2）：CURRENT_LENGTHパッド（2）：decompressed_pointerパッド（2）
set (returned_parameters_location, 0)
セット（returned_parameters_location、0）
align (64)
（64）を整列させます
:initialize_memory
：メモリを初期化します
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
設定された設定（udvm_memory_size、8192）（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、コードブック、1、static_dictionary）
:initialize_codebook
：initialize_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))
設定された設定（index_lsb、（インデックス+ 1））（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リテラル（current_length_lsb、3、$のcodebook_next）COPYリテラル（index_lsb、1、$のdecompressed_pointer）（$インデックスは、1）COMPARE ADD（$インデックス、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)
INPUTビット（10、インデックス、end_of_message）
; The following instructions interpret the received bits as an index ; into the LZW codebook and extract the corresponding ; position/length pair:
;以下の手順は、インデックスとして、受信したビットを解釈します。 LZW符号帳へと対応を抽出します。位置/長さのペア：
set (length_value_lsb, (length_value + 1))
セット（length_value_lsb、（length_value + 1））
MULTIPLY ($index, 3) ADD ($index, codebook) COPY ($index, 3, length_value_lsb)
MULTIPLY（$インデックスは、3）（$インデックス、コードブック）コピーを追加（$インデックス、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リテラル（current_length_lsb、3、$ codebook_next）COPYリテラル（$ 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
02bf F0 0x14c6 f080 6c1b c6e1 9c20 1846 E190 201D 0684 206B 1cc2 0198 6f1c 0x9071 b06c 42c6 8195 111A 4731 A021
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.
このセクションでは、deflate圧縮アルゴリズムにUDVMバイトコードを提供します。 DEFLATEは、よく知られた「GZIP」のファイル形式で使用されるアルゴリズムです。
The following bytecode will decompress the DEFLATE compressed data format [8] with the following modifications:
次のバイトコードは、以下の改変を伴う[8] DEFLATE圧縮データ形式を解凍します。
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（固定ハフマン符号で圧縮データ）をDEFLATEサポート。
Assembly for the DEFLATE decompressor is given below:
DEFLATE圧縮解除のためのアセンブリは、以下の通りであります：
at (32) readonly (0)
（32）に読み取り専用（0）
:index pad (2) :extra_length_bits pad (2) :length_value pad (2) :extra_distance_bits pad (2) :distance_value pad (2)
：インデックスパッド（2）：extra_length_bitsパッド（2）：length_valueパッド（2）：extra_distance_bitsパッド（2）：distance_valueパッド（2）
at (42)
（42）で
set (requested_feedback_location, 0)
セット（requested_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)
：パッドbyte_copy_left（2）：byte_copy_rightパッド（2）：input_bit_orderパッド（2）：decompressed_pointerパッド（2）
:length_table pad (116) :distance_table pad (120)
：length_tableパッド（116）：distance_tableパッド（120）
set (returned_parameters_location, 0)
セット（returned_parameters_location、0）
align (64)
（64）を整列させます
readonly (1) :initialize_memory
読み取り専用（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))
セット（udvm_memory_size、8192）セット（state_length、（udvm_memory_size - 64））セット（length_table_start、（（（length_table - 4）+ 65536）/ 4））セット（length_table_mid、（length_table_start + 24））セット（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, 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, 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, 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)
:decompress_sigcomp_message
：decompress_sigcomp_message
INPUT-BITS (3, extra_length_bits, !)
INPUT-BITS（3、extra_length_bits、！）
:next_character
：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)
INPUT-ハフマン（インデックス、end_of_message、4、7、0、23、length_table_start、1、48、191、0、0、192、199、length_table_mid、1、400、511、144）$インデックス、length_table_start、リテラル（COMPARE 、end_of_message、length_distance）
:literal
：リテラル
set (index_lsb, (index + 1))
セット（index_lsb、（インデックス+ 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（$指数、4）COPY（$インデックス、4、extra_length_bits）INPUT-BITS（$ extra_length_bits、extra_length_bitsは、！）（$ length_value、$ extra_length_bits）ADD
; 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-ハフマン（インデックス、！、1、5、0、31、distance_table_start）MULTIPLY（$指数、4）COPY（$インデックス、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（インデックスは、$ decompressed_pointer）COPY-OFFSET（$ distance_value、$ length_value、$ decompressed_pointer）OUTPUT（$インデックスは、$ 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）
readonly (0) :circular_buffer
読み取り専用（0）：circular_buffer
An example of a message compressed using the DEFLATE algorithm is given below:
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)
（32）に読み取り専用（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:
;次の2バイトの変数は、スクラッチパッドメモリに記憶されています。地域彼らは解凍後に保存する必要はありませんので。 SigCompメッセージ：
:length_value pad (2) :position_value pad (2) :index pad (2) :extra_extension_bits pad (2) :codebook_old pad (2)
：length_valueパッド（2）：position_valueパッド（2）：インデックスパッド（2）：extra_extension_bitsパッド（2）：codebook_oldパッド（2）
at (42)
（42）で
set (requested_feedback_location, 0)
セット（requested_feedback_location、0）
at (64)
（64）で、
; UDVM_registers
; UDVM_registers
:byte_copy_left pad (2) :byte_copy_right pad (2)
：パッドbyte_copy_left（2）：byte_copy_rightパッド（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)
：CURRENT_LENGTHパッド（2）：decompressed_pointerパッド（2）：ordinal_lengthパッド（2）：codeword_lengthパッド（2）：codebook_nextパッド（2）
set (returned_parameters_location, 0)
セット（returned_parameters_location、0）
align (64) readonly (1)
（1）読み取り専用（64）を整列させます
:initialize_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):
;次の定数は、LZJHを構成するように調整することができます。解凍器。 V.44で推奨されているように、現在の設定がされています。 （8K UDVMメモリの合計が利用可能であると仮定）仕様：
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
セット（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))
セット（codebook_start、4492）セット（first_codeword、（codebook_start - 12））を設定（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:
;次のコードは、標準的な1ビットLZJHプレフィックスを解凍し、それは、次の文字が序かであるかどうかを指定します。コードワード/コントロール値：
INPUT-BITS (1, index, end_of_message) COMPARE ($index, 1, ordinal, codeword_control, codeword_control)
INPUT-BITS（1、インデックス、end_of_message）COMPARE（$インデックス、1、序、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:
;次のコードは、その特殊なLZJH接頭辞を解凍します。コードワードの後に起こります。これは、次の文字かどうかを指定します。序、コードワード/コントロール値、または文字列の拡張子は次のとおりです。
INPUT-HUFFMAN (index, end_of_message, 2, 1, 1, 1, 2, 1, 0, 1, 0) COMPARE ($index, 1, ordinal, string_extension, codeword_control)
INPUT-ハフマン（インデックス、end_of_message、2、1、1、1、2、1、0、1、0）COMPARE（$インデックス、1、順序、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))
設定された設定（index_lsb、（インデックス+ 1））（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、インデックス、！）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）
: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、インデックス、！）COMPARE（$インデックス、3、control_code、initialize_memory、コードワード）
: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:
;次のコードは、LZJHへのインデックスとして符号語を解釈します。コードブック。これは、指定の位置/長さのペアを抽出します。コードブックエントリ;バイト文字列に位置/長さ対ポイント。その後の終わりにコピーされる循環バッファで、解凍メッセージ。コードは、新しいコードブックエントリを作成します。バイトの文字列をプラスにするために、次の文字からなります。解凍：
set (length_value_lsb, (length_value + 1))
セット（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)
MULTIPLY（$インデックス、3）ADD（$インデックス、first_codeword）COPY（$インデックス、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)
COPYリテラル（current_length_lsb、3、$のcodebook_next）COPYリテラル（$ 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-ハフマン（インデックス、！、4、1、1、1、1、2、1、3、2、1、1、1、13、3、0、7、5）COMPARE（$インデックスは、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（$インデックス、$ 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リテラル（$ position_value、$ length_value、$ position_value）COPYリテラル（$ position_value、$インデックスは、$ decompressed_pointer）OUTPUT（$ position_value、$インデックス）（$インデックスは、$ length_value）を追加COPY（index_lsb、1、$ codebook_old ）JUMP（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.
;コードは除くV.44での制御文字のすべてを扱うことができます。必要ありませんETM（トランスペアレントモードを入力します）、のために、このようにSigComp等のメッセージベースのプロトコル。
COMPARE ($index, 1, !, flush, stepup)
COMPARE（$インデックス、1、！、フラッシュ、昇圧）
:flush
：流す
; The FLUSH control character jumps to the beginning of the next ; complete byte in the compressed message:
; FLUSH制御文字は、次の先頭にジャンプします。圧縮されたメッセージでの完全なバイト：
INPUT-BYTES (0, 0, 0) JUMP (standard_prefix)
INPUTバイト（0、0、0）JUMP（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)
INPUT-BITS（1、インデックス、！）COMPARE（$インデックス、1、stepup_ordinal、stepup_codeword、0）
:stepup_ordinal
：stepup_ordinal
ADD ($ordinal_length, 1) JUMP (ordinal)
（$ ordinal_lengthを、1）ADD JUMP（序）
: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
読み取り専用（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 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".
圧縮されていないメッセージがある「...税務目的のために死んだ年を費やします\ 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]アルゴリズムの修正バージョンを示しています。 DEFLATEの二段階の符号化は、シンボル毎に離散的なハフマンコードを有する単一のステップによって置き換えられます。リテラル/長シンボル確率は、前のシンボルがリテラル又は一致したかどうかに依存しています。全てのビットがので、すべてのビットが入力されると、読み込まれ変化しないINPUT-ハフマン命令と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)
（32）に読み取り専用（0）
:index pad (2) :distance_value pad (2) :old_pointer pad (2)
：インデックスパッド（2）：distance_valueパッド（2）：old_pointerパッド（2）
at (42)
（42）で
set (requested_feedback_location, 0)
セット（requested_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)
：パッドbyte_copy_left（2）：byte_copy_rightパッド（2）：input_bit_orderパッド（2）：decompressed_pointerパッド（2）
set (returned_parameters_location, 0)
セット（returned_parameters_location、0）
at (128) readonly (1)
（128）での読み取り専用（1）
:initialize_memory
：メモリを初期化します
set (udvm_memory_size, 8192) set (state_length, (udvm_memory_size - 64))
設定された設定（udvm_memory_size、8192）（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,
INPUT-ハフマン（インデックス、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)
COMPARE（$インデックス、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-ハフマン（インデックス、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）
COMPARE ($index, 256, literal, distance, distance)
COMPARE（$インデックス、256、リテラル、距離、距離）
:literal
：リテラル
set (index_lsb, (index + 1))
セット（index_lsb、（インデックス+ 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,
SUBTRACT（$インデックス、253）INPUT-ハフマン（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)
LOAD (old_pointer, $decompressed_pointer) COPY-OFFSET ($distance_value, $index, $decompressed_pointer) OUTPUT ($old_pointer, $index) JUMP (character_after_match)
LOAD（old_pointer、$ decompressed_pointer）COPY-OFFSET（$のdistance_value、$インデックスは、$ decompressed_pointer）OUTPUT（$ old_pointer、$インデックス）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
読み取り専用（0）：circular_buffer
An example of a message compressed using the modified DEFLATE algorithm is given below:
修飾DEFLATEアルゴリズムを使用して圧縮されたメッセージの例を以下に示します：
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 930A a4ca 74a4 c268 0x0Cの
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によって使用することができる追加のメカニズムを、カバー辞書、及び圧縮されたメッセージ・フローの二つの方向の間で状態を共有します。
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.
アセンブリコードの例は、これらの機構のために設けられています。このアルゴリズムは、CRCの意志のための入力命令でend_of_messageを以下、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状態項目として保存されています。後続のメッセージは、メッセージごとに圧縮アルゴリズムのためのバイトコードをアップロードする必要性を回避する受信エンドポイントに正しい状態識別子をアップロードすることによって、この状態アイテムにアクセスすることができます。状態項目にアクセスできる前に、しかし、圧縮機は、最初に、受信エンドポイントで利用可能であることを保証しなければなりません。
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、0）」の行を置き換えることにより第4のアルゴリズムのいずれかに確保することができます。
:requested_feedback_location pad (1) :requested_feedback_length pad (1) :requested_feedback_field pad (12) :hash_start pad (8)
：requested_feedback_locationパッド（1）：requested_feedback_lengthパッド（1）：requested_feedback_fieldパッド（12）：hash_startパッド（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))
セット（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（requested_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:
「：initialize_memory」ラベル部4の圧縮アルゴリズムのいずれにおいても、静的辞書は、直後に続く命令を挿入することによってアクセスすることができます。
STATE-ACCESS (dictionary_id, 6, 0, 0, 1024, 0)
STATE-ACCESS（dictionary_id、6、0、0、1024 0）
The parameters of STATE-ACCESS instruction will depend on the compression algorithm in use.
STATE-ACCESS命令のパラメータは、使用中の圧縮アルゴリズムに依存します。
The following lines should also be inserted immediately after the END-MESSAGE instruction:
次の行は、END-MESSAGE命令の直後に挿入する必要があります。
: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:
「：end_of_message」ラベルの追加CRCチェックが必要な場合は、次のバイトコードは、後に挿入することができます。
INPUT-BYTES (2, index, !) CRC ($index, 64, state_length, !)
INPUT-BYTES（2、インデックス、！）CRC（$インデックス、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.
バイトコードの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:
これらのフィールドは、アセンブリの以下の部分で「設定（returned_parameters_location、0）」の行を置き換えることにより第4のアルゴリズムのいずれかに確保することができます。
:adverts_len pad (1) :adverts_len_lsb pad (1) :returned_parameters_location pad (1) :returned_sigcomp_version pad (1) :state_ids pad (x)
：adverts_lenパッド（1）：adverts_len_lsbパッド（1）：returned_parameters_locationパッド（1）：returned_sigcomp_versionパッド（1）：state_idsパッド（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、行われる）INPUT-BYTES（$ adverts_len、state_ids、行われ）
: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.
このセクションでは、[3] RFC 3321、SigCompの共有圧縮機構を実装するためのバイトコードを提供します。 2つのエンドポイントAとBはSigCompのを介して通信している場合、共有圧縮がエンドポイントBをエンドポイントAから送信されたメッセージは、エンドポイントA（及びその逆）へのエンドポイントBから送信されたメッセージに対して圧縮されることを可能にします。これは両方向で同一の情報を送信する必要性を低減することによって、全体の圧縮率を向上させることができます。
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.
リチャード価格、カルステンボルマン、アダムローチ、ローレンスコンロイ、クリスチャン・シュミット、マックスリーゲル、ラース・エリックジョンソン、ジョナサン・ローゼンバーグ、ステファンForsgren、クリスターSvanbro、ミゲル・ガルシア、クリストファー・クラントン、Khiemル、カーチョン・レオン、とゾルタンBarczikayのおかげで貴重な入力とレビューのために。
Special thanks to Pekka Pessi and Cristian Constantin, who served as committed working group document reviewers.
コミットワーキンググループ文書の校閲を務めペッカPessiとクリスティアン・コンスタンティン、に感謝します。
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]クロッカー、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]価格、R.、ボルマン、C.、Christoffersson、J.、ハンヌ、H.、劉、Z.、およびJ.ローゼンバーグ、 "シグナリング圧縮（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]ハンヌ、H.、Christoffersson、J.、Forsgren、S.、レオン、K.-C.、劉、Z.、およびR.価格、 "シグナリング圧縮（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]ガルシア - マーチン、M.、ボルマン、C.、オット、J.、価格、R.、およびA.B.ローチ、 "セッション開始プロトコル（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]ジブ、J. A.及びレンペル、 "逐次データ圧縮用の汎用アルゴリズム"、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データ圧縮"、博士ドッブのジャーナル、1989年10月。
[8] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[8]ドイツ、P.、 "DEFLATE圧縮データフォーマット仕様バージョン1.3"、RFC 1951、1996年5月を。
[9] "Data Compression Procedures", ITU-T Recommendation V.44, November 2000.
[9] "データ圧縮手順"、ITU-T勧告V.44、2000年11月。
Appendix A. UDVM Bytecode for the Compression Algorithms
圧縮アルゴリズムのための付録A. UDVMバイトコード
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.
異なるアセンブラが出力アセンブリコードの同じ部分に異なるバイトコードので、有効なアセンブラは以下に示すものとは異なる結果を生成することができることに留意されたいです。ただし、次のバイトコードは常にUDVMに同じ解凍メッセージを生成する必要があります。
A.1. Well-known Algorithms
A.1。周知のアルゴリズム
A.1.1. LZ77
.1.1。 LZH
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 2300 16f5 0x00bf c086 a08b 06
A.1.2. LZSS
A.1.2。 LZSS
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
5116 9fd2 2300 00BFのc086のa089 06 0x2252 0117 508D 0x0f23 0622 2101 1321 0123 16e5 1d04 22e8 0611 030e 2463 1450 5123 BFFF 0x0f86 04a0 c48d 00A0 c41e 2031 0209 00A0 ff8eの048c
A.1.3. LZW
A.1.3。 LZW
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 06 a09f 8f01 a0ce 13a0 4903 2313 2501 2506 1201 1752 0x88f4 079f 681d 0a24 2508 1203 0612 1252 0321 b18f 0ea0 4801 0624 0x5013 a049 0323 1351 5025 2251 5016 2300 9fde 00BFのc086を00B1 ce8d
A.1.4. DEFLATE
A.1.4。 DEFLATE
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 3b04 A043 0x04a0 5304 a063 04a0 7305 A083 05a0 A305 a0c3 05a0 E300のA102 0001 0209 020d 0311 0319 0421 0431 0003 0004 0105 0107 0×0002 05a0 4105 0xa061 06a0 8106 a0c1 07a1 0107 A181 08a2 0108 A301 09a4 0109 A601 0x0aa8 010A AC01 0bb0 010B B801の0c80 0c80 3001 0d80 4001 2001 0d80 0x6001 1d03 229f b41e 20a0 6504 0700 1780 4011 0130 0000 a0c0 0xa0c7 8040 2901 A190 a0bf A090 1750 8040 1109 a1ff 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 06 a1de
A.1.5. LZJH
A.1.5。 LZJH
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
A15B 0706 0x0f86 08a1 5b8d 0700 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 9fa8 1e24 9fb1 0401 0101 0102 0103 0201 0x0101 0d03 0007 0517 520D 0d06 061d 0826 a047 0x0327 1351 5024 2251 5016 6713 F706 9fdb 070f 1C00 009e 0xce16 9f57 1d01 24fa 1752 0107 0d9eのC206 2501 1225 0154 169f 6617 5201 1253 1351 5011 1351 0x5224 2251 5206 1250 169f 6506 2601 169f 0x7623 0000 BFC0 86a0 8e06
A.2. Adapted Algorithms
A.2。適応アルゴリズム
A.2.1. Modified DEFLATE
A.2.1。変更されたDEFLATE
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 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 9080 807f 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 0000 3b23 BFC0 86a0 8906 169f
Authors' Addresses
著者のアドレス
Abigail Surtees Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
アビゲイルサーティースシーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国
Phone: +44 (0)1794 833131 EMail: abigail.surtees@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833131 Eメール：URI abigail.surtees@roke.co.uk：http://www.roke.co.uk
Mark A. West Siemens/Roke Manor Research Roke Manor Research Ltd. Romsey, Hants SO51 0ZN UK
マーク・A.西シーメンス/ Rokeマナー研究Rokeマナーリサーチ株式会社ロムジー、ハンツSO51 0ZN英国
Phone: +44 (0)1794 833311 EMail: mark.a.west@roke.co.uk URI: http://www.roke.co.uk
電話：+44（0）1794 833311 Eメール：mark.a.west@roke.co.uk URI：http://www.roke.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。