Bits in XDR

Bits in XDR RiverExplorer LLC

848 N. Rainbow Blvd, Ste-1120 Las Vegas Nevada 89107 US +1-208-806-1358 DouglasRoyer@gmail.com https://DougRoyer.US

General Internet Engineering Task Force XDR bit This is an extension to the XDR specification to allow for bits to be described and sent. With protocols that have a large number of boolean values the existing standard requires each to be individually packed into a 32-bit value. This addition does not alter any existing XDR data streams or effect existing implementations.

This specification describes how to pack a bit-boolean and short bit-width data values into the 32-bit XDR block chunks.
And this specification describes how to describe them by extending "The XDR Language Specification" to include bits.
And a new namespace declaration type is specified to aid in the reduction of name collisions in large projects.

While in draft status, a new Open Source XDR generation tool is being developed .

Introduction Definitions:

A value with 2 or more bits is called a bit-value. A bit-value value can be signed or unsigned. They often represent a set of possible conditions and not a numeric value and would be unsigned. And in other usages, the bits could represent a positive or negative value.
A single bit value is called a bit-boolean. A bit-boolean is a single bit representing a true or false value. A bit-boolean by itself has no sign. Up to 32 bit-boolean fit in a 32-bit XDR block.
A scope is a way of extending a name of a item to uniquely identify it. As an example, file A variable 'a' and file B variable 'a' can be difficult to uniquely identify in code. By adding a 'namespace A' and a second 'namespace B', they can then be identified with 'A:a' and 'B:a'.

All multi bit width values are placed into network byte order the same as their 32-bit or wider values as described in XDR .

The XDR Bit Language Specification With an large amount of bits and data packets it is easier to have name collisions between generated object. For this reason a new 'namespace' declaration' type is specified in A new RFC-XDR type-specifier of 'bitobject' is added to the one shown in . Resulting in 'type-specifier' becoming:

Extended type-specifier ABNF The properties of a bitobject are:

A bitobject only consists of one or more of:
- A signed integer value: "sbits"
- An unsigned integer value: "ubits"
- A boolean "bit"
Floating point numbers would be transmitted as a float value as already described in as they have a sign, exponent and a mantissa. No floating value is defined in a bitobject.
Unused bits are set to zero (0).
All bit widths that exceed 32-bits would be placed into two or more bitobject values. With the ones containing the most significant bits sent first and the one with the least signification bits sent last.
A bitobject does not need to define 32-bits of data. The undefined bits are at the most significant end of the 32-bits object and and are set to zero.
All type-specifier objects are at least 32-bits wide which means that "sbits", "ubits", or "bit" can never occupy a 32-bit XDR block with a type-specifier.
A 32-bit wide "sbits" is the same as a signed integer. Except when they span 32-bit blocks. See .
A 32-bit wide "ubits" is the same as a unsigned integer. Except when they span 32-bit blocks. See .

bitobject ABNF is one example of a bitobject. that is 32-bits wide.

Multiple Bits Example Example uses 11 bit-boolean values and would be transmitted in one 32-bit block.

Flags Example Example contains two 42 bit-boolean values and would be transmitted in three 32-bit blocks.

Wider than 32 bit example: In some cases, like in "AssemblyLineStatus" and in "Trajectory", the bits could represent the output of a hardware device where the bits are defined by a manufacturer. And in other cases the bits could be logical software flags that have a predefined bit-position in a bit stream as exampled in .

Packing Bits The bit-boolean and bit-value objects are processed from the top to the bottom as shown in their bitobject XDR language definition. The top most value would be packed into the least significant bits. The second from the top value would be placed next to it, and so on. bit-values are converted to network byte order and then bit packed. And a caution to the implementors for signed bit-value data. Many computer languages will convert a narrower bit value into a wider bit value and move the sign bit to the most significant position. So when preparing a signed bit-value, be sure to clamp the value and adjust the sign to the correct bit position before packing the bits. This would apply to "sbits" and not "ubits".

Packing bit-boolean This is how the XDR Language bitobject "EmailStatus" in would be packed. "EmailStatus" is a bitobject that only contains bit-boolean values.

How would be packed. bit-object EmailStatus { bit Seen; ----------------------------------------------------+ bit Answered; ----------------------------------------------+ | bit Flagged; ---------------------------------------------+ | | bit Deleted; -------------------------------------------+ | | | bit Draft; -------------------------------------------+ | | | | bit Recent; ----------------------------------------+ | | | | | bit Forwarded; -----------------------------------+ | | | | | | bit Ignored; -----------------------------------+ | | | | | | | bit Watched; ---------------------------------+ | | | | | | | | bit Shared; --------------------------------+ | | | | | | | | | bit ReadOnly; ----------------------------+ | | | | | | | | | | }; | | | | | | | | | | | | | | | | | | | | | | V V V V V V V V V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Most Significant Bits Least significant Bits unused bits in this example. | | '---------------------------. .-------------------------------' | 32-bits wide

Packing bit-values This example has both bit-boolean and bit-value data being packed together. Here is how the XDR Language bitobject "AssemblyLineStatus" shown in would be packed:

How would be packed. bit-object AssemblyLineStatus { bit LightOn; ----------------------------------------------. ubits Status:3; -----------------------------------------. | ubits SwitchPosition:4; --------------------------. | | sbits Rotation:10; ------------------. | | | bit Active; ----------------. | | | | ubits UnitsPerMinute:8; ---. | | | | | ubits UnitID:5; ---. | | | | | | }; | / | | | | | | / | | | | | .-------------' / | | | | | | | | | | | | | .---' .--' | | | | | | | | | | | .--+--. .------+----. | .--------+------. .-+-. .+. | | | | | | | | | | | | | v v v v v v v v v v v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Most Significant Bits Least significant Bits | | '---------------------------. .-------------------------------' | 32-bits wide

Packing wider than 32-bit-values or spanning blocks This shows how to pack values that are wider than 32-bits. The values would be converted to network byte order like with Hyper Integer and Unsigned Hyper Integer values. With their values clamped to the width defined and sbits values having their sign at their own most significant bit position. Here is how the XDR Language bitobject "Trajectory" shown in would be packed into three 32-bit XDR blocks:

Trajectory - shown again bit-object Trajectory { ubits Velocity:42; sbits VectorX:14; sbits VectorY:14; sbits VectorZ:14; };

Most significant 32-bit block of "Trajectory"

11 unused bits set to zero (0).
14-bit "VectorZ:14"
The most significant 7 bits of 14-bit "VectorY:14"

How "Trajectory" most signification 32-bit block would be packed. Most significant 7-bits of 14-bit VectorZ:14 VectorY:14 | | .----------' '------------. .----' '---. | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0|0|0|0| | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Most significant of 32-bits Least signification of 32-bits | | '---------------------------. .-------------------------------' | 32-bits wide Most significant 32-bit block -----------------------------

How "Trajectory" middle signification 32-bit block would be packed. The middle signification 32-bit block of "Trajectory" would have:

The least significant 7 bits of 14-bit "VectorY:14.
14-bit "VectorX:14"
The most significant 10 bits of 42-bit "Velocity:42"

How "Trajectory" middle signification 32-bit block would be packed. Least significant Most significant 7-bits of 10-bits of VectorY:14 14-bit VectorX:14 Velocity:42 | | | .----' '------. .-----------' '-----------. .-------' '-------. | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Most significant of 32-bits Least signification of 32-bits | | '---------------------------. .-------------------------------' | 32-bits wide Middle significant 32-bit block -------------------------------

How "Trajectory" least signification 32-bit block would be packed.

How "Trajectory" least signification 32-bit block would be packed. Lest significant 32-bits of Velocity:42 | .---------------------------' '-------------------------------. | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Most Significant Bits Least significant Bits | | '---------------------------. .-------------------------------' | 32-bits wide Least significant 32-bit block ------------------------------

Reducing Namespace Collision in Generated Code When gathering specifications and definitions from multiple specifications it can be much more convenient to be able to name each identifier in a way the most resembles the original specification. However it can be confusing to uniquely identify them in generated code, and match them up to the XDR Language file that generated them. For this reason a new 'namespace' declaration type is being defined.

namespace declaration type A namespace may have several scope levels. Each scope name separated by a colon (:). As each 'namespace' is encountered, all objects that follow will be in that scoped namespace. Zero or more 'namespaces' declarations may be in one XDR Language source. 'declaration' is modified to:

namespace type-specifier Multiple namespaces in one definition could look like this:

Namespace Example The result would be two 'Status' data types. They are similar, and unique. Perhaps they came from different specifications. And each uniquely identifiable by their scope. And the variables produced could be referenced with:

'MyCompany:LaunchPad:Status'
'MyCompany:Projectile:Status'

This also makes it easier to identify an object in an XDR union: Multiple namespaces used in one definition could look like this:

Namespace Example

IANA Considerations This memo includes no request to IANA. [CHECK]

Security Considerations This document should not affect the security of the Internet. [CHECK]

Normative References XDR: External Data Representation Standard This document describes the External Data Representation Standard (XDR) protocol as it is currently deployed and accepted. This document obsoletes RFC 1832. [STANDARDS-TRACK] Informative References XDR Code Generator, Open Source RiverExplorer LLC

Appendix 1 Full XDR Language Grammar TODO

Acknowledgments

Contributors