OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0
Part 1: Types

OASIS Standard

29 October 2012

Specification URIs

This version:

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-complete-v1.0-os.pdf

Previous version:

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-types-v1.0-csprd01.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-types-v1.0-csprd01.html

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-complete-v1.0-csprd01.pdf

Latest version:

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-types-v1.0.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-types-v1.0.html

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf

Technical Committee:

OASIS Advanced Message Queuing Protocol (AMQP) TC

Chairs:

Ram Jeyaraman (Ram.Jeyaraman@microsoft.com), Microsoft

Angus Telfer (angus.telfer@inetco.com), INETCO Systems

Editors:

Robert Godfrey (robert.godfrey@jpmorgan.com), JPMorgan Chase & Co.

David Ingham (David.Ingham@microsoft.com), Microsoft

Rafael Schloming (rafaels@redhat.com), Red Hat

Additional artifacts:

This specification consists of the following documents:

·        Part 0: Overview - Overview of the AMQP specification

·        Part 1: Types (this document) - AMQP type system and encoding

·        Part 2: Transport - AMQP transport layer

·        Part 3: Messaging - AMQP Messaging Layer

·        Part 4: Transactions - AMQP Transactions Layer

·        Part 5: Security - AMQP Security Layers

·        XML Document Type Definition (DTD)

Related work:

This specification replaces or supersedes:

·        AMQP v1.0 Final, 07 October 2011. http://www.amqp.org/specification/1.0/amqp-org-download

Abstract:

The Advanced Message Queuing Protocol (AMQP) is an open internet protocol for business messaging. It defines a binary wire-level protocol that allows for the reliable exchange of business messages between two parties. AMQP has a layered architecture and the specification is organized as a set of parts that reflects that architecture. Part 1 defines the AMQP type system and encoding. Part 2 defines the AMQP transport layer, an efficient, binary, peer-to-peer protocol for transporting messages between two processes over a network. Part 3 defines the AMQP message format, with a concrete encoding. Part 4 defines how interactions can be grouped within atomic transactions. Part 5 defines the AMQP security layers.

Status:

This document was last revised or approved by the membership of OASIS on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee's email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/comments/amqp/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/amqp/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[amqp-core-types-v1.0]

OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0 Part 1: Types. 29 October 2012. OASIS Standard. http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-types-v1.0-os.html.


Notices

Copyright © OASIS Open 2012. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication 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 OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/policies-guidelines/trademark for above guidance.


Table of Contents



1.1 Type System
      1.1.1 Primitive Types
      1.1.2 Described Types
      1.1.3 Composite Types
      1.1.4 Restricted Types
1.2 Type Encodings
      1.2.1 Fixed Width
      1.2.2 Variable Width
      1.2.3 Compound
      1.2.4 Array
1.3 Type Notation
      1.3.1 Primitive Type Notation
      1.3.2 Composite Type Notation
      1.3.3 Descriptor Notation
      1.3.4 Field Notation
      1.3.5 Restricted Type Notation
1.4 Composite Type Representation
1.5 Descriptor Values
1.6 Primitive Type Definitions
      1.6.1 Null
      1.6.2 Boolean
      1.6.3 Ubyte
      1.6.4 Ushort
      1.6.5 Uint
      1.6.6 Ulong
      1.6.7 Byte
      1.6.8 Short
      1.6.9 Int
      1.6.10 Long
      1.6.11 Float
      1.6.12 Double
      1.6.13 Decimal32
      1.6.14 Decimal64
      1.6.15 Decimal128
      1.6.16 Char
      1.6.17 Timestamp
      1.6.18 Uuid
      1.6.19 Binary
      1.6.20 String
      1.6.21 Symbol
      1.6.22 List
      1.6.23 Map
      1.6.24 Array

1.1 Type System

The AMQP type system defines a set of commonly used primitive types for interoperable data representation. AMQP values can be annotated with additional semantic information beyond that associated with the primitive type. This allows for the association of an AMQP value with an external type that is not present as an AMQP primitive. For example, a URL is commonly represented as a string, however not all strings are valid URLs, and many programming languages and/or applications define a specific type to represent URLs. The AMQP type system would allow for the definition of a code with which to annotate strings when the value is intended to represent a URL.

1.1.1 Primitive Types

The AMQP type system defines a standard set of primitive types for representing both common scalar values and common collections. The scalar types include booleans, integral numbers, floating point numbers, timestamps, UUIDs, characters, strings, binary data, and symbols. The collection types include arrays (monomorphic), lists (polymorphic), and maps.

1.1.2 Described Types

The primitive types defined by AMQP can directly represent many of the basic types present in most popular programming languages, and therefore can be trivially used to exchange basic data. In practice, however, even the simplest applications have their own set of custom types used to model concepts within the application's domain. In messaging applications these custom types need to be externalized for transmission.

AMQP provides a means to do this by allowing any AMQP type to be annotated with a descriptor. A descriptor forms an association between a custom type, and an AMQP type. This association indicates that the AMQP type is actually a representation of the custom type. The resulting combination of the AMQP type and its descriptor is referred to as a described type.

A described type contains two distinct kinds of type information. It identifies both an AMQP type and a custom type (as well as the relationship between them), and so can be understood at two different levels. An application with intimate knowledge of a given domain can understand described types as the custom types they represent, thereby decoding and processing them according to the complete semantics of the domain. An application with no intimate knowledge can still understand the described types as AMQP types, decoding and processing them as such.

1.1.3 Composite Types

AMQP defines a number of composite types used for encoding structured data such as frame bodies. A composite type defines a composite value where each constituent value is identified by a well-known named field. Each composite type definition includes an ordered sequence of fields, each with a specified name, type, and multiplicity. Composite type definitions also include one or more descriptors (symbolic and/or numeric) for identifying their defined representations. Composite types are formally defined using the XML notation defined in section 1.3.

1.1.4 Restricted Types

AMQP defines the notion of a restricted type. This is a new type derived from an existing type where the permitted values of the new type are a subset of the values of the existing type. Restricted types are commonly used programming constructs, the most frequent being "enumerations" which in AMQP terminology are restrictions of the integral types. However, the AMQP notion of restricted types can also represent more open ended restrictions such as a URL which can be thought of as a restriction of the string type.

A restricted type definition might limit the permitted values to either a pre-defined fixed set, or an open-ended set. In the former case, each permitted value is called a choice and all possible choices are listed in the formal type definition. In the latter case, the nature of the restriction is specified as text in the formal type definition.

The existing type from which a restricted type is derived is referred to as the source type for the restriction. A restricted type might or might not be annotated with a descriptor on the wire depending on the formal definition for the type.

1.2 Type Encodings

An AMQP encoded data stream consists of untyped bytes with embedded constructors. The embedded constructor indicates how to interpret the untyped bytes that follow. Constructors can be thought of as functions that consume untyped bytes from an open ended byte stream and construct a typed value. An AMQP encoded data stream always begins with a constructor.

Figure 1.1: Primitive Format Code (String)
constructor untyped bytes | | +--+ +-----------------+-----------------+ | | | | ... 0xA1 0x1E "Hello Glorious Messaging World" ... | | | | | | | | utf8 bytes | | | | | | | # of data octets | | | | | +-----------------+-----------------+ | | | string value encoded according | to the str8-utf8 encoding | primitive format code for the str8-utf8 encoding

An AMQP constructor consists of either a primitive format code, or a described format code. A primitive format code is a constructor for an AMQP primitive type. A described format code consists of a descriptor and a primitive format-code. A descriptor defines how to produce a domain specific type from an AMQP primitive value.

Figure 1.2: Described Format Code (URL)
constructor untyped bytes | | +-----------+-----------+ +-----------------+-----------------+ | | | | ... 0x00 0xA1 0x03 "URL" 0xA1 0x1E "http://example.org/hello-world" ... | | | | | +------+------+ | | | | | | | descriptor | +------------------+----------------+ | | | string value encoded according | to the str8-utf8 encoding | primitive format code for the str8-utf8 encoding (Note: this example shows a string-typed descriptor, which is considered reserved)

The descriptor portion of a described format code is itself any valid AMQP encoded value, including other described values. The formal BNF for constructors is given below.

Figure 1.3: Constructor BNF
constructor = format-code / %x00 descriptor constructor format-code = fixed / variable / compound / array fixed = empty / fixed-one / fixed-two / fixed-four / fixed-eight / fixed-sixteen variable = variable-one / variable-four compound = compound-one / compound-four array = array-one / array-four descriptor = value value = constructor untyped-bytes untyped-bytes = *OCTET ; this is not actually *OCTET, the ; valid byte sequences are restricted ; by the constructor ; fixed width format codes empty = %x40-4E / %x4F %x00-FF fixed-one = %x50-5E / %x5F %x00-FF fixed-two = %x60-6E / %x6F %x00-FF fixed-four = %x70-7E / %x7F %x00-FF fixed-eight = %x80-8E / %x8F %x00-FF fixed-sixteen = %x90-9E / %x9F %x00-FF ; variable width format codes variable-one = %xA0-AE / %xAF %x00-FF variable-four = %xB0-BE / %xBF %x00-FF ; compound format codes compound-one = %xC0-CE / %xCF %x00-FF compound-four = %xD0-DE / %xDF %x00-FF ; array format codes array-one = %xE0-EE / %xEF %x00-FF array-four = %xF0-FE / %xFF %x00-FF

Format codes map to one of four different categories: fixed width, variable width, compound and array. Values encoded within each category share the same basic structure parameterized by width. The subcategory within a format-code identifies both the category and width.

Fixed Width

The size of fixed-width data is determined based solely on the subcategory of the format code for the fixed width value.

Variable Width

The size of variable-width data is determined based on an encoded size that prefixes the data. The width of the encoded size is determined by the subcategory of the format code for the variable width value.

Compound

Compound data is encoded as a size and a count followed by a polymorphic sequence of count constituent values. Each constituent value is preceded by a constructor that indicates the semantics and encoding of the data that follows. The width of the size and count is determined by the subcategory of the format code for the compound value.

Array

Array data is encoded as a size and count followed by an array element constructor followed by a monomorphic sequence of values encoded according to the supplied array element constructor. The width of the size and count is determined by the subcategory of the format code for the array.

The bits within a format code can be interpreted according to the following layout:

Figure 1.4: Format Code Layout
Bit: 7 6 5 4 3 2 1 0 +------------------------------------+ +----------+ | subcategory | subtype | | ext-type | +------------------------------------+ +----------+ 1 octet 1 octet | | +-------------------------------------------------+ | format-code ext-type: only present if subtype is 0xF

The following table describes the subcategories of format-codes:

Figure 1.5: Subcategory Formats
Subcategory Category Format ============================================================================== 0x4 Fixed Width Zero octets of data. 0x5 Fixed Width One octet of data. 0x6 Fixed Width Two octets of data. 0x7 Fixed Width Four octets of data. 0x8 Fixed Width Eight octets of data. 0x9 Fixed Width Sixteen octets of data. 0xA Variable Width One octet of size, 0-255 octets of data. 0xB Variable Width Four octets of size, 0-4294967295 octets of data. 0xC Compound One octet each of size and count, 0-255 distinctly typed values. 0xD Compound Four octets each of size and count, 0-4294967295 distinctly typed values. 0xE Array One octet each of size and count, 0-255 uniformly typed values. 0xF Array Four octets each of size and count, 0-4294967295 uniformly typed values.

Please note, unless otherwise specified, AMQP uses network byte order for all numeric values.

1.2.1 Fixed Width

The width of a specific fixed width encoding can be computed from the subcategory of the format code for the fixed width value:

Figure 1.6: Layout of Fixed Width Data Encodings
n OCTETs +----------+ | data | +----------+ Subcategory n ================= 0x4 0 0x5 1 0x6 2 0x7 4 0x8 8 0x9 16

1.2.2 Variable Width

All variable width encodings consist of a size in octets followed by size octets of encoded data. The width of the size for a specific variable width encoding can be computed from the subcategory of the format code:

Figure 1.7: Layout of Variable Width Data Encodings
n OCTETs size OCTETs +----------+-------------+ | size | value | +----------+-------------+ Subcategory n ================= 0xA 1 0xB 4

1.2.3 Compound

All compound encodings consist of a size and a count followed by count encoded items. The width of the size and count for a specific compound encoding can be computed from the category of the format code:

Figure 1.8: Layout of Compound Data Encodings
+----------= count items =----------+ | | n OCTETs n OCTETs | | +----------+----------+--------------+------------+-------+ | size | count | ... /| item |\ ... | +----------+----------+------------/ +------------+ \-----+ / / \ \ / / \ \ / / \ \ +-------------+----------+ | constructor | data | +-------------+----------+ Subcategory n ================= 0xC 1 0xD 4

1.2.4 Array

All array encodings consist of a size followed by a count followed by an element constructor followed by count elements of encoded data formated as REQUIRED by the element constructor:

Figure 1.9: Layout of Array Encodings
+--= count elements =--+ | | n OCTETs n OCTETs | | +----------+----------+---------------------+-------+------+-------+ | size | count | element-constructor | ... | data | ... | +----------+----------+---------------------+-------+------+-------+ Subcategory n ================= 0xE 1 0xF 4

1.3 Type Notation

Types are formally specified using an XML notation described below. Please note that this XML notation is used only to define the type and is never used to represent encoded data. All encoded AMQP data is binary as described in section 1.2.

The type element formally defines a semantic type used to exchange data on the wire. Every type definition has the following general form. The child elements present depend upon the class of the type definition (primitive, composite, or restricted):

Figure 1.10: Type Definitions
<type class="primitive|composite|restricted" name="..." label="..." provides="..."> ... </type>

The attributes of a type definition specify the following:

name

The name of the type.

label

A short description of the type.

class

A string identifying what class of type is being defined: "primitive", "composite", or "restricted".

provides

A comma separated list of archetypes (see field element).

There are three different classes of types identified by the "class" attribute: primitive, composite, and restricted.

1.3.1 Primitive Type Notation

A "primitive" type definition will contain one or more encoding elements that describe how the data is formatted on the wire. Primitive types do not contain the descriptor, field, or choice elements.

Figure 1.11: Primitive Type Definitions
<type class="primitive" name="..." label="..." provides="..."> <encoding ... > ... </encoding> ... <encoding ... > ... </encoding> </type>

The encoding element defines how a primitive type is encoded. The specification defines 4 general categories of encodings: fixed, variable, compound, and array. A specific encoding provides further details of how data is formatted within its general category.

Figure 1.12: Encoding Definitions
<type class="primitive" ... > ... <encoding name="..." code="0xNN" category="fixed|variable|compound|array" width="N" label="..."/> ... </type>
name

The name of the encoding.

label

A short description of the encoding.

code

The numeric value that prefixes the encoded data on the wire.

category

The category of the encoding: "fixed", "variable", "compound", or "array".

width

The width of the encoding or the size/count prefixes depending on the category.

1.3.2 Composite Type Notation

A "composite" type definition specifies a new kind of record type, i.e., a type composed of a fixed number of fields whose values are each of a specific type. A composite type does not have a new encoding, but is sent on the wire as a list annotated by a specific descriptor value that identifies it as a representation of the defined composite type. A composite type definition will contain a descriptor and zero or more field elements. Composite types do not contain encoding or choice elements. The source attribute of a composite type will always be "list", other values are reserved for future use.

Figure 1.13: Composite Type Definitions
<type class="composite" name="..." label="..." provides="..."> <descriptor name="..." code="..."/> <field name="..." ... > ... </field> ... <field name="..." ... > ... </field> </type>

1.3.3 Descriptor Notation

The descriptor element specifies what annotation is used to identify encoded values as representations of a described type.

Figure 1.14: Descriptor Definitions
<type class="composite|restricted" ...> ... <!-- domain-id:descriptor-id --> <descriptor name="domain:name" code="0xNNNNNNNN:0xNNNNNNNN"/> ... </type>
name

A symbolic name for the representation.

code

The numeric value.

1.3.4 Field Notation

The field element identifies a field within a composite type. Every field has the following attributes:

Figure 1.15: Field Definitions
<type class="composite" ...> ... <field name="..." type="..." requires="..." default="..." label="..." mandatory="true|false" multiple="true|false" /> ... </type>
name

A name that uniquely identifies the field within the type.

type

The type of the field. This attribute defines the range of values that are permitted to appear in this field. It might name a specific type, in which case the values are restricted to that type, or it might be the special character "*", in which case a value of any type is permitted. In the latter case the range of values might be further restricted by the requires attribute.

requires

A comma separated list of archetypes. Field values are restricted to types providing at least one of the specified archetypes.

default

A default value for the field if no value is encoded.

label

A short description of the field.

mandatory

"true" iff a non null value for the field is always encoded.

multiple

"true" iff the field can have multiple values of its specified type.

1.3.5 Restricted Type Notation

A "restricted" type definition specifies a new kind of type whose values are restricted to a subset of the values that might be represented with another type. The source attribute identifies the base type from which a restricted type is derived. A restricted type can have a descriptor element in which case it is identified by a descriptor on the wire. The values permitted by a restricted type can be specified either via documentation, or directly limited to a fixed number of values by the choice elements contained within the definition.

Figure 1.16: Restricted Type Definitions
<type class="restricted" name="..." label="..." provides="..."> <descriptor name="..." code="..."/> <choice name="..." value="..."/> ... <choice name="..." value="..."/> </type>

The choice element identifies a legal value for a restricted type. The choice element has the following attributes:

Figure 1.17: Choice Definitions
<type class="restricted" ...> ... <choice name="..." value="..."/> ... </type>
name

A name for the value.

value

The permitted value.

1.4 Composite Type Representation

AMQP composite types are represented as a described list. Each element in the list is positionally correlated with the fields listed in the composite type definition. The permitted element values are determined by the type specification and multiplicity of the corresponding field definitions. When the trailing elements of the list representation are null, they MAY be omitted. The descriptor of the list indicates the specific composite type being represented.

Figure 1.18: Example Composite Type
<type class="composite" name="book" label="example composite type"> <doc> <p>An example composite type.</p> </doc> <descriptor name="example:book:list" code="0x00000003:0x00000002"/> <field name="title" type="string" mandatory="true" label="title of the book"/> <field name="authors" type="string" multiple="true"/> <field name="isbn" type="string" label="the ISBN code for the book"/> </type>

The mandatory attribute of a field description controls whether a null element value is permitted in the representation.

The multiple attribute of a field description controls whether multiple element values are permitted in the representation. A single element of the type specified in the field description is always permitted. Multiple values are represented by the use of an array where the type of the elements in the array is the type defined in the field definition. Note that a null value and a zero-length array (with a correct type for its elements) both describe an absence of a value and MUST be treated as semantically identical.

A field which is defined as both multiple and mandatory MUST contain at least one value (i.e. for such a field both null and an array with no entries are invalid).

The described list shown below is an example composite value of the book type defined above. A trailing null element corresponding to the absence of an ISBN value is depicted in the example, but can optionally be omitted according to the encoding rules.

Figure 1.19: Example Composite Value
constructor list representation of a book | | +-----------------+-------------------+ +-------------+---------------+ | | | | 0x00 0xA3 0x11 "example:book:list" 0xC0 0x40 0x03 title authors isbn | | | | | | identifies composite type | | | | | | 0x40 sym8 +----------------------+ | | (symbol) | | null value +--------------+----------------+ | | | | 0xA1 0x15 "AMQP for & by Dummies" | | +------------------------------------------------------------+-----+ | | 0xE0 0x25 0x02 0xA1 0x0E "Rob J. Godfrey" 0x13 "Rafael H. Schloming" | | | | | | | size | | +---------+---------+ +-----------+------------+ | | | | count | first element second element | element constructor

1.5 Descriptor Values

Descriptor values other than symbolic (symbol) or numeric (ulong) are, while not syntactically invalid, reserved - this includes numeric types other than ulong. To allow for users of the type system to define their own descriptors without collision of descriptor values, an assignment policy for symbolic and numeric descriptors is given below.

The namespace for both symbolic and numeric descriptors is divided into distinct domains. Each domain has a defined symbol and/or 4 byte numeric id assigned by the AMQP working group. For numeric ids the assigned domain-id will be equal to the IANA Private Enterprise Number (PEN) of the requesting organisation [IANAPEN] with domain-id 0 reserved for descriptors defined in the AMQP specification.

Descriptors are then assigned within each domain according to the following rules:

symbolic descriptors

<domain>:<name>

numeric descriptors

(domain-id << 32) | descriptor-id

1.6 Primitive Type Definitions

1.6.1 null

Indicates an empty value.

<type name="null" class="primitive"> <encoding code="0x40" category="fixed" width="0" label="the null value"/> </type>

1.6.2 boolean

Represents a true or false value.

<type name="boolean" class="primitive"> <encoding code="0x56" category="fixed" width="1" label="boolean with the octet 0x00 being false and octet 0x01 being true"/> <encoding name="true" code="0x41" category="fixed" width="0" label="the boolean value true"/> <encoding name="false" code="0x42" category="fixed" width="0" label="the boolean value false"/> </type>

1.6.3 ubyte

Integer in the range 0 to 2^8 - 1 inclusive.

<type name="ubyte" class="primitive"> <encoding code="0x50" category="fixed" width="1" label="8-bit unsigned integer"/> </type>

1.6.4 ushort

Integer in the range 0 to 2^16 - 1 inclusive.

<type name="ushort" class="primitive"> <encoding code="0x60" category="fixed" width="2" label="16-bit unsigned integer in network byte order"/> </type>

1.6.5 uint

Integer in the range 0 to 2^32 - 1 inclusive.

<type name="uint" class="primitive"> <encoding code="0x70" category="fixed" width="4" label="32-bit unsigned integer in network byte order"/> <encoding name="smalluint" code="0x52" category="fixed" width="1" label="unsigned integer value in the range 0 to 255 inclusive"/> <encoding name="uint0" code="0x43" category="fixed" width="0" label="the uint value 0"/> </type>

1.6.6 ulong

Integer in the range 0 to 2^64 - 1 inclusive.

<type name="ulong" class="primitive"> <encoding code="0x80" category="fixed" width="8" label="64-bit unsigned integer in network byte order"/> <encoding name="smallulong" code="0x53" category="fixed" width="1" label="unsigned long value in the range 0 to 255 inclusive"/> <encoding name="ulong0" code="0x44" category="fixed" width="0" label="the ulong value 0"/> </type>

1.6.7 byte

Integer in the range -(2^7) to 2^7 - 1 inclusive.

<type name="byte" class="primitive"> <encoding code="0x51" category="fixed" width="1" label="8-bit two's-complement integer"/> </type>

1.6.8 short

Integer in the range -(2^15) to 2^15 - 1 inclusive.

<type name="short" class="primitive"> <encoding code="0x61" category="fixed" width="2" label="16-bit two's-complement integer in network byte order"/> </type>

1.6.9 int

Integer in the range -(2^31) to 2^31 - 1 inclusive.

<type name="int" class="primitive"> <encoding code="0x71" category="fixed" width="4" label="32-bit two's-complement integer in network byte order"/> <encoding name="smallint" code="0x54" category="fixed" width="1" label="8-bit two's-complement integer"/> </type>

1.6.10 long

Integer in the range -(2^63) to 2^63 - 1 inclusive.

<type name="long" class="primitive"> <encoding code="0x81" category="fixed" width="8" label="64-bit two's-complement integer in network byte order"/> <encoding name="smalllong" code="0x55" category="fixed" width="1" label="8-bit two's-complement integer"/> </type>

1.6.11 float

32-bit floating point number (IEEE 754-2008 binary32).

<type name="float" class="primitive"> <encoding name="ieee-754" code="0x72" category="fixed" width="4" label="IEEE 754-2008 binary32"/> </type>

A 32-bit floating point number (IEEE 754-2008 binary32 [IEEE754]).

1.6.12 double

64-bit floating point number (IEEE 754-2008 binary64).

<type name="double" class="primitive"> <encoding name="ieee-754" code="0x82" category="fixed" width="8" label="IEEE 754-2008 binary64"/> </type>

A 64-bit floating point number (IEEE 754-2008 binary64 [IEEE754]).

1.6.13 decimal32

32-bit decimal number (IEEE 754-2008 decimal32).

<type name="decimal32" class="primitive"> <encoding name="ieee-754" code="0x74" category="fixed" width="4" label="IEEE 754-2008 decimal32 using the Binary Integer Decimal encoding"/> </type>

A 32-bit decimal number (IEEE 754-2008 decimal32 [IEEE754]).

1.6.14 decimal64

64-bit decimal number (IEEE 754-2008 decimal64).

<type name="decimal64" class="primitive"> <encoding name="ieee-754" code="0x84" category="fixed" width="8" label="IEEE 754-2008 decimal64 using the Binary Integer Decimal encoding"/> </type>

A 64-bit decimal number (IEEE 754-2008 decimal64 [IEEE754]).

1.6.15 decimal128

128-bit decimal number (IEEE 754-2008 decimal128).

<type name="decimal128" class="primitive"> <encoding name="ieee-754" code="0x94" category="fixed" width="16" label="IEEE 754-2008 decimal128 using the Binary Integer Decimal encoding"/> </type>

A 128-bit decimal number (IEEE 754-2008 decimal128 [IEEE754]).

1.6.16 char

A single Unicode character.

<type name="char" class="primitive"> <encoding name="utf32" code="0x73" category="fixed" width="4" label="a UTF-32BE encoded Unicode character"/> </type>

A UTF-32BE encoded Unicode character [UNICODE6].

1.6.17 timestamp

An absolute point in time.

<type name="timestamp" class="primitive"> <encoding name="ms64" code="0x83" category="fixed" width="8" label="64-bit two's-complement integer representing milliseconds since the unix epoch"/> </type>

Represents an approximate point in time using the Unix time_t [IEEE1003] encoding of UTC, but with a precision of milliseconds. For example, 1311704463521 represents the moment 2011-07-26T18:21:03.521Z.

1.6.18 uuid

A universally unique identifier as defined by RFC-4122 section 4.1.2 .

<type name="uuid" class="primitive"> <encoding code="0x98" category="fixed" width="16" label="UUID as defined in section 4.1.2 of RFC-4122"/> </type>

UUID is defined in section 4.1.2 of RFC-4122 [RFC4122].

1.6.19 binary

A sequence of octets.

<type name="binary" class="primitive"> <encoding name="vbin8" code="0xa0" category="variable" width="1" label="up to 2^8 - 1 octets of binary data"/> <encoding name="vbin32" code="0xb0" category="variable" width="4" label="up to 2^32 - 1 octets of binary data"/> </type>

1.6.20 string

A sequence of Unicode characters.

<type name="string" class="primitive"> <encoding name="str8-utf8" code="0xa1" category="variable" width="1" label="up to 2^8 - 1 octets worth of UTF-8 Unicode (with no byte order mark)"/> <encoding name="str32-utf8" code="0xb1" category="variable" width="4" label="up to 2^32 - 1 octets worth of UTF-8 Unicode (with no byte order mark)"/> </type>

A string represents a sequence of Unicode characters as defined by the Unicode V6.0.0 standard [UNICODE6].

1.6.21 symbol

Symbolic values from a constrained domain.

<type name="symbol" class="primitive"> <encoding name="sym8" code="0xa3" category="variable" width="1" label="up to 2^8 - 1 seven bit ASCII characters representing a symbolic value"/> <encoding name="sym32" code="0xb3" category="variable" width="4" label="up to 2^32 - 1 seven bit ASCII characters representing a symbolic value"/> </type>

Symbols are values from a constrained domain. Although the set of possible domains is open-ended, typically the both number and size of symbols in use for any given application will be small, e.g. small enough that it is reasonable to cache all the distinct values. Symbols are encoded as ASCII characters [ASCII].

1.6.22 list

A sequence of polymorphic values.

<type name="list" class="primitive"> <encoding name="list0" code="0x45" category="fixed" width="0" label="the empty list (i.e. the list with no elements)"/> <encoding name="list8" code="0xc0" category="compound" width="1" label="up to 2^8 - 1 list elements with total size less than 2^8 octets"/> <encoding name="list32" code="0xd0" category="compound" width="4" label="up to 2^32 - 1 list elements with total size less than 2^32 octets"/> </type>

1.6.23 map

A polymorphic mapping from distinct keys to values.

<type name="map" class="primitive"> <encoding name="map8" code="0xc1" category="compound" width="1" label="up to 2^8 - 1 octets of encoded map data"/> <encoding name="map32" code="0xd1" category="compound" width="4" label="up to 2^32 - 1 octets of encoded map data"/> </type>

A map is encoded as a compound value where the constituent elements form alternating key value pairs.

Figure 1.20: Layout of Map Encoding
item 0 item 1 item n-1 item n +-------+-------+----+---------+---------+ | key 1 | val 1 | .. | key n/2 | val n/2 | +-------+-------+----+---------+---------+

Map encodings MUST contain an even number of items (i.e. an equal number of keys and values). A map in which there exist two identical key values is invalid. Unless known to be otherwise, maps MUST be considered to be ordered, that is, the order of the key-value pairs is semantically important and two maps which are different only in the order in which their key-value pairs are encoded are not equal.

1.6.24 array

A sequence of values of a single type.

<type name="array" class="primitive"> <encoding name="array8" code="0xe0" category="array" width="1" label="up to 2^8 - 1 array elements with total size less than 2^8 octets"/> <encoding name="array32" code="0xf0" category="array" width="4" label="up to 2^32 - 1 array elements with total size less than 2^32 octets"/> </type>

<< Part 0: Overview Part 2: Transport >>