rfc-1832

XDR: External Data Representation Standard

R. Srinivasan
date1995-08 streamIETF areatsv wgoncrpc statusDRAFT STANDARD pages24 canonicalhttps://www.rfc-editor.org/rfc/rfc1832 doi10.17487/RFC1832
This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]

obsoleted by

Extracted elements (30)

design-rationale §4

A formal data-description language is preferred over graphical (diagram) representations because languages are more formal, less ambiguous, closer to high-level language types (C/Pascal), and the specification itself is an ASCII string that can be transmitted for on-the-fly data interpretation.

design-rationale §4

The 4-byte unit size was chosen as a compromise: 2-byte units produce smaller data but cause alignment problems on many architectures; 8-byte units align everywhere but bloat data. Four bytes is large enough for most architectures and small enough to keep encoded size reasonable, with the Cray (8-byte aligned) as a known exception.

design-rationale §3.20

XDR intentionally lacks bit fields, bitmaps, and packed decimals because its scope is limited to the most common data types of high-level languages (C, Pascal), not a universal encoding for all existing protocols. Extensions for variable block sizes and byte orders would be needed to describe protocols like TCP.

design-rationale §4

XDR mandates a single byte order (big-endian) rather than supporting both, because supporting two orders would require a higher-level protocol to signal the encoding. The single-order approach allows XDR data written to media (e.g., magnetic tape) to be read by any machine without additional negotiation.

design-rationale §4

XDR uses implicit typing (no type tags on the wire) rather than explicit typing because most protocols already know the expected type, making type fields redundant. Explicit typing adds expansion overhead and interpretation cost for little practical benefit.

interoperability-note §1

XDR uses implicit typing, in contrast to X.409 (ISO ASN.1) which uses explicit typing. This is the primary structural difference between XDR and ISO presentation-layer encoding standards.

normative-requirement §3.10 MUST NOT

It is an error to encode a variable-length opaque, string, or array value whose length n exceeds the maximum m declared in the specification.

normative-requirement §3.3 MUST NOT

It is an error to encode as an enum any integer value other than those explicitly assigned in the enum declaration.

normative-requirement §5.4 MUST

Only unsigned constants may be used as array size specifications; if an identifier is used as a size, it must have been declared previously as an unsigned constant in a const definition.

normative-requirement §2 MUST

Residual padding bytes appended to variable-length data MUST be zero, ensuring that the same data encodes identically on all machines so encoded data can be meaningfully compared or checksummed.

normative-requirement §5.4 MUST

The discriminant of a union must be of a type that evaluates to an integer (int, unsigned int, bool, or an enumerated/typedefed equivalent); case values must be legal values of the discriminant and may not be specified more than once within a union scope.

protocol-element §3.4

Boolean is a first-class type encoded as enum { FALSE = 0, TRUE = 1 }, occupying 4 bytes on the wire.

protocol-element §3.3

Enumerations are encoded identically to signed 32-bit integers. It is an error to encode any integer value not explicitly assigned in the enum declaration.

protocol-element §3.19

Optional-data (type-name *identifier) is syntactic sugar for a discriminated union with a boolean discriminant: TRUE arm carries a value of the named type, FALSE arm is void. This pattern supports recursive structures such as linked lists.

protocol-element §3.16

Void is a 0-byte quantity used for union arms that carry no data or for operations with no input/output. It contributes nothing to the byte stream.

security-consideration §Security Considerations

The RFC explicitly states that security issues are not discussed in this memo. Implementors must consider security implications (e.g., buffer overflows from untrusted length fields in variable-length types) independently.

security

wire-format §2

All XDR items are encoded as a multiple of four bytes. If the data requires n bytes not divisible by four, 0 to 3 residual zero bytes are appended so that (n+r) mod 4 = 0.

wire-format §3.15

Discriminated union encodes a 4-byte discriminant (int, unsigned int, or enum) followed by the encoding of the selected arm. If no default arm is specified, encoding an unspecified discriminant value is invalid.

wire-format §3.7

Double-precision float is 64 bits encoded per IEEE 754: 1-bit sign (S), 11-bit exponent biased by 1023 (E), 52-bit mantissa fraction (F). NaN is system-dependent and must not be interpreted as anything other than NaN within XDR.

wire-format §3.12

Fixed-length array (type-name identifier[n]) encodes elements 0 through n-1 sequentially; each element is a multiple of four bytes. Elements of the same type may vary in size (e.g., strings).

wire-format §3.9

Fixed-length opaque data (opaque identifier[n]) encodes exactly n bytes followed by 0–3 zero padding bytes r such that (n+r) mod 4 = 0. No length prefix is transmitted.

wire-format §3.5

Hyper integer and unsigned hyper integer are 64-bit (8-byte) big-endian quantities in two's complement notation; most significant byte is byte 0, least significant is byte 7.

wire-format §3.8

Quadruple-precision float is 128 bits: 1-bit sign (S), 15-bit exponent biased by 16383 (E), 112-bit mantissa fraction (F), modeled as an analog of IEEE 754 double-extended precision. NaN is system-dependent.

wire-format §3.6

Single-precision float is 32 bits encoded per IEEE 754: 1-bit sign (S), 8-bit exponent biased by 127 (E), 23-bit mantissa fraction (F); value is (-1)^S * 2^(E-127) * 1.F. NaN is system-dependent and must not be interpreted as anything other than NaN within XDR.

wire-format §3.11

String (string identifier<m>) encodes a 4-byte unsigned integer length n followed by n ASCII bytes and 0–3 zero padding bytes. Default maximum m is 2^32-1. It is an error to encode a length greater than the specified maximum.

wire-format §3.14

Structure encodes its component declarations sequentially in declaration order; each component is a multiple of four bytes.

wire-format §3.13

Variable-length array (type-name identifier<m>) encodes a 4-byte unsigned element count n followed by the n elements in order. Default maximum m is 2^32-1. It is an error to encode n greater than the specified maximum.

wire-format §3.10

Variable-length opaque data (opaque identifier<m>) encodes a 4-byte unsigned integer length n, followed by n data bytes, followed by 0–3 zero padding bytes. Default maximum m is 2^32-1. It is an error to encode a length greater than the specified maximum.

wire-format §3.1

XDR signed integer is a 32-bit, big-endian, two's complement datum encoding values in [-2147483648, 2147483647]; most significant byte is byte 0, least significant is byte 3.

wire-format §3.2

XDR unsigned integer is a 32-bit, big-endian unsigned binary number encoding values in [0, 4294967295]; most significant byte is byte 0, least significant is byte 3.