[要約] RFC 4506は、XDR（External Data Representation）の標準を定義しており、データの表現と相互運用性を提供することを目的としています。このRFCは、データのエンコードとデコードの方法、データ型の定義、およびネットワーク上でのデータの交換に関するガイドラインを提供しています。
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
XDR：外部データ表現標準
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).
Copyright（c）The Internet Society（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 Workstation*、Vax*、IBM-PC*、Cray*などの多様なマシン間でデータを通信するために使用されています。XDRはISOプレゼンテーションレイヤーに適合し、X.409のISO抽象的な構文表記に目的がほぼ類似しています。これら2つの主な違いは、XDRが暗黙的なタイピングを使用し、X.409が明示的なタイピングを使用することです。
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は言語を使用してデータ形式を説明します。言語は、データを説明するためにのみ使用できます。プログラミング言語ではありません。この言語では、複雑なデータ形式を簡潔に説明できます。グラフィカル表現（それ自体が非公式の言語）を使用する代替手段は、複雑さに直面するとすぐに理解できなくなります。XDR言語自体は、Courier [Cour]がMesaに似ているように、C言語[Kern]に似ています。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.
XDR標準は、次の仮定を作成します。バイト（またはオクテット）はポータブルであり、バイトは8ビットのデータとして定義されます。特定のハードウェアデバイスは、他のハードウェアデバイスが意味を失うことなくバイトをデコードできるように、バイトをさまざまなメディアにエンコードする必要があります。たとえば、イーサネット*標準は、バイトが「リトルエンディアン」スタイル[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ビット）のデータが複数あります。バイトには0からn-1に番号が付けられています。バイトは、バイトmが常にバイトM 1に先行するように、あるバイトストリームに読み取りまたは書き込まれます1。ゼロバイト、R、合計バイトを4の倍数にカウントします。
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".
言語の各データ型について、一般的なパラダイム宣言を示します。角度ブラケット（<and>）は、データの可変長さシーケンスを示し、正方形の括弧（[および]）がデータの固定長シーケンスを示すことに注意してください。「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の非署名整数は、範囲の非陰性整数をコードする32ビットデータムです[0,4294967295]。これは、それぞれ最も有意なバイトがそれぞれ0と3である符号なしのバイナリ数で表されます。署名されていない整数が次のように宣言されます。
unsigned int identifier;
署名されていない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;
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;
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
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).
数の最も多くの有意なバイトが0および3であるように、単一式の浮動小数点数の最大および最も有意なビットは0と31です。、およびfはそれぞれ0、1、および9です。これらの数値は、ビットの数学的位置を指し、実際の物理的な位置（中程度から中程度まで異なる）ではなく指していることに注意してください。
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仕様は、署名されたゼロ、署名された無限（オーバーフロー）、および非正規化された数字（Underflow）[IEEE]のエンコーディングに関して相談する必要があります。IEEE仕様によると、「NAN」（数ではない）はシステムに依存しており、XDR内で「NAN」以外のものと解釈されるべきではありません。
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:
標準は、ダブルサイジョンの浮動小数点データ型 "double"（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
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).
数の最も多くの有意なバイトが0および3であるように、二重精度の浮動小数点数の最大および最も有意なビットは0と63です。、およびfはそれぞれ0、1、および12です。これらの数値は、ビットの数学的位置を指し、実際の物理的な位置（中程度から中程度まで異なる）ではなく指していることに注意してください。
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仕様は、署名されたゼロ、署名された無限（オーバーフロー）、および非正規化された数字（Underflow）[IEEE]のエンコーディングに関して相談する必要があります。IEEE仕様によると、「NAN」（数ではない）はシステムに依存しており、XDR内で「NAN」以外のものと解釈されるべきではありません。
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:
標準は、四重幅のプレシジョンフローティングポイントデータ型「Quadruple」（128ビットまたは16バイト）のエンコードを定義します。使用されるエンコーディングは、1つの形式の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. 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
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).
数の最も多くの有意なバイトが0および3であるように、4倍前のフローティングポイント数の最大および最も有意なビットは0と127です。、およびfはそれぞれ0、1、および16です。これらの数値は、ビットの数学的位置を指し、実際の物理的な位置（中程度から中程度まで異なる）ではなく指していることに注意してください。
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".
署名されたゼロ、署名された無限（オーバーフロー）、および非正規化された数字のエンコーディングは、単一および二重精度のフローティングポイント数[SPAR]、[HPRE]の対応するエンコーディングのアナログです。Quadruple Precisionの浮動小数点数に適用される「NAN」エンコードはシステムに依存しており、XDR内で「NAN」以外のものと解釈されるべきではありません。
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バイトの後に十分な（0〜3）残留ゼロバイトrが続き、不透明なオブジェクトの合計バイト数を4つの倍数にします。
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（番号0からn-1）のシーケンスとして定義される可変長（カウント）不透明データも提供します。シーケンスの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 1に先行し、シーケンスのバイト0は常にシーケンスの長さ（カウント）に従います。nが4つの倍数ではない場合、nバイトの後に十分な（0〜3）残留ゼロバイトrが続き、合計バイトが4つの倍数にカウントされます。可変長の不透明データは、次のように宣言されます。
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は、シーケンスに含まれるバイト数の上限を示します。2回目の宣言のように、mが指定されていない場合、（2 ** 32）-1、最大長であると想定されます。
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>;
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（番号0からn-1）asciiバイトの文字列を定義し、符号なしの整数（上記のように）としてエンコードされた数nで、その後、文字列のnバイトが続きます。文字列のバイトは常に文字列のバイトM 1に先行し、文字列のバイト0は常に文字列の長さに従います。nが4つの倍数ではない場合、nバイトの後に十分な（0〜3）残留ゼロバイトrが続き、合計バイトが4つの倍数にカウントされます。カウントされたバイト文字列は次のように宣言されています。
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は、文字列に含まれるバイト数の上限を示します。2回目の宣言のように、mが指定されていない場合、（2 ** 32）-1、最大長であると想定されます。通常、Mはプロトコル仕様に記載されています。たとえば、ファイリングプロトコルは、次のように、ファイル名は255バイト以下になる可能性があると述べている場合があります。
string 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];
type-name識別子[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の番号が付けられた要素の固定長い配列は、アレイの要素を自然な順序で0からn-1で個別にエンコードすることによってエンコードされます。各要素のサイズは、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は、配列の最大許容要素カウントを指定します。2回目の宣言のように、mが指定されていない場合、それは（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」、または「bool」などの列挙型のいずれかです。コンポーネントタイプは、組合の「武器」と呼ばれ、その前には、そのエンコードを意味する判別剤の価値があります。差別された組合は次のように宣言されます。
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 voidは0バイト数量です。ボイドは、データを入力として取得しない操作またはデータを出力として説明するのに役立ちます。また、一部の武器にデータが含まれている場合があり、他の武器にはない組合でも役立ちます。宣言は単に次のとおりです。
void;
空所;
Voids are illustrated as follows:
ボイドは次のように説明されています。
++
|| VOID
++
--><-- 0 bytes
The data declaration for a constant follows this form:
定数のデータ宣言は、次の形式に従います。
const name-identifier = n;
const name-identifier = 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に等しいシンボリック一定のダースを定義します。
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の宣言部分の変数名です。たとえば、「Egg」と呼ばれる既存のタイプを使用して、「Eggbox」と呼ばれる新しいタイプを定義しています。
typedef egg eggbox[DOZEN];
typedef egg 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];
エッグボックスフレッシュヘッグ;卵の新鮮な卵[ダース];
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;
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」部品を削除し、「struct」、「union」、または「enum」キーワードの後に識別子を配置することにより、代替フォームに変換できます。たとえば、タイプ「ブール」を定義する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.
この構文は、新しいタイプの名前を把握するために宣言の終了まで待つ必要がないため、好ましいです。
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;
type-name *識別子;
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>;
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;
typedef stringentry *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>;
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.
これらの宣言は両方とも、弦楽項型タイプの意図を曖昧にするため、オプションのデータ宣言が両方で優先されます。オプションのDATAタイプは、ポインターを使用して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.
XDRへの拡張機能を想像することができます。これにより、TCPなどのほぼすべての既存のプロトコルを説明できます。これに必要な最小は、さまざまなブロックサイズとバイトオーダーのサポートです。ここで説明する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と図を使用するなどのデータ説明言語を使用することには、多くの利点があります。言語は図よりも正式であり、データのあいまいな説明につながります。また、言語は、ビットエンコードの低レベルの詳細ではなく、他の問題を考えることができ、理解しやすくなります。また、XDRのタイプとCやPascalなどの高レベルの言語との間には密接な類似性があります。これにより、XDRのエンコードとデコードモジュールの実装が簡単になります。最後に、言語仕様自体は、マシンからマシンへと渡すことができるASCII文字列です。
(2) Why is there only one byte-order for an XDR unit?
(2) XDRユニットにバイトオーダーが1つしかないのはなぜですか？
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バイトオーダーの大エンディアンがいるのですか？これは、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.
はい、それは不公平ですが、1つのバイトオーダーしかないことは、誰かに不公平でなければならないことを意味します。Motorola 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つを選びました。4バイトに並べられたクレイ*などの希少なマシンを除き、4つはほとんどのアーキテクチャを効率的にサポートするのに十分な大きさです。4つは、エンコードされたデータを妥当なサイズに制限するのに十分なほど小さいです。
(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.
Data-Typingは、それがどのような利点を持っているかについて比較的高いコストを持っています。1つのコストは、挿入されたタイプフィールドによるデータの拡張です。もう1つは、これらのタイプフィールドを解釈し、それに応じて行動するための追加コストです。そして、ほとんどのプロトコルはすでに期待しているタイプを知っているので、データタイピングは冗長な情報のみを提供します。ただし、XDRを使用してデータタイピングの利点を得ることができます。1つの方法は、2つのことをエンコードすることです。最初に、エンコードされたデータのXDRデータ説明である文字列、次にエンコードされたデータ自体です。別の方法は、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) 文字 '|'、 '（'、 '）'、 '['、 ']'、 '"'、および '*'は特別です。）非末端シンボルは非専門文字の文字列です。（4）代替アイテムは垂直バーで区切られています（ "|"）。（5）オプションのアイテムは括弧内に囲まれています。括弧内。（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').
(1) コメントは「/*」で始まり、「*/」で終了します。（2）空白はアイテムを分離するのに役立ち、それ以外の場合は無視されます。（3）識別子とは、文字、数字、またはunderbar（ '_'）のオプションのシーケンスが続く文字です。識別子の場合は無視されません。（4）小数定数はベース10で数値を発現し、1桁以上の数字のシーケンスであり、最初の数字はゼロではなく、オプションでマイナス標識（ ' - '）が先行します。（5）16進数定数はベース16の数値を発現し、「0x」、その後に1つまたは16桁（ 'a'、 'b'、 'c'、 'd'、e '、'が続く必要があります。'、' a '、' b '、' c ''、 'd'、 'e'、 'f'、 '0'、 '1'、 '2'、 '3'、 '4'、 '5'、'6'、 '7'、 '8'、 '9'）。（6）octal定数はベース8の数を表し、常に数字0でリードし、1つ以上のオクタル桁（ '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
enum-type-spec: "enum" enum-body
enum-type-spec： "enum" enum-body
enum-body: "{" ( identifier "=" value ) ( "," identifier "=" value )* "}"
enum-body： "{"（識別子 "="値）（ "、"識別子 "="値）* "}"
struct-type-spec: "struct" struct-body
struct-type-spec： "struct" struct-body
struct-body: "{" ( declaration ";" ) ( declaration ";" )* "}"
struct-body： "{"（宣言 ";"）（宣言 ";"）* "}"
union-type-spec: "union" union-body
ユニオンタイプスペック：「組合」組合体
union-body:
"switch" "(" declaration ")" "{"
case-spec
case-spec *
[ "default" ":" declaration ";" ]
"}"
case-spec: ( "case" value ":") ( "case" value ":") * declaration ";"
case-spec：（ "case" value "："）（ "case" value "："） *宣言 ";"
constant-def: "const" identifier "=" constant ";"
定数def： "const"識別子 "=" constant ";"
type-def:
"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"
definition: type-def | constant-def
定義：Type-DEF |constant-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」、「デフォルト」、「ダブル」、「Quadruple」、「enum」、「float」、 "hyper"、 "int"、「Opaque "、" String "、" struct "、" switch "、" typedef "、" union "、" unsigned "、および" void "。
(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) 連合の判別は、整数に評価するタイプでなければなりません。つまり、「int」、「unsigned int」、「bool」、列挙されたタイプ、またはこれらのいずれかを評価する任意のタイプ化されたタイプは合法です。また、ケース値は、判別の法的価値の1つでなければなりません。最後に、組合宣言の範囲内でケース値を複数回指定しない場合があります。
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:
これで、「John」という名前のユーザーが、「データ」（QUIT）を含む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.
* バッファオーバーフロー攻撃。実行可能な場合、プロトコルは、さまざまな長さのデータ型を持つ要素の明示的な制限（「<"[value]"> "notation" <"" "" "" "" "" "" ">"を介して）で定義する必要があります。特定のプロトコルの要素の変数長の明示的な制限の実現可能性に関係なく、デコーダは、入力サイズがプロビジョニングされたレシーバーバッファーの長さを超えないようにする必要があります。
* 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末端の文字列を使用する場合、デコードされたオブジェクトの見かけのサイズは、文字列に割り当てられたメモリの量よりも少なくなります。一部のメモリディールロケーションインターフェイスは、サイズの引数を取ります。Deallocation Interfaceの発信者は、Nul Octetの場所にカウントして追加することにより、文字列のサイズを決定する可能性があります。この矛盾は、メモリの漏れを引き起こす可能性があります（実際には割り当てられたよりもフリープールに戻されるメモリが少ないため）。システムの障害とサービス攻撃の拒否につながります。
* 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.
エンコーダーまたはデコーダーサブルーチンは、タイプ「struct m」の別の要素が見つかるたびに再帰的に呼び出すように書かれている場合があります。攻撃者は、リクエストまたは応答に「struct 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を追跡する標準は、RFCSの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
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].
[IEEE]からのゼロと無限の署名、ゼロと無限のNANSの定義は、便利なためにここで再現されています。四角形前のフローティングポイント番号の定義は、単一および二重精度の浮動小数点数の類似物であり、[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」は指数の「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
ネガティブインフィニティ1 255（最大）.000000 --- 0
positive infinity 0 255 (max) .000000---0
ポジティブインフィニティ0 255（最大）.000000 --- 0
negative zero 1 0 .000000---0
負のゼロ1 0 .000000 --- 0
positive zero 0 0 .000000---0
正のゼロ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
ネガティブインフィニティ1 2047（最大）.000000 --- 0
positive infinity 0 2047 (max) .000000---0
ポジティブインフィニティ0 2047（最大）.000000 --- 0
negative zero 1 0 .000000---0
負のゼロ1 0 .000000 --- 0
positive zero 0 0 .000000---0
正のゼロ0 0 .000000 --- 0
For quadruple-precision floating point numbers:
四角形のプレシジョンフローティングポイント番号の場合：
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
ネガティブインフィニティ1 32767（最大）.000000 --- 0
positive infinity 0 32767 (max) .000000---0
ポジティブインフィニティ0 32767（最大）.000000 --- 0
negative zero 1 0 .000000---0
負のゼロ1 0 .000000 --- 0
positive zero 0 0 .000000---0
正のゼロ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
Quadruple 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 Standard 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.
[Cohe] Danny Cohen、「聖戦と平和のための嘆願」、IEEEコンピューター、1981年10月。
[COUR] "Courier: The Remote Procedure Call Protocol", XEROX Corporation, XSIS 038112, December 1981.
[cour]「クーリエ：リモート手順コールプロトコル」、Xerox Corporation、XSIS 038112、1981年12月。
[SPAR] "The SPARC Architecture Manual: Version 8", Prentice Hall, ISBN 0-13-825001-4.
[SPAR] "The Sparc Architecture Manual：バージョン8"、Prentice Hall、ISBN 0-13-825001-4。
[HPRE] "HP Precision Architecture Handbook", June 1987, 5954-9906.
[HPRE]「HP Precision Architecture Handbook」、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の背後にある太陽の目に見える力でした。Sun Microsystems、Inc。は、RFC 1014の著者としてリストされています。RajSrinivasanおよびその他の古いONCワーキンググループの残りの部分は、RFC 1014をRFC 1832に編集しました。マイク・アイスラーとビル・ヤンセンは、この標準の実装レポートを提出しました。Kevin Coffman、Benny Halevy、およびJon Petersonはこの文書をレビューし、フィードバックをしました。Peter AstrandとBryan Olsonは、このドキュメントで修正された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メール：email2mre-rfc4506@yahoo.com
Please address comments to: nfsv4@ietf.org
nfsv4@ietf.orgへのコメントをお問い合わせください
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。