Network Working Group M. Eisler, Ed.
Request for Comments: 4506 Network Appliance, Inc.
STD: 67 May 2006
Obsoletes: 1832
Category: Standards Track
XDR: External Data Representation Standard
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832.
この文書は、それが現在展開して受け入れられているよう外部データ表現標準（XDR）プロトコルを記述しています。この文書はRFC 1832を廃止します。
Table of Contents
目次
1. Introduction ....................................................3
2. Changes from RFC 1832 ...........................................3
3. Basic Block Size ................................................3
4. XDR Data Types ..................................................4
4.1. Integer ....................................................4
4.2. Unsigned Integer ...........................................4
4.3. Enumeration ................................................5
4.4. Boolean ....................................................5
4.5. Hyper Integer and Unsigned Hyper Integer ...................5
4.6. Floating-Point .............................................6
4.7. Double-Precision Floating-Point ............................7
4.8. Quadruple-Precision Floating-Point .........................8
4.9. Fixed-Length Opaque Data ...................................9
4.10. Variable-Length Opaque Data ...............................9
4.11. String ...................................................10
4.12. Fixed-Length Array .......................................11
4.13. Variable-Length Array ....................................11
4.14. Structure ................................................12
4.15. Discriminated Union ......................................12
4.16. Void .....................................................13
4.17. Constant .................................................13
4.18. Typedef ..................................................13
4.19. Optional-Data ............................................14
4.20. Areas for Future Enhancement .............................16
5. Discussion .....................................................16
6. The XDR Language Specification .................................17
6.1. Notational Conventions ....................................17
6.2. Lexical Notes .............................................18
6.3. Syntax Information ........................................18
6.4. Syntax Notes ..............................................20
7. An Example of an XDR Data Description ..........................21
8. Security Considerations ........................................22
9. IANA Considerations ............................................23
10. Trademarks and Owners .........................................23
11. ANSI/IEEE Standard 754-1985 ...................................24
12. Normative References ..........................................25
13. Informative References ........................................25
14. Acknowledgements ..............................................26
XDR is a standard for the description and encoding of data. It is useful for transferring data between different computer architectures, and it has been used to communicate data between such diverse machines as the SUN WORKSTATION*, VAX*, IBM-PC*, and Cray*. XDR fits into the ISO presentation layer and is roughly analogous in purpose to X.409, ISO Abstract Syntax Notation. The major difference between these two is that XDR uses implicit typing, while X.409 uses explicit typing.
XDRは、データの記述および符号化の標準です。これは、異なるコンピュータアーキテクチャ間でデータを転送するために有用であり、SUNワークステーション*、VAX *、IBM-PC *、およびクレイ*など、さまざまな機器との間でデータを通信するために使用されてきました。 XDRはISOプレゼンテーション層に収まるとX.409に、ISO抽象構文記法目的で大体似ています。これら二つの間の主な違いは、X.409は明示的な型を使用しつつ、XDRは、暗黙の型を使用することです。
XDR uses a language to describe data formats. The language can be used only to describe data; it is not a programming language. This language allows one to describe intricate data formats in a concise manner. The alternative of using graphical representations (itself an informal language) quickly becomes incomprehensible when faced with complexity. The XDR language itself is similar to the C language [KERN], just as Courier [COUR] is similar to Mesa. Protocols such as ONC RPC (Remote Procedure Call) and the NFS* (Network File System) use XDR to describe the format of their data.
XDRは、データ形式を記述するための言語を使用しています。言語は、データを記述するためにのみ使用することができます。それは、プログラミング言語ではありません。この言語は、1つの簡潔な方法で複雑なデータ形式を記述することができます。複雑さに直面したときのグラフィック表現を使用することの別の（それ自体非公式言語）を素早く理解不能となります。 XDR言語自体は、クーリエ[COUR]はメサと類似しているだけのように、C言語[カーン]と同様です。このようONC RPC（リモートプロシージャコール）とNFS *（ネットワークファイルシステム）などのプロトコルは、データのフォーマットを記述するためにXDRを使用しています。
The XDR standard makes the following assumption: that bytes (or octets) are portable, where a byte is defined as 8 bits of data. A given hardware device should encode the bytes onto the various media in such a way that other hardware devices may decode the bytes without loss of meaning. For example, the Ethernet* standard suggests that bytes be encoded in "little-endian" style [COHE], or least significant bit first.
バイト（オクテット）がポータブルであること、バイトが8ビットのデータとして定義される：XDR規格は、以下の仮定を行います。特定のハードウェアデバイスは、他のハードウェアデバイスが意味を失うことなくバイトを復号することができるように、様々なメディアにバイトを符号化すべきです。例えば、イーサネット*標準は、バイトが最初の「リトルエンディアン」スタイル[COHE]、または最下位ビットで符号化されることを示唆しています。
This document makes no technical changes to RFC 1832 and is published for the purposes of noting IANA considerations, augmenting security considerations, and distinguishing normative from informative references.
この文書は、RFC 1832への技術的な変更を行わず、、IANAの考慮事項に留意し、セキュリティ上の考慮事項を増強し、有益な参考文献から規範を区別する目的のために公開されています。
The representation of all items requires a multiple of four bytes (or 32 bits) of data. The bytes are numbered 0 through n-1. The bytes are read or written to some byte stream such that byte m always precedes byte m+1. If the n bytes needed to contain the data are not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of 4.
すべての項目の表示は、データの4バイト（又は32ビット）の倍数を必要とします。バイトは、n-1を介して0に番号が付けられています。バイトは、バイトmは常にバイトM + 1に先行するようないくつかのバイトストリームに読み書きされます。データを含むために必要なnバイトが4の倍数でない場合、nバイトは、全バイトが4の倍数をカウントするために、残留（0〜3）十分にゼロバイト、R、が続きます。
We include the familiar graphic box notation for illustration and comparison. In most illustrations, each box (delimited by a plus sign at the 4 corners and vertical bars and dashes) depicts a byte.
我々は、説明と比較のためにおなじみのグラフィックボックスの表記が含まれています。ほとんどのイラストでは、（4つのコーナーと垂直バーとダッシュでプラス記号で区切ら）各ボックスには、バイトを示します。
Ellipses (...) between boxes show zero or more additional bytes where required.
ボックスの間の省略記号（...）は、必要なゼロまたはそれ以上の追加のバイトを示しています。
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 | BLOCK
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)>----------->|
Each of the sections that follow describes a data type defined in the XDR standard, shows how it is declared in the language, and includes a graphic illustration of its encoding.
XDR規格で定義されたデータタイプを記述する次のセクションのそれぞれは、それが言語で宣言されている方法を示し、その符号化のグラフ表示を含みます。
For each data type in the language we show a general paradigm declaration. Note that angle brackets (< and >) denote variable-length sequences of data and that square brackets ([ and ]) denote fixed-length sequences of data. "n", "m", and "r" denote integers. For the full language specification and more formal definitions of terms such as "identifier" and "declaration", refer to Section 6, "The XDR Language Specification".
言語の各データ・タイプのために我々は、一般的なパラダイムの宣言を示しています。データの固定長配列を示す（<と>）は角括弧に注意して、データとその角括弧の可変長配列を示す（[と]）。 "N"、 "M"、及び "R" の整数を表します。完全な言語仕様や、「識別子」と「宣言」などの用語のより正式な定義については、第6章、「XDR言語仕様」を参照。
For some data types, more specific examples are included. A more extensive example of a data description is in Section 7, "An Example of an XDR Data Description".
一部のデータ型について、より具体的な例が含まれています。データ記述のより広範な例は、第7章の「XDRデータ記述の例」です。
An XDR signed integer is a 32-bit datum that encodes an integer in the range [-2147483648,2147483647]. The integer is represented in two's complement notation. The most and least significant bytes are 0 and 3, respectively. Integers are declared as follows:
XDR符号付き整数【-2147483648,2147483647]の範囲内の整数を符号化する32ビットデータです。整数は、2の補数で表現されます。最も最下位バイトは、それぞれ、0および3です。次のように整数は宣言されています：
int identifier;
識別値int;
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
An XDR unsigned integer is a 32-bit datum that encodes a non-negative integer in the range [0,4294967295]. It is represented by an unsigned binary number whose most and least significant bytes are 0 and 3, respectively. An unsigned integer is declared as follows:
XDR符号なし整数[0,4294967295]範囲内の負でない整数を符号化する32ビットデータです。それは、その最も最下位バイトはそれぞれ、0及び3である符号なし2進数で表されます。次のように符号なし整数が宣言されています：
unsigned int identifier;
unsigned int型の識別子。
(MSB) (LSB)
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | UNSIGNED INTEGER
+-------+-------+-------+-------+
<------------32 bits------------>
Enumerations have the same representation as signed integers. Enumerations are handy for describing subsets of the integers. Enumerated data is declared as follows:
列挙型は、符号付き整数と同じ表現を持ちます。列挙型は、整数のサブセットを記述するのに便利です。列挙型は次のように宣言されています。
enum { name-identifier = constant, ... } identifier;
列挙{名前、識別子=定数、...}識別子。
For example, the three colors red, yellow, and blue could be described by an enumerated type:
例えば、赤、黄、青の3色列挙型によって記述することができます。
enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;
列挙{RED = 2、YELLOW = 3、BLUE = 5}色。
It is an error to encode as an enum any integer other than those that have been given assignments in the enum declaration.
列挙として列挙宣言で割り当てを与えられているもの以外の任意の整数を符号化するエラーです。
Booleans are important enough and occur frequently enough to warrant their own explicit type in the standard. Booleans are declared as follows:
ブールは十分に重要であり、標準で独自の明示的な型を正当化するのに十分な頻度で起こります。次のようにブール値が宣言されています：
bool identifier;
ブール識別子。
This is equivalent to:
これはと同等です。
enum { FALSE = 0, TRUE = 1 } identifier;
列挙{FALSE = 0、TRUE = 1}識別子。
The standard also defines 64-bit (8-byte) numbers called hyper integers and unsigned hyper integers. Their representations are the obvious extensions of integer and unsigned integer defined above. They are represented in two's complement notation. The most and least significant bytes are 0 and 7, respectively. Their declarations:
標準はまた、ハイパー整数と符号なし整数ハイパーと呼ばれる64ビット（8バイト）の数を定義します。彼らの表現は、整数および上記で定義された符号なし整数の明白な拡張です。これらは、2の補数で表されます。最も最下位バイトは、それぞれ、0と7です。彼らの宣言：
hyper identifier; unsigned hyper identifier;
ハイパー識別子;符号なしのハイパー識別子。
(MSB) (LSB)
+-------+-------+-------+-------+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 |byte 4 |byte 5 |byte 6 |byte 7 |
+-------+-------+-------+-------+-------+-------+-------+-------+
<----------------------------64 bits---------------------------->
HYPER INTEGER
UNSIGNED HYPER INTEGER
The standard defines the floating-point data type "float" (32 bits or 4 bytes). The encoding used is the IEEE standard for normalized single-precision floating-point numbers [IEEE]. The following three fields describe the single-precision floating-point number:
標準は、浮動小数点データ・タイプ「フロート」（32ビットまたは4バイト）を定義します。使用される符号化は[IEEE]正規化された単精度浮動小数点数のためのIEEE規格です。次の3つのフィールドは、単精度浮動小数点数を記述する。
S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit.
S：数値の符号。値0と1は、それぞれ、正および負表します。 1ビット。
E: The exponent of the number, base 2. 8 bits are devoted to this field. The exponent is biased by 127.
E：数値の指数、ベース2の8ビットがこの分野に専念しています。指数は127でバイアスされています。
F: The fractional part of the number's mantissa, base 2. 23 bits are devoted to this field.
F：数値の仮数の小数部分、ベース2の23ビットは、この分野に専念しています。
Therefore, the floating-point number is described by:
したがって、浮動小数点数は、によって記述されます。
(-1)**S * 2**(E-Bias) * 1.F
（-1）** S * 2 **（E-バイアス）* 1.F
It is declared as follows:
これは次のように宣言されます。
float identifier;
フロート識別子。
+-------+-------+-------+-------+
|byte 0 |byte 1 |byte 2 |byte 3 | SINGLE-PRECISION
S| E | F | FLOATING-POINT NUMBER
+-------+-------+-------+-------+
1|<- 8 ->|<-------23 bits------>|
<------------32 bits------------>
Just as the most and least significant bytes of a number are 0 and 3, the most and least significant bits of a single-precision floating-point number are 0 and 31. The beginning bit (and most significant bit) offsets of S, E, and F are 0, 1, and 9, respectively. Note that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
数の最も最下位バイトは、単精度浮動小数点数の最もおよび最下位ビットはSの開始ビット（最上位ビット）のオフセットは、E 0及び31 0,3されているのと同じように、及びFは、それぞれ、0,1、および9です。これらの数字はビットの数学的な位置に、及びNOT（培地に培地から変化）実際の物理的な位置を指すことに留意されたいです。
The IEEE specifications should be consulted concerning the encoding for signed zero, signed infinity (overflow), and denormalized numbers (underflow) [IEEE]. According to IEEE specifications, the "NaN" (not a number) is system dependent and should not be interpreted within XDR as anything other than "NaN".
IEEE仕様は、署名されたゼロの符号化に関する相談すべきである、[IEEE]無限大（オーバーフロー）を署名した、と数字（アンダーフロー）非正規化。 IEEE仕様に従って、「のNaN」（非数）に依存するシステムであり、「のNaN」以外としてXDR内で解釈されるべきではありません。
The standard defines the encoding for the double-precision floating-point data type "double" (64 bits or 8 bytes). The encoding used is the IEEE standard for normalized double-precision floating-point numbers [IEEE]. The standard encodes the following three fields, which describe the double-precision floating-point number:
標準は、倍精度浮動小数点データ・タイプ「ダブル」（64ビットまたは8バイト）のための符号化を定義します。使用される符号化は[IEEE]正規化された倍精度浮動小数点数のためのIEEE規格です。標準は、倍精度浮動小数点数を記述する次の3つのフィールドをコードします：
S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit.
S：数値の符号。値0と1は、それぞれ、正および負表します。 1ビット。
E: The exponent of the number, base 2. 11 bits are devoted to this field. The exponent is biased by 1023.
E：数値の指数、ベース2の11ビットは、この分野に専念しています。指数は1023でバイアスされています。
F: The fractional part of the number's mantissa, base 2. 52 bits are devoted to this field.
F：数値の仮数の小数部分、ベース2 52ビットは、この分野に専念しています。
Therefore, the floating-point number is described by:
したがって、浮動小数点数は、によって記述されます。
(-1)**S * 2**(E-Bias) * 1.F
（-1）** S * 2 **（E-バイアス）* 1.F
It is declared as follows:
これは次のように宣言されます。
double identifier;
ダブル識別する。
+------+------+------+------+------+------+------+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5|byte 6|byte 7|
S| E | F |
+------+------+------+------+------+------+------+------+
1|<--11-->|<-----------------52 bits------------------->|
<-----------------------64 bits------------------------->
DOUBLE-PRECISION FLOATING-POINT
Just as the most and least significant bytes of a number are 0 and 3, the most and least significant bits of a double-precision floating-point number are 0 and 63. The beginning bit (and most significant bit) offsets of S, E, and F are 0, 1, and 12, respectively. Note that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
数の最も最下位バイトは、倍精度浮動小数点数の最もおよび最下位ビットはSの開始ビット（最上位ビット）のオフセットは、E 0及び63 0,3されているのと同じように、及びFは、それぞれ、0,1、および12です。これらの数字はビットの数学的な位置に、及びNOT（培地に培地から変化）実際の物理的な位置を指すことに留意されたいです。
The IEEE specifications should be consulted concerning the encoding for signed zero, signed infinity (overflow), and denormalized numbers (underflow) [IEEE]. According to IEEE specifications, the "NaN" (not a number) is system dependent and should not be interpreted within XDR as anything other than "NaN".
IEEE仕様は、署名されたゼロの符号化に関する相談すべきである、[IEEE]無限大（オーバーフロー）を署名した、と数字（アンダーフロー）非正規化。 IEEE仕様に従って、「のNaN」（非数）に依存するシステムであり、「のNaN」以外としてXDR内で解釈されるべきではありません。
The standard defines the encoding for the quadruple-precision floating-point data type "quadruple" (128 bits or 16 bytes). The encoding used is designed to be a simple analog of the encoding used for single- and double-precision floating-point numbers using one form of IEEE double extended precision. The standard encodes the following three fields, which describe the quadruple-precision floating-point number:
標準は、4倍精度浮動小数点データ・タイプ「四」（128ビット又は16バイト）のための符号化を定義します。使用されるエンコーディングは、IEEE拡張倍精度の一の形態を使用して、単一および倍精度浮動小数点数のために使用される符号化の単純なアナログであるように設計されています。標準は、4倍精度浮動小数点数を記述する次の3つのフィールドをコードします：
S: The sign of the number. Values 0 and 1 represent positive and negative, respectively. One bit.
S：数値の符号。値0と1は、それぞれ、正および負表します。 1ビット。
E: The exponent of the number, base 2. 15 bits are devoted to this field. The exponent is biased by 16383.
E：数値の指数、ベース2の15ビットは、この分野に専念しています。指数は16383によってバイアスされています。
F: The fractional part of the number's mantissa, base 2. 112 bits are devoted to this field.
F：数値の仮数の小数部分、基部2の112ビットは、この分野に専念しています。
Therefore, the floating-point number is described by:
したがって、浮動小数点数は、によって記述されます。
(-1)**S * 2**(E-Bias) * 1.F
（-1）** S * 2 **（E-バイアス）* 1.F
It is declared as follows:
これは次のように宣言されます。
quadruple identifier;
四特定します。
+------+------+------+------+------+------+-...--+------+
|byte 0|byte 1|byte 2|byte 3|byte 4|byte 5| ... |byte15|
S| E | F |
+------+------+------+------+------+------+-...--+------+
1|<----15---->|<-------------112 bits------------------>|
<-----------------------128 bits------------------------>
QUADRUPLE-PRECISION FLOATING-POINT
Just as the most and least significant bytes of a number are 0 and 3, the most and least significant bits of a quadruple-precision floating-point number are 0 and 127. The beginning bit (and most significant bit) offsets of S, E , and F are 0, 1, and 16, respectively. Note that these numbers refer to the mathematical positions of the bits, and NOT to their actual physical locations (which vary from medium to medium).
数の最も最下位バイトは、4倍精度浮動小数点数の最もおよび最下位ビットはSの開始ビット（最上位ビット）のオフセットは、E 0および127 0と3されているのと同じように、及びFは、それぞれ、0,1、および16です。これらの数字はビットの数学的な位置に、及びNOT（培地に培地から変化）実際の物理的な位置を指すことに留意されたいです。
The encoding for signed zero, signed infinity (overflow), and denormalized numbers are analogs of the corresponding encodings for single and double-precision floating-point numbers [SPAR], [HPRE]. The "NaN" encoding as it applies to quadruple-precision floating-point numbers is system dependent and should not be interpreted within XDR as anything other than "NaN".
ゼロの符号付きの符号化、符号付き無限大（オーバーフロー）、及び[HPRE]、数字は単精度および倍精度浮動小数点数[SPAR]のための対応するエンコーディングの類似体である非正規化。 「はNaN」符号化は4倍精度浮動小数点数に適用されるシステムに依存し、「のNaN」以外としてXDR内で解釈されるべきではありません。
At times, fixed-length uninterpreted data needs to be passed among machines. This data is called "opaque" and is declared as follows:
時には、解釈しない固定長データをマシン間で受け渡さなければなりません。このデータは、「不透明」と呼ばれ、次のように宣言されています。
opaque identifier[n];
不透明な識別子[N]。
where the constant n is the (static) number of bytes necessary to contain the opaque data. If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count of the opaque object a multiple of four.
ここで、定数nは、隠されたデータを含むのに必要なバイトの（静的な）数です。 nが4の倍数でない場合、nバイトは、不透明オブジェクトの総バイト数が4の倍数にするために、R（0〜3）十分な残留ゼロバイトが続きます。
0 1 ...
+--------+--------+...+--------+--------+...+--------+
| byte 0 | byte 1 |...|byte n-1| 0 |...| 0 |
+--------+--------+...+--------+--------+...+--------+
|<-----------n bytes---------->|<------r bytes------>|
|<-----------n+r (where (n+r) mod 4 = 0)------------>|
FIXED-LENGTH OPAQUE
The standard also provides for variable-length (counted) opaque data, defined as a sequence of n (numbered 0 through n-1) arbitrary bytes to be the number n encoded as an unsigned integer (as described below), and followed by the n bytes of the sequence.
標準はまた、数N（以下で説明するように）符号なし整数として符号化されるn個のシーケンスとして定義される（カウント）不透明なデータは、（N-1まで番号0）可変長のための任意のバイトを提供し、続いてシーケンスのnバイト。
Byte m of the sequence always precedes byte m+1 of the sequence, and byte 0 of the sequence always follows the sequence's length (count). If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four. Variable-length opaque data is declared in the following way:
シーケンスのバイトmはいつも、常にシーケンスの長さ（カウント）次のバイトシーケンスのM + 1、およびシーケンスのバイト0先行します。 nが4の倍数でない場合、nバイトは、全バイトは4の倍数をカウントするために、（0〜3）十分な残留ゼロバイト、Rが続きます。可変長の不透明データは、次のように宣言されています：
opaque identifier<m>;
or
opaque identifier<>;
The constant m denotes an upper bound of the number of bytes that the sequence may contain. If m is not specified, as in the second declaration, it is assumed to be (2**32) - 1, the maximum length.
定数mは、シーケンスが含まれていてもよいバイト数の上限を示しています。 1、最大長さ - mは2番目の宣言のように、指定されていない場合は、（2 ** 32）であると仮定されます。
The constant m would normally be found in a protocol specification. For example, a filing protocol may state that the maximum data transfer size is 8192 bytes, as follows:
定数mは、通常、プロトコル仕様に見出されるであろう。たとえば、ファイリングプロトコルは、以下のように最大データ転送サイズは、8192バイトであることを述べることができます。
opaque filedata<8192>;
不透明なFILEDATA <8192>。
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
VARIABLE-LENGTH OPAQUE
It is an error to encode a length greater than the maximum described in the specification.
なお、明細書に記載の最大値よりも大きい長さを符号化するエラーです。
The standard defines a string of n (numbered 0 through n-1) ASCII bytes to be the number n encoded as an unsigned integer (as described above), and followed by the n bytes of the string. Byte m of the string always precedes byte m+1 of the string, and byte 0 of the string always follows the string's length. If n is not a multiple of four, then the n bytes are followed by enough (0 to 3) residual zero bytes, r, to make the total byte count a multiple of four. Counted byte strings are declared as follows:
標準は、（N-1まで番号0）、nの文字列を定義するASCIIは、（上記のように）符号なし整数として数nは符号化されるバイト、文字列のnバイトが続きます。文字列のバイトmは常に文字列のバイトM + 1に先行し、文字列のバイト0は常に文字列の長さを次の。 nが4の倍数でない場合、nバイトは、全バイトは4の倍数をカウントするために、（0〜3）十分な残留ゼロバイト、Rが続きます。次のようにカウントされたバイト文字列が宣言されています：
string object<m>;
or
string object<>;
The constant m denotes an upper bound of the number of bytes that a string may contain. If m is not specified, as in the second declaration, it is assumed to be (2**32) - 1, the maximum length. The constant m would normally be found in a protocol specification. For example, a filing protocol may state that a file name can be no longer than 255 bytes, as follows:
定数mは、文字列が含まれていてもよいバイト数の上限を示しています。 1、最大長さ - mは2番目の宣言のように、指定されていない場合は、（2 ** 32）であると仮定されます。定数mは、通常、プロトコル仕様に見出されるであろう。例えば、ファイリングプロトコルは、次のようにファイル名が、もはや255バイトを超えることができることを述べるないことがあります。
string filename<255>;
文字列filename <255>。
0 1 2 3 4 5 ...
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
| length n |byte0|byte1|...| n-1 | 0 |...| 0 |
+-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
|<-------4 bytes------->|<------n bytes------>|<---r bytes--->|
|<----n+r (where (n+r) mod 4 = 0)---->|
STRING
It is an error to encode a length greater than the maximum described in the specification.
なお、明細書に記載の最大値よりも大きい長さを符号化するエラーです。
Declarations for fixed-length arrays of homogeneous elements are in the following form:
均質要素の固定長配列の宣言は、以下の形式は以下のとおりです。
type-name identifier[n];
型名識別子[N]。
Fixed-length arrays of elements numbered 0 through n-1 are encoded by individually encoding the elements of the array in their natural order, 0 through n-1. Each element's size is a multiple of four bytes. Though all elements are of the same type, the elements may have different sizes. For example, in a fixed-length array of strings, all elements are of type "string", yet each element will vary in its length.
要素の固定長配列は、0からn-1を介して個々にその自然な順序で配列の要素を符号化して符号化されるn-1個の0〜番号。各要素のサイズは4バイトの倍数です。すべての要素が同じ型であるが、構成要素は、異なるサイズを有することができます。例えば、文字列の固定長配列では、すべての要素がタイプ「文字列」のもので、まだ各要素は、その長さが変化することになります。
+---+---+---+---+---+---+---+---+...+---+---+---+---+
| element 0 | element 1 |...| element n-1 |
+---+---+---+---+---+---+---+---+...+---+---+---+---+
|<--------------------n elements------------------->|
FIXED-LENGTH ARRAY
固定長配列
Counted arrays provide the ability to encode variable-length arrays of homogeneous elements. The array is encoded as the element count n (an unsigned integer) followed by the encoding of each of the array's elements, starting with element 0 and progressing through element n-1. The declaration for variable-length arrays follows this form:
計数アレイは、均質要素の可変長配列をコードする能力を提供します。アレイは、アレイの各要素の符号化に続く要素数n（符号なし整数）としてエンコードされ、要素0から始まり、要素のn-1を介して進行します。可変長配列の宣言は、このフォームを、以下：
type-name identifier<m>;
or
type-name identifier<>;
The constant m specifies the maximum acceptable element count of an array; if m is not specified, as in the second declaration, it is assumed to be (2**32) - 1.
定数mは、アレイの最大許容要素数を指定します。 mは2番目の宣言のように、指定されていない場合、（2 ** 32）であると仮定されている - 1。
0 1 2 3
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
| n | element 0 | element 1 |...|element n-1|
+--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
|<-4 bytes->|<--------------n elements------------->|
COUNTED ARRAY
It is an error to encode a value of n that is greater than the maximum described in the specification.
なお、明細書に記載の最大値よりも大きいnの値を符号化するエラーです。
Structures are declared as follows:
構造体は次のように宣言されています。
struct {
component-declaration-A;
component-declaration-B;
...
} identifier;
The components of the structure are encoded in the order of their declaration in the structure. Each component's size is a multiple of four bytes, though the components may be different sizes.
構造体の構成要素は、構造中のそれらの宣言の順序で符号化されます。構成要素は異なるサイズであってもよいけれども、各コンポーネントのサイズは、4バイトの倍数です。
+-------------+-------------+...
| component A | component B |... STRUCTURE
+-------------+-------------+...
A discriminated union is a type composed of a discriminant followed by a type selected from a set of prearranged types according to the value of the discriminant. The type of discriminant is either "int", "unsigned int", or an enumerated type, such as "bool". The component types are called "arms" of the union and are preceded by the value of the discriminant that implies their encoding. Discriminated unions are declared as follows:
判別共用体は、判別式の値に応じて事前に決められたタイプのセットから選択されたタイプ続い判別からなるタイプです。判別式のタイプは、「INT」、「unsigned int型」、または「ブール」として列挙型、のいずれかです。コンポーネントタイプは、組合の「アーム」と呼ばれ、その符号化を意味判別式の値が先行します。次のように区別組合が宣言されています：
union switch (discriminant-declaration) {
case discriminant-value-A:
arm-declaration-A;
case discriminant-value-B:
arm-declaration-B;
...
default: default-declaration;
} identifier;
Each "case" keyword is followed by a legal value of the discriminant. The default arm is optional. If it is not specified, then a valid encoding of the union cannot take on unspecified discriminant values. The size of the implied arm is always a multiple of four bytes.
各「ケース」のキーワードは、判別式の正当な値が続いています。デフォルトのアームはオプションです。それが指定されていない場合には、労働組合の正当なエンコーディングが指定されていない判別式の値を取ることができません。アームのサイズは4バイトの倍数です。
The discriminated union is encoded as its discriminant followed by the encoding of the implied arm.
判別共用体は、暗黙のアームの符号化に続いて、その判別式として符号化されます。
0 1 2 3
+---+---+---+---+---+---+---+---+
| discriminant | implied arm | DISCRIMINATED UNION
+---+---+---+---+---+---+---+---+
|<---4 bytes--->|
An XDR void is a 0-byte quantity. Voids are useful for describing operations that take no data as input or no data as output. They are also useful in unions, where some arms may contain data and others do not. The declaration is simply as follows:
XDRボイドは0バイトの量です。ボイドは、入力としてデータや出力などのないデータを取得しない動作を説明するために有用です。彼らはまた、いくつかの腕がデータを含むことができ、他にはない組合において有用です。次のように宣言は、単純です：
void;
無効;
Voids are illustrated as follows:
次のようにボイドが示されています：
++
|| VOID
++
--><-- 0 bytes
The data declaration for a constant follows this form:
定数のデータ宣言は、このフォームを、次のとおりです。
const name-identifier = n;
CONST名識別子= N。
"const" is used to define a symbolic name for a constant; it does not declare any data. The symbolic constant may be used anywhere a regular constant may be used. For example, the following defines a symbolic constant DOZEN, equal to 12.
「CONSTは、」定数の記号名を定義するのに使用されます。それは、すべてのデータを宣言していません。シンボリック定数はどこでも使用することができる通常の定数を使用することができます。例えば、以下は12に等しいシンボル定数DOZENを定義します。
const DOZEN = 12;
CONST DOZEN = 12。
"typedef" does not declare any data either, but serves to define new identifiers for declaring data. The syntax is:
「typedefが」どちらか任意のデータを宣言しますが、データを宣言するための新しい識別子を定義するのに役立つものではありません。構文は次のとおりです。
typedef declaration;
typedefを宣言。
The new type name is actually the variable name in the declaration part of the typedef. For example, the following defines a new type called "eggbox" using an existing type called "egg":
新しいタイプの名前は、実際のtypedefの宣言部分の変数名です。例えば、以下は「卵」と呼ばれる既存の型を使用して「eggbox」と呼ばれる新しいタイプを定義します。
typedef egg eggbox[DOZEN];
typedefの卵eggbox [DOZEN]。
Variables declared using the new type name have the same type as the new type name would have in the typedef, if it were considered a variable. For example, the following two declarations are equivalent in declaring the variable "fresheggs":
変数は、変数と見なされた場合は、新しいタイプの名前は、typedefの中に持っているものと同じタイプを持つ新しいタイプの名前を使用して宣言しました。たとえば、以下の2つの宣言は、変数「fresheggs」を宣言に等価です。
eggbox fresheggs; egg fresheggs[DOZEN];
卵の箱新鮮な卵。卵新鮮な卵[DOZEN]。
When a typedef involves a struct, enum, or union definition, there is another (preferred) syntax that may be used to define the same type. In general, a typedef of the following form:
typedefは構造体、列挙、または共用定義を含む場合、同じタイプを定義するために使用することができる別の（好適な）シンタックスがあります。一般的には、次の形式のtypedefは：
typedef <<struct, union, or enum definition>> identifier;
typedef <<構造体、共用体、または列挙型の定義>>識別子。
may be converted to the alternative form by removing the "typedef" part and placing the identifier after the "struct", "union", or "enum" keyword, instead of at the end. For example, here are the two ways to define the type "bool":
「typedefの」一部を除去し、代わりの終了時に、「構造体」、「ユニオン」、または「列挙」キーワードの後に識別子を配置することによって、別の形に変換することができます。例えば、ここではタイプ「ブール」を定義する2つの方法があります：
typedef enum { /* using typedef */
FALSE = 0,
TRUE = 1
} bool;
enum bool { /* preferred alternative */
FALSE = 0,
TRUE = 1
};
This syntax is preferred because one does not have to wait until the end of a declaration to figure out the name of the new type.
1は新しいタイプの名前を把握するために、宣言の終わりまで待つ必要がないため、この構文が好ましいです。
Optional-data is one kind of union that occurs so frequently that we give it a special syntax of its own for declaring it. It is declared as follows:
オプションのデータはそう頻繁に私達はそれにそれを宣言するための独自の特別な構文を与えることが発生組合の一種です。これは次のように宣言されます。
type-name *identifier;
型名*識別子。
This is equivalent to the following union:
これは、次の労働組合と同等です。
union switch (bool opted) {
case TRUE:
type-name element;
case FALSE:
void;
} identifier;
It is also equivalent to the following variable-length array declaration, since the boolean "opted" can be interpreted as the length of the array:
ブール配列の長さと解釈することができる「オプトイン」ので、それは、また、以下の可変長配列宣言と等価です。
type-name identifier<1>;
型名識別子<1>。
Optional-data is not so interesting in itself, but it is very useful for describing recursive data-structures such as linked-lists and trees. For example, the following defines a type "stringlist" that encodes lists of zero or more arbitrary length strings:
オプションのデータは、それ自体にはそれほど興味深いものではありませんが、それは、このようなリンクされたリストやツリーなどの再帰的なデータ構造を記述するために非常に有用です。例えば、以下はゼロ以上の任意の長さの文字列のリストをコードタイプ「STRINGLIST」を定義しています。
struct stringentry {
string item<>;
stringentry *next;
};
typedef stringentry *stringlist;
stringentryのtypedef * STRINGLIST。
It could have been equivalently declared as the following union:
これは、同等以下の労働組合として宣言されている可能性が：
union stringlist switch (bool opted) {
case TRUE:
struct {
string item<>;
stringlist next;
} element;
case FALSE:
void;
};
or as a variable-length array:
または可変長配列として：
struct stringentry {
string item<>;
stringentry next<1>;
};
typedef stringentry stringlist<1>;
typedefのstringentry STRINGLIST <1>;
Both of these declarations obscure the intention of the stringlist type, so the optional-data declaration is preferred over both of them. The optional-data type also has a close correlation to how recursive data structures are represented in high-level languages such as Pascal or C by use of pointers. In fact, the syntax is the same as that of the C language for pointers.
オプションのデータ宣言がそれらの双方よりも好ましいように、これらの宣言の両方が、STRINGLISTタイプの意図を不明瞭。オプションのデータ型は、データ構造は、ポインタを使用することによって、そのようなPascalやC等の高水準言語で表現されている方法を再帰的に密接な相関関係を有しています。実際には、構文は、ポインタのためのC言語の場合と同様です。
The XDR standard lacks representations for bit fields and bitmaps, since the standard is based on bytes. Also missing are packed (or binary-coded) decimals.
標準は、バイトに基づいているので、XDR規格は、ビットフィールドおよびビットマップの表現を欠いています。また、行方不明は、パック（またはバイナリコード化された）小数されています。
The intent of the XDR standard was not to describe every kind of data that people have ever sent or will ever want to send from machine to machine. Rather, it only describes the most commonly used data-types of high-level languages such as Pascal or C so that applications written in these languages will be able to communicate easily over some medium.
XDR標準の目的は、人々がこれまでに送信したか、これまでに、マシンから送信することになるでしょうデータのすべての種類を記述することはなかったです。これらの言語で書かれたアプリケーションは、いくつかの媒体を介して容易に通信することができるであろうように、むしろ、それだけでこのようなPascalやC等の高水準言語の最も一般的に使用されるデータ型を記述する。
One could imagine extensions to XDR that would let it describe almost any existing protocol, such as TCP. The minimum necessary for this is support for different block sizes and byte-orders. The XDR discussed here could then be considered the 4-byte big-endian member of a larger XDR family.
一つは、TCPのようなほぼすべての既存のプロトコルを記述聞かせXDRへの拡張を想像できます。このために必要な最小値は異なるブロックサイズとバイトオーダーのサポートです。ここで説明XDRは、より大きなXDRファミリーの4バイトのビッグエンディアンのメンバーと考えることができます。
(1) Why use a language for describing data? What's wrong with diagrams?
（1）なぜデータを記述するための言語を使用するのか？何がダイアグラムが悪いですの？
There are many advantages in using a data-description language such as XDR versus using diagrams. Languages are more formal than diagrams and lead to less ambiguous descriptions of data. Languages are also easier to understand and allow one to think of other issues instead of the low-level details of bit encoding. Also, there is a close analogy between the types of XDR and a high-level language such as C or Pascal. This makes the implementation of XDR encoding and decoding modules an easier task. Finally, the language specification itself is an ASCII string that can be passed from machine to machine to perform on-the-fly data interpretation.
図を用いて対ようXDRなどのデータ記述言語を使用することに多くの利点があります。言語は、図より正式であり、データの少ない曖昧な説明につながります。言語も理解し、1の代わりにビット符号化の低レベルの詳細の他の問題を考えることができやすくなります。また、XDRの種類や、CやPascalのような高レベル言語との間の密接な類似性があります。これは、XDRエンコードおよびデコードモジュールより簡単にタスクの実装を行います。最後に、言語仕様自体は、オンザフライでデータ解釈実行するために、マシンから渡すことができるASCII文字列です。
(2) Why is there only one byte-order for an XDR unit?
（2）なぜXDRユニットの一方のみバイト順序はありますか？
Supporting two byte-orderings requires a higher-level protocol for determining in which byte-order the data is encoded. Since XDR is not a protocol, this can't be done. The advantage of this, though, is that data in XDR format can be written to a magnetic tape, for example, and any machine will be able to interpret it, since no higher-level protocol is necessary for determining the byte-order.
2バイト順序付けをサポートするデータが符号化されたバイトの順序で決定するための、より高いレベルのプロトコルを必要とします。 XDRはプロトコルではありませんので、これを行うことはできません。この利点は、しかし、XDR形式のデータは、例えば、磁気テープに書き込むことができ、そして任意のマシンがない高いレベルのプロトコルはバイト順を決定する必要があるため、それを解釈することができるであろうということです。
(3) Why is the XDR byte-order big-endian instead of little-endian? Isn't this unfair to little-endian machines such as the VAX(r), which has to convert from one form to the other?
（3）なぜ、代わりに、リトルエンディアンのXDRのバイト順序ビッグエンディアンとは？これは、他の1つのフォームから変換する必要がありVAX（r）は、としてリトルエンディアンマシンに不公平ではないですか？
Yes, it is unfair, but having only one byte-order means you have to be unfair to somebody. Many architectures, such as the Motorola 68000* and IBM 370*, support the big-endian byte-order.
はい、それは不公平ですが、一つだけのバイトオーダーを持つことは、あなたが誰かに不公平でなければならないことを意味します。モトローラ68000 *とIBM 370 *などの多くのアーキテクチャは、ビッグエンディアンバイト順をサポートしています。
(4) Why is the XDR unit four bytes wide?
（4）なぜXDRユニットは、4バイト幅でありますか？
There is a tradeoff in choosing the XDR unit size. Choosing a small size, such as two, makes the encoded data small, but causes alignment problems for machines that aren't aligned on these boundaries. A large size, such as eight, means the data will be aligned on virtually every machine, but causes the encoded data to grow too big. We chose four as a compromise. Four is big enough to support most architectures efficiently, except for rare machines such as the eight-byte-aligned Cray*. Four is also small enough to keep the encoded data restricted to a reasonable size.
XDRユニットサイズを選択する際のトレードオフがあります。 、例えば2つの小さなサイズの選択、符号化されたデータは小さいなりますが、これらの境界に配置されていないマシンのための位置合わせの問題が発生します。など8のような大きなサイズは、データが事実上すべてのマシン上に整列されることを意味するが、符号化データが大きすぎる成長する原因となります。私たちは、妥協案として4を選択しました。四つは、8バイト整列クレイ*など希少な機械を除き、効率的にほとんどのアーキテクチャをサポートするのに十分な大きさです。フォーまた、合理的な大きさに制限された符号化データを維持するのに十分に小さいです。
(5) Why must variable-length data be padded with zeros?
（5）なぜ可変長データがゼロでパディングされなければなりませんか？
It is desirable that the same data encode into the same thing on all machines, so that encoded data can be meaningfully compared or checksummed. Forcing the padded bytes to be zero ensures this.
符号化データが意味の比較やチェックサムできるように同一のデータが、すべてのマシンで同じものにエンコードすることが望ましいです。ゼロにするパディングバイトを強制すると、これを保証します。
(6) Why is there no explicit data-typing?
（6）なぜ、明示的なデータ・タイピングがありませんか？
Data-typing has a relatively high cost for what small advantages it may have. One cost is the expansion of data due to the inserted type fields. Another is the added cost of interpreting these type fields and acting accordingly. And most protocols already know what type they expect, so data-typing supplies only redundant information. However, one can still get the benefits of data-typing using XDR. One way is to encode two things: first, a string that is the XDR data description of the encoded data, and then the encoded data itself. Another way is to assign a value to all the types in XDR, and then define a universal type that takes this value as its discriminant and for each value, describes the corresponding data type.
データタイピングは、それが持っているかもしれ小さな何の利点のために比較的高いコストを持っています。一つのコストが挿入されたタイプのフィールドに起因するデータの展開です。もう一つは、これらのタイプのフィールドを解釈し、それに応じて行動する追加コストです。そして、ほとんどのプロトコルはすでにだけ冗長な情報を、彼らが期待するものの種類を知っているので、データ入力を供給します。しかし、一つはまだXDRを使用して、データ・タイピングのメリットを得ることができます。まず、符号化データのXDRデータ記述し、その後符号化されたデータそのものである列を：1つの方法は、2つのものを符号化することです。別の方法は、XDR内のすべてのタイプに値を割り当て、その判別式としてこの値を取り、各値に対して、対応するデータタイプを記述するユニバーサルタイプを定義することです。
This specification uses an extended Back-Naur Form notation for describing the XDR language. Here is a brief description of the notation:
この仕様は、XDR言語を記述するための拡張バックナウアフォーム表記を使用します。ここでは表記の簡単な説明は次のとおりです。
(1) The characters '|', '(', ')', '[', ']', '"', and '*' are special. (2) Terminal symbols are strings of any characters surrounded by double quotes. (3) Non-terminal symbols are strings of non-special characters. (4) Alternative items are separated by a vertical bar ("|"). (5) Optional items are enclosed in brackets. (6) Items are grouped together by enclosing them in parentheses. (7) A '*' following an item means 0 or more occurrences of that item.
（1）文字 '|'、 '（'、 '）'、 '['、 ']'、 '"'、および特別な '*'（2）ターミナルシンボルは二重引用符で囲まれた任意の文字の文字列です。 （3）非終端記号は、非特殊文字の文字列である（4）代替項目は縦棒（「|」）により分離されている。（5）オプションの項目は括弧で囲まれている（6）アイテムが一緒にグループ化されます。括弧で囲む。（7）項目下記A「*」は、その項目の0回以上の繰り返しを意味します。
For example, consider the following pattern:
たとえば、次のパターンを考慮してください。
"a " "very" (", " "very")* [" cold " "and "] " rainy "
("day" | "night")
An infinite number of strings match this pattern. A few of them are:
文字列の無限の数は、このパターンに一致します。それらのいくつかは以下のとおりです。
"a very rainy day"
"a very, very rainy day"
"a very cold and rainy day"
"a very, very, very cold and rainy night"
(1) Comments begin with '/*' and terminate with '*/'. (2) White
space serves to separate items and is otherwise ignored. (3) An
identifier is a letter followed by an optional sequence of letters,
digits, or underbar ('_'). The case of identifiers is not ignored.
(4) A decimal constant expresses a number in base 10 and is a
sequence of one or more decimal digits, where the first digit is not
a zero, and is optionally preceded by a minus-sign ('-'). (5) A
hexadecimal constant expresses a number in base 16, and must be
preceded by '0x', followed by one or hexadecimal digits ('A', 'B',
'C', 'D', E', 'F', 'a', 'b', 'c', 'd', 'e', 'f', '0', '1', '2', '3',
'4', '5', '6', '7', '8', '9'). (6) An octal constant expresses a
number in base 8, always leads with digit 0, and is a sequence of one
or more octal digits ('0', '1', '2', '3', '4', '5', '6', '7').
declaration:
type-specifier identifier
| type-specifier identifier "[" value "]"
| type-specifier identifier "<" [ value ] ">"
| "opaque" identifier "[" value "]"
| "opaque" identifier "<" [ value ] ">"
| "string" identifier "<" [ value ] ">"
| type-specifier "*" identifier
| "void"
value: constant | identifier
値：定数|識別子
constant: decimal-constant | hexadecimal-constant | octal-constant
定数10進定数| 16進定数|進定数
type-specifier: [ "unsigned" ] "int" | [ "unsigned" ] "hyper" | "float" | "double" | "quadruple" | "bool" | enum-type-spec | struct-type-spec | union-type-spec | identifier
タイプ指定子：[ "符号なし"] "int型" | [ "符号なし"] "ハイパー" | 「フロート」| 「ダブル」| 「四」| 「ブール」|列挙型スペック|構造体の型スペック|ユニオン型スペック|識別子
enum-type-spec: "enum" enum-body
列挙型スペック：「列挙」列挙型ボディ
enum-body: "{" ( identifier "=" value ) ( "," identifier "=" value )* "}"
列挙体： "{"（識別子 "=" 値）（ "" 識別子 "=" 値）* "}"
struct-type-spec: "struct" struct-body
構造体の型スペック：「構造体」構造体、体
struct-body: "{" ( declaration ";" ) ( declaration ";" )* "}"
構造体ボディ： "{"（宣言 ";"）（宣言 ";"）* "}"
union-type-spec: "union" union-body
ユニオン型スペック：「労働組合」組合体
union-body: "switch" "(" declaration ")" "{" case-spec case-spec * [ "default" ":" declaration ";" ] "}"
組合体：「スイッチ」「（」宣言「）」「{」の場合スペックケーススペック* [「デフォルト」「：」宣言「;」 ] "}"
case-spec: ( "case" value ":") ( "case" value ":") * declaration ";"
ケース仕様（ "ケース" の値 "："）（ "ケース" 値 "："）*宣言 ";"
constant-def: "const" identifier "=" constant ";"
一定-DEF： "CONST" 識別子 "=" 一定の ";"
type-def: "typedef" declaration ";" | "enum" identifier enum-body ";" | "struct" identifier struct-body ";" | "union" identifier union-body ";"
typedefは： "typedefの" 宣言 ";" | 「列挙」識別子列挙体「;」 | 「構造体」識別子構造体体「;」 | 「労働組合」の識別子組合-体「;」
definition: type-def | constant-def
定義：タイプ-DEF |定DEF
specification: definition *
仕様：定義*
(1) The following are keywords and cannot be used as identifiers: "bool", "case", "const", "default", "double", "quadruple", "enum", "float", "hyper", "int", "opaque", "string", "struct", "switch", "typedef", "union", "unsigned", and "void".
（1）以下のキーワードであり、識別子として使用することはできません。「ブール」、「ケース」、「CONST」、「デフォルト」、「ダブル」、「四」、「列挙型」、「フロート」、「ハイパー」、 "INT"、 "不透明"、 "文字列"、 "構造体"、 "スイッチ"、 "typedefの"、 "労働組合"、 "符号なし"、および "無効"。
(2) Only unsigned constants may be used as size specifications for arrays. If an identifier is used, it must have been declared previously as an unsigned constant in a "const" definition.
（2）のみ符号なし定数は、アレイのサイズ仕様として使用することができます。識別子が使用されている場合、それは「CONST」の定義における符号なし定数として以前に宣言しておく必要があります。
(3) Constant and type identifiers within the scope of a specification are in the same name space and must be declared uniquely within this scope.
（3）仕様の範囲内で一定とタイプ識別子は、同じ名前空間内にあり、この範囲内で一意に宣言されなければなりません。
(4) Similarly, variable names must be unique within the scope of struct and union declarations. Nested struct and union declarations create new scopes.
（4）同様に、変数名は、構造体と共用体の宣言の範囲内で一意でなければなりません。ネストされた構造体と共用体の宣言は、新しいスコープを作成します。
(5) The discriminant of a union must be of a type that evaluates to an integer. That is, "int", "unsigned int", "bool", an enumerated type, or any typedefed type that evaluates to one of these is legal. Also, the case values must be one of the legal values of the discriminant. Finally, a case value may not be specified more than once within the scope of a union declaration.
（5）組合の判別式は、整数に評価されるタイプのものでなければなりません。それは、「ブール」、列挙型、またはこれらのいずれかを評価する任意のtypedefedタイプは合法である、「unsigned int型」、「int型」です。また、ケース値は、判別の正当な値のいずれかでなければなりません。最後に、ケースの値は、共用体宣言の範囲内で複数回指定されなくてもよいです。
Here is a short XDR data description of a thing called a "file", which might be used to transfer files from one machine to another.
ここでは別のマシンからファイルを転送するために使用されるかもしれない「ファイル」と呼ばれるもの、の短いXDRデータ記述です。
const MAXUSERNAME = 32; /* max length of a user name */
const MAXFILELEN = 65535; /* max length of a file */
const MAXNAMELEN = 255; /* max length of a file name */
/*
* Types of files:
*/
enum filekind {
TEXT = 0, /* ascii data */
DATA = 1, /* raw data */
EXEC = 2 /* executable */
};
/*
* File information, per kind of file:
*/
union filetype switch (filekind kind) {
case TEXT:
void; /* no extra information */
case DATA:
string creator<MAXNAMELEN>; /* data creator */
case EXEC:
string interpretor<MAXNAMELEN>; /* program interpretor */
};
/*
* A complete file:
*/
struct file {
string filename<MAXNAMELEN>; /* name of file */
filetype type; /* info about file */
string owner<MAXUSERNAME>; /* owner of file */
opaque data<MAXFILELEN>; /* file data */
};
Suppose now that there is a user named "john" who wants to store his lisp program "sillyprog" that contains just the data "(quit)". His file would be encoded as follows:
「（終了）」だけのデータが含まれている彼のlispのプログラム「sillyprog」を保存したい「ジョン」という名前のユーザーが存在することになりましたと。次のように彼のファイルをエンコードすることになります。
OFFSET HEX BYTES ASCII COMMENTS
------ --------- ----- --------
0 00 00 00 09 .... -- length of filename = 9
4 73 69 6c 6c sill -- filename characters
8 79 70 72 6f ypro -- ... and more characters ...
12 67 00 00 00 g... -- ... and 3 zero-bytes of fill
16 00 00 00 02 .... -- filekind is EXEC = 2
20 00 00 00 04 .... -- length of interpretor = 4
24 6c 69 73 70 lisp -- interpretor characters
28 00 00 00 04 .... -- length of owner = 4
32 6a 6f 68 6e john -- owner characters
36 00 00 00 06 .... -- length of file data = 6
40 28 71 75 69 (qui -- file data bytes ...
44 74 29 00 00 t).. -- ... and 2 zero-bytes of fill
XDR is a data description language, not a protocol, and hence it does not inherently give rise to any particular security considerations. Protocols that carry XDR-formatted data, such as NFSv4, are responsible for providing any necessary security services to secure the data they transport.
XDRデータ記述言語、ないプロトコルであるため、それは本質的に特定のセキュリティ上の考慮事項を生じません。このようなNFSv4としてXDR-形式のデータを運ぶプロトコルは、データ彼らの輸送を確保するためにあらゆる必要なセキュリティサービスを提供する責任があります。
Care must be take to properly encode and decode data to avoid attacks. Known and avoidable risks include:
ケアが適切にエンコードし、攻撃を回避するために、データを復号化するために取ることが必要です。既知および回避のリスクが含まれます：
* Buffer overflow attacks. Where feasible, protocols should be defined with explicit limits (via the "<" [ value ] ">" notation instead of "<" ">") on elements with variable-length data types. Regardless of the feasibility of an explicit limit on the variable length of an element of a given protocol, decoders need to ensure the incoming size does not exceed the length of any provisioned receiver buffers.
*バッファオーバーフロー攻撃。可能であれば、プロトコルは、可変長データ型の要素に（代わりに「<」「>」の「<」[値]「>」の表記を介して）明示的な制限に定義されるべきです。かかわらず、特定のプロトコルの要素の可変長に明示的な制限の可能性の、デコーダは、着信サイズは任意プロビジョニング受信バッファの長さを超えないようにする必要があります。
* Nul octets embedded in an encoded value of type string. If the decoder's native string format uses nul-terminated strings, then the apparent size of the decoded object will be less than the amount of memory allocated for the string. Some memory deallocation interfaces take a size argument. The caller of the deallocation interface would likely determine the size of the string by counting to the location of the nul octet and adding one. This discrepancy can cause memory leakage (because less memory is actually returned to the free pool than allocated), leading to system failure and a denial of service attack.
文字列型の符号化された値に埋め込ま* NULオクテット。デコーダのネイティブ文字列フォーマットはNULで終わる文字列を使用する場合、復号化対象の見かけの大きさは、文字列に割り当てられたメモリの量よりも少ないであろう。いくつかのメモリ割り当て解除インタフェースはsize引数を取ります。割り当て解除インタフェースの呼び出し元は、おそらくNULオクテットの位置にカウントし、いずれかを添加することにより、文字列のサイズを決定するであろう。 （より少ないメモリが実際に割り当てられたよりも自由プールに戻されているため）この矛盾は、システム障害やサービス拒否攻撃につながる、メモリリークが発生する可能性があります。
* Decoding of characters in strings that are legal ASCII characters but nonetheless are illegal for the intended application. For example, some operating systems treat the '/' character as a component separator in path names. For a protocol that encodes a string in the argument to a file creation operation, the decoder needs to ensure that '/' is not inside the component name. Otherwise, a file with an illegal '/' in its name will be created, making it difficult to remove, and is therefore a denial of service attack.
*法的なASCII文字であるが、それにもかかわらず、目的とする用途のために違法である文字列内の文字のデコード。例えば、いくつかのオペレーティングシステムは、パス名内のコンポーネント区切り文字として「/」文字を扱います。ファイル作成操作の引数の文字列をエンコードするプロトコルの場合、デコーダは、「/」、コンポーネント名の内側にないことを確認する必要があります。それ以外の場合は、違法な「/」でその名前を持つファイルは、それが困難削除すること、作成されますので、サービス拒否攻撃です。
* Denial of service caused by recursive decoder or encoder subroutines. A recursive decoder or encoder might process data that has a structured type with a member of type optional data that directly or indirectly refers to the structured type (i.e., a linked list). For example,
*再帰的デコーダまたはエンコーダサブルーチンによって引き起こされるサービスの拒否。再帰的デコーダまたはエンコーダが、直接または間接的に構造化されたタイプ（すなわち、リンクリスト）を指すタイプオプションのデータのメンバーと構造型を有するデータを処理するかもしれません。例えば、
struct m {
int x;
struct m *next;
};
An encoder or decoder subroutine might be written to recursively call itself each time another element of type "struct m" is found. An attacker could construct a long linked list of "struct m" elements in the request or response, which then causes a stack overflow on the decoder or encoder. Decoders and encoders should be written non-recursively or impose a limit on list length.
エンコーダまたはデコーダサブルーチンが再帰型「構造体M」の別の要素が発見されるたびに自分自身を呼び出すために書かれるかもしれません。攻撃者は、その後、デコーダやエンコーダでスタックオーバーフローを引き起こす要求または応答では、「構造体M」要素の長いリンクリストを構築することができました。デコーダとエンコーダは、非再帰的に書かれたか、リストの長さに制限を課すべきです。
It is possible, if not likely, that new data types will be added to XDR in the future. The process for adding new types is via a standards track RFC and not registration of new types with IANA. Standards track RFCs that update or replace this document should be documented as such in the RFC Editor's database of RFCs.
そうでない場合には、新しいデータ型は、将来的にXDRに追加されることが、可能です。新しいタイプを追加するためのプロセスは、IANAとの新しいタイプの登録基準トラックRFCを経由してではありません。規格は、RFCのRFC編集者のデータベースでそのように文書化する必要があり、更新や、この文書を交換するRFCを追跡します。
SUN WORKSTATION Sun Microsystems, Inc. VAX Hewlett-Packard Company IBM-PC International Business Machines Corporation Cray Cray Inc. NFS Sun Microsystems, Inc. Ethernet Xerox Corporation. Motorola 68000 Motorola, Inc. IBM 370 International Business Machines Corporation
日WORKSTATIONサン・マイクロシステムズ株式会社VAXヒューレット・パッカード・カンパニーIBM-PC、インターナショナル・ビジネス・マシーンズ・コーポレーションクレイクレイ社NFSサン・マイクロシステムズ社のイーサネットゼロックス社。モトローラ68000モトローラ社IBM 370インターナショナル・ビジネス・マシーンズ・コーポレーション
The definition of NaNs, signed zero and infinity, and denormalized numbers from [IEEE] is reproduced here for convenience. The definitions for quadruple-precision floating point numbers are analogs of those for single and double-precision floating point numbers and are defined in [IEEE].
NaNの定義は、ゼロと無限大に署名し、便宜上ここで再生される[IEEE]から数値を非正規化。 4倍精度浮動小数点数の定義は、単精度および倍精度浮動小数点数のために、これらの類似体であり、[IEEE]で定義されています。
In the following, 'S' stands for the sign bit, 'E' for the exponent, and 'F' for the fractional part. The symbol 'u' stands for an undefined bit (0 or 1).
以下では、「S」を小数部分のための符号ビット、指数部は「E」、および「F」の略です。シンボル「U」が未定義ビット（0または1）を表します。
For single-precision floating point numbers:
単精度浮動小数点数の場合：
Type S (1 bit) E (8 bits) F (23 bits)
---- --------- ---------- -----------
signalling NaN u 255 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 255 (max) .1uuuuu---u
negative infinity 1 255 (max) .000000---0
positive infinity 0 255 (max) .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
For double-precision floating point numbers:
倍精度浮動小数点数の場合：
Type S (1 bit) E (11 bits) F (52 bits)
---- --------- ----------- -----------
signalling NaN u 2047 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 2047 (max) .1uuuuu---u
negative infinity 1 2047 (max) .000000---0
positive infinity 0 2047 (max) .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
For quadruple-precision floating point numbers:
4倍精度浮動小数点数の場合：
Type S (1 bit) E (15 bits) F (112 bits)
---- --------- ----------- ------------
signalling NaN u 32767 (max) .0uuuuu---u
(with at least
one 1 bit)
quiet NaN u 32767 (max) .1uuuuu---u
negative infinity 1 32767 (max) .000000---0
positive infinity 0 32767 (max) .000000---0
negative zero 1 0 .000000---0
positive zero 0 0 .000000---0
Subnormal numbers are represented as follows:
次のように非正規数が表現されます。
Precision Exponent Value
--------- -------- -----
Single 0 (-1)**S * 2**(-126) * 0.F
Double 0 (-1)**S * 2**(-1022) * 0.F
ダブル0（-1）** S * 2 **（ - 1022年）* 0.F
Quadruple 0 (-1)**S * 2**(-16382) * 0.F
トリプル0（-1）** S * 2 **（ - 16382）* 0.F
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.
[IEEE]「バイナリ浮動小数点演算のためのIEEE規格」、ANSI / IEEE規格754-1985、電気電子技術、1985年8月の研究所。
[KERN] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming Language", Bell Laboratories, Murray Hill, New Jersey, 1978.
[カーン]ブライアンW.カーニハン＆デニスM.リッチー、「プログラミング言語C」、ベル研究所、マリーヒル、ニュージャージー州、1978年。
[COHE] Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer, October 1981.
、IEEEコンピュータ、1981年10月「聖戦と平和のための嘆願について」[COHE]ダニー・コーエン、。
[COUR] "Courier: The Remote Procedure Call Protocol", XEROX Corporation, XSIS 038112, December 1981.
[COUR] "宅配便：リモートプロシージャコールプロトコル"、XEROX社、XSIS 038112、1981年12月。
[SPAR] "The SPARC Architecture Manual: Version 8", Prentice Hall, ISBN 0-13-825001-4.
[SPAR] "SPARCアーキテクチャマニュアル：バージョン8"、プレンティスホール、ISBN 0-13-825001-4。
[HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906.
[HPRE] "HPプレシジョンアーキテクチャハンドブック"、1987年6月、5954から9906まで。
Bob Lyon was Sun's visible force behind ONC RPC in the 1980s. Sun Microsystems, Inc., is listed as the author of RFC 1014. Raj Srinivasan and the rest of the old ONC RPC working group edited RFC 1014 into RFC 1832, from which this document is derived. Mike Eisler and Bill Janssen submitted the implementation reports for this standard. Kevin Coffman, Benny Halevy, and Jon Peterson reviewed this document and gave feedback. Peter Astrand and Bryan Olson pointed out several errors in RFC 1832 which are corrected in this document.
ボブ・リヨンは、1980年代にONC RPCの背後にある太陽の見える力となりました。サン・マイクロシステムズ社は、RFC 1014のRaj Srinivasan氏の著者と、この文書が由来するRFC 1832にRFC 1014を編集した古いONC RPCワーキンググループの残りの部分として表示されます。マイク・アイスラーとビル・ヤンセンは、この標準の実装報告書を提出しました。ケビン・コフマン、ベニー・アレヴィ、およびジョンピーターソンは、この文書をレビューし、フィードバックを与えました。ピーターAstrandとブライアン・オルソンは、このドキュメントで修正されているRFC 1832でいくつかのエラーを指摘しました。
Editor's Address
編集者の住所
Mike Eisler 5765 Chase Point Circle Colorado Springs, CO 80919 USA
マイク・アイスラー5765チェイスポイントサークルコロラドスプリングス、CO 80919 USA
Phone: 719-599-9026 EMail: email2mre-rfc4506@yahoo.com
電話：719-599-9026 Eメール：email2mre-rfc4506@yahoo.com
Please address comments to: nfsv4@ietf.org
nfsv4@ietf.org：へのコメントに対処してください
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）によって提供されます。