Function encapsulation_header 

pub fn encapsulation_header(
    encoding: Encoding,
    endianness: Endianness,
    little: bool,
    padding: u8,
) -> [u8; 4]

The encapsulation header for an encoding and byte order.

DDSI-RTPS 2.5 §10.5 and XTypes 1.3 §7.4.1.1: the identifier, then two option bytes carrying the payload’s trailing padding count.

The options field is not decoration

§7.6.3.1.2 makes the low two bits of the second options byte the number of padding bytes at the end of the serialized data, and says they “shall be interpreted by the receiver to determine where the serialized data exactly ended”. Leaving them zero over a padded payload tells a receiver that reads them that the padding is data.

Measured on the loopback wire on 2026-08-09, @final struct One { octet a; } with a = 0xAB, captured with tshark:

cyclone   CDR_LE  options 0x0003  serializedData ab000000
rti       CDR_LE  options 0x0003  serializedData ab000000
fastdds   CDR_LE  options 0x0003  serializedData ab000000

and @final struct TypeB { short a; char b; } — §7.6.3.1.2’s own example — through Cyclone: options 0x0001, serializedData 23006200. Fast CDR 2.3.5 Cdr::set_dds_cdr_options computes the same count for bodies of 1, 2, 3 and 4 bytes (3, 2, 1, 0), and Cyclone’s dds_serdata_default.c writes ddsrt_toBE2u(pad) into hdr.options and reads the data back as d->pos - pad.

RTI’s static Plugin_serialize_to_cdr_buffer_ex leaves the field zero and does not pad; its RTPS layer sets both, which is what the capture above shows. The field belongs to the encapsulated form, so Emit::Payload — the unpadded serialized data, which is what every row of vendor_bytes.md records — is unaffected.

The word is big-endian like the identifier: Cyclone writes ddsrt_toBE2u, Fast CDR serialises options_[0] then options_[1] whatever the payload’s order, and both put the count in the second byte.