OASIS AMQP Version 1.0
Part 1 : Types
Committee Specification Draft 01
21 February 2012
Specification URIs
This version:
http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-types-v1.0-csd01.xml (Authoritative)
http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-types-v1.0-csd01.html
http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-complete-v1.0-csd01.pdf
Previous version:
N/A
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 AMQP Technical Committee
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:
· 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 OASIS AMQP Technical Committee 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/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 AMQP Version 1.0 Part 1 : Types. 21 February 2012. Committee Specification Draft 01. http://docs.oasis-open.org/amqp/core/v1.0/csd01/amqp-core-types-v1.0-csd01.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/who/trademark.php for above guidance.
1.1 Type System |
1.1.1 Primitive Types |
1.1.2 Described Types |
1.1.3 Descriptor Values |
1.2 Type Encodings |
1.2.1 Fixed Width |
1.2.2 Variable Width |
1.2.3 Compound |
1.2.4 Array |
1.2.5 List of Encodings |
1.3 Composite Types |
1.3.1 List Encoding |
The AMQP type system defines a set of commonly used primitive types used for interoperable data representation. AMQP values may 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.
The following primitive types are defined:
null | indicates an empty value |
boolean | represents a true or false value |
ubyte | integer in the range 0 to 2^8 - 1 inclusive |
ushort | integer in the range 0 to 2^16 - 1 inclusive |
uint | integer in the range 0 to 2^32 - 1 inclusive |
ulong | integer in the range 0 to 2^64 - 1 inclusive |
byte | integer in the range -(2^7) to 2^7 - 1 inclusive |
short | integer in the range -(2^15) to 2^15 - 1 inclusive |
int | integer in the range -(2^31) to 2^31 - 1 inclusive |
long | integer in the range -(2^63) to 2^63 - 1 inclusive |
float | 32-bit floating point number (IEEE 754-2008 binary32) |
double | 64-bit floating point number (IEEE 754-2008 binary64) |
decimal32 | 32-bit decimal number (IEEE 754-2008 decimal32) |
decimal64 | 64-bit decimal number (IEEE 754-2008 decimal64) |
decimal128 | 128-bit decimal number (IEEE 754-2008 decimal128) |
char | a single Unicode character |
timestamp | an absolute point in time |
uuid | a universally unique identifier as defined by RFC-4122 section 4.1.2 |
binary | a sequence of octets |
string | a sequence of Unicode characters |
symbol | symbolic values from a constrained domain |
list | a sequence of polymorphic values |
map | a polymorphic mapping from distinct keys to values |
array | a sequence of values of a single type |
The primitive types defined by AMQP can directly represent many of the basic types present in most popular programming languages, and therefore may 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.
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:
<domain>:<name>
(domain-id << 32) | descriptor-id
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.
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.
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 should be 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.
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.
The size of fixed-width data is determined based solely on the subcategory of the format code for the fixed width value.
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 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 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 may be interpreted according to the following 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:
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.
The width of a specific fixed width encoding may be computed from the subcategory of the format code for the fixed width value:
n OCTETs +----------+ | data | +----------+ Subcategory n ================= 0x4 0 0x5 1 0x6 2 0x7 4 0x8 8 0x9 16 |
<type name="null" class="primitive"/> |
null: indicates an empty value |
Encoding | Code | Category | Description |
---|---|---|---|
0x40 | fixed-width, 0-byte value | the null value |
<type name="boolean" class="primitive"/> |
boolean: represents a true or false value |
Encoding | Code | Category | Description |
---|---|---|---|
0x56 | fixed-width, 1-byte value | boolean with the octet 0x00 being false and octet 0x01 being true | |
true | 0x41 | fixed-width, 0-byte value | the boolean value true |
false | 0x42 | fixed-width, 0-byte value | the boolean value false |
<type name="ubyte" class="primitive"/> |
ubyte: integer in the range 0 to 2^8 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x50 | fixed-width, 1-byte value | 8-bit unsigned integer |
<type name="ushort" class="primitive"/> |
ushort: integer in the range 0 to 2^16 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x60 | fixed-width, 2-byte value | 16-bit unsigned integer in network byte order |
<type name="uint" class="primitive"/> |
uint: integer in the range 0 to 2^32 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x70 | fixed-width, 4-byte value | 32-bit unsigned integer in network byte order | |
smalluint | 0x52 | fixed-width, 1-byte value | unsigned integer value in the range 0 to 255 inclusive |
uint0 | 0x43 | fixed-width, 0-byte value | the uint value 0 |
<type name="ulong" class="primitive"/> |
ulong: integer in the range 0 to 2^64 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x80 | fixed-width, 8-byte value | 64-bit unsigned integer in network byte order | |
smallulong | 0x53 | fixed-width, 1-byte value | unsigned long value in the range 0 to 255 inclusive |
ulong0 | 0x44 | fixed-width, 0-byte value | the ulong value 0 |
<type name="byte" class="primitive"/> |
byte: integer in the range -(2^7) to 2^7 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x51 | fixed-width, 1-byte value | 8-bit two's-complement integer |
<type name="short" class="primitive"/> |
short: integer in the range -(2^15) to 2^15 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x61 | fixed-width, 2-byte value | 16-bit two's-complement integer in network byte order |
<type name="int" class="primitive"/> |
int: integer in the range -(2^31) to 2^31 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x71 | fixed-width, 4-byte value | 32-bit two's-complement integer in network byte order | |
smallint | 0x54 | fixed-width, 1-byte value | 8-bit two's-complement integer |
<type name="long" class="primitive"/> |
long: integer in the range -(2^63) to 2^63 - 1 inclusive |
Encoding | Code | Category | Description |
---|---|---|---|
0x81 | fixed-width, 8-byte value | 64-bit two's-complement integer in network byte order | |
smalllong | 0x55 | fixed-width, 1-byte value | 8-bit two's-complement integer |
<type name="float" class="primitive"/> |
float: 32-bit floating point number (IEEE 754-2008 binary32) |
Encoding | Code | Category | Description |
---|---|---|---|
ieee-754 | 0x72 | fixed-width, 4-byte value | IEEE 754-2008 binary32 |
<type name="double" class="primitive"/> |
double: 64-bit floating point number (IEEE 754-2008 binary64) |
Encoding | Code | Category | Description |
---|---|---|---|
ieee-754 | 0x82 | fixed-width, 8-byte value | IEEE 754-2008 binary64 |
<type name="decimal32" class="primitive"/> |
decimal32: 32-bit decimal number (IEEE 754-2008 decimal32) |
Encoding | Code | Category | Description |
---|---|---|---|
ieee-754 | 0x74 | fixed-width, 4-byte value | IEEE 754-2008 decimal32 using the Binary Integer Decimal encoding |
<type name="decimal64" class="primitive"/> |
decimal64: 64-bit decimal number (IEEE 754-2008 decimal64) |
Encoding | Code | Category | Description |
---|---|---|---|
ieee-754 | 0x84 | fixed-width, 8-byte value | IEEE 754-2008 decimal64 using the Binary Integer Decimal encoding |
<type name="decimal128" class="primitive"/> |
decimal128: 128-bit decimal number (IEEE 754-2008 decimal128) |
Encoding | Code | Category | Description |
---|---|---|---|
ieee-754 | 0x94 | fixed-width, 16-byte value | IEEE 754-2008 decimal128 using the Binary Integer Decimal encoding |
<type name="char" class="primitive"/> |
char: a single Unicode character |
Encoding | Code | Category | Description |
---|---|---|---|
utf32 | 0x73 | fixed-width, 4-byte value | a UTF-32BE encoded Unicode character |
<type name="timestamp" class="primitive"/> |
timestamp: an absolute point in time |
Encoding | Code | Category | Description |
---|---|---|---|
ms64 | 0x83 | fixed-width, 8-byte value | 64-bit two's-complement integer representing milliseconds since the unix epoch |
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. |
<type name="uuid" class="primitive"/> |
uuid: a universally unique identifier as defined by RFC-4122 section 4.1.2 |
Encoding | Code | Category | Description |
---|---|---|---|
0x98 | fixed-width, 16-byte value | UUID as defined in section 4.1.2 of RFC-4122 |
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 may be computed from the subcategory of the format code:
n OCTETs size OCTETs +----------+-------------+ | size | value | +----------+-------------+ Subcategory n ================= 0xA 1 0xB 4 |
<type name="binary" class="primitive"/> |
binary: a sequence of octets |
Encoding | Code | Category | Description |
---|---|---|---|
vbin8 | 0xa0 | variable-width, 1 byte size | up to 2^8 - 1 octets of binary data |
vbin32 | 0xb0 | variable-width, 4 byte size | up to 2^32 - 1 octets of binary data |
<type name="string" class="primitive"/> |
string: a sequence of Unicode characters |
Encoding | Code | Category | Description |
---|---|---|---|
str8-utf8 | 0xa1 | variable-width, 1 byte size | up to 2^8 - 1 octets worth of UTF-8 Unicode (with no byte order mark) |
str32-utf8 | 0xb1 | variable-width, 4 byte size | up to 2^32 - 1 octets worth of UTF-8 Unicode (with no byte order mark) |
<type name="symbol" class="primitive"/> |
symbol: symbolic values from a constrained domain |
Encoding | Code | Category | Description |
---|---|---|---|
sym8 | 0xa3 | variable-width, 1 byte size | up to 2^8 - 1 seven bit ASCII characters representing a symbolic value |
sym32 | 0xb3 | variable-width, 4 byte size | up to 2^32 - 1 seven bit ASCII characters representing a symbolic value |
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 may be computed from the category of the format code:
+----------= count items =----------+ | | n OCTETs n OCTETs | | +----------+----------+--------------+------------+-------+ | size | count | ... /| item |\ ... | +----------+----------+------------/ +------------+ \-----+ / / \ \ / / \ \ / / \ \ +-------------+----------+ | constructor | data | +-------------+----------+ Subcategory n ================= 0xC 1 0xD 4 |
<type name="list" class="primitive"/> |
list: a sequence of polymorphic values |
Encoding | Code | Category | Description |
---|---|---|---|
list0 | 0x45 | fixed-width, 0-byte value | the empty list (i.e. the list with no elements) |
list8 | 0xc0 | variable-width, 1 byte size | up to 2^8 - 1 list elements with total size less than 2^8 octets |
list32 | 0xd0 | variable-width, 4 byte size | up to 2^32 - 1 list elements with total size less than 2^32 octets |
<type name="map" class="primitive"/> |
map: a polymorphic mapping from distinct keys to values |
Encoding | Code | Category | Description |
---|---|---|---|
map8 | 0xc1 | variable-width, 1 byte size | up to 2^8 - 1 octets of encoded map data |
map32 | 0xd1 | variable-width, 4 byte size | up to 2^32 - 1 octets of encoded map data |
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:
+--= count elements =--+ | | n OCTETs n OCTETs | | +----------+----------+---------------------+-------+------+-------+ | size | count | element-constructor | ... | data | ... | +----------+----------+---------------------+-------+------+-------+ Subcategory n ================= 0xE 1 0xF 4 |
<type name="array" class="primitive"/> |
array: a sequence of values of a single type |
Encoding | Code | Category | Description |
---|---|---|---|
array8 | 0xe0 | variable-width, 1 byte size | up to 2^8 - 1 array elements with total size less than 2^8 octets |
array32 | 0xf0 | variable-width, 4 byte size | up to 2^32 - 1 array elements with total size less than 2^32 octets |
Type | Encoding | Code | Category | Description |
---|---|---|---|---|
null | 0x40 | fixed/0 | the null value | |
boolean | 0x56 | fixed/1 | boolean with the octet 0x00 being false and octet 0x01 being true | |
boolean | true | 0x41 | fixed/0 | the boolean value true |
boolean | false | 0x42 | fixed/0 | the boolean value false |
ubyte | 0x50 | fixed/1 | 8-bit unsigned integer | |
ushort | 0x60 | fixed/2 | 16-bit unsigned integer in network byte order | |
uint | 0x70 | fixed/4 | 32-bit unsigned integer in network byte order | |
uint | smalluint | 0x52 | fixed/1 | unsigned integer value in the range 0 to 255 inclusive |
uint | uint0 | 0x43 | fixed/0 | the uint value 0 |
ulong | 0x80 | fixed/8 | 64-bit unsigned integer in network byte order | |
ulong | smallulong | 0x53 | fixed/1 | unsigned long value in the range 0 to 255 inclusive |
ulong | ulong0 | 0x44 | fixed/0 | the ulong value 0 |
byte | 0x51 | fixed/1 | 8-bit two's-complement integer | |
short | 0x61 | fixed/2 | 16-bit two's-complement integer in network byte order | |
int | 0x71 | fixed/4 | 32-bit two's-complement integer in network byte order | |
int | smallint | 0x54 | fixed/1 | 8-bit two's-complement integer |
long | 0x81 | fixed/8 | 64-bit two's-complement integer in network byte order | |
long | smalllong | 0x55 | fixed/1 | 8-bit two's-complement integer |
float | ieee-754 | 0x72 | fixed/4 | IEEE 754-2008 binary32 |
double | ieee-754 | 0x82 | fixed/8 | IEEE 754-2008 binary64 |
decimal32 | ieee-754 | 0x74 | fixed/4 | IEEE 754-2008 decimal32 using the Binary Integer Decimal encoding |
decimal64 | ieee-754 | 0x84 | fixed/8 | IEEE 754-2008 decimal64 using the Binary Integer Decimal encoding |
decimal128 | ieee-754 | 0x94 | fixed/16 | IEEE 754-2008 decimal128 using the Binary Integer Decimal encoding |
char | utf32 | 0x73 | fixed/4 | a UTF-32BE encoded Unicode character |
timestamp | ms64 | 0x83 | fixed/8 | 64-bit two's-complement integer representing milliseconds since the unix epoch |
uuid | 0x98 | fixed/16 | UUID as defined in section 4.1.2 of RFC-4122 | |
binary | vbin8 | 0xa0 | variable/1 | up to 2^8 - 1 octets of binary data |
binary | vbin32 | 0xb0 | variable/4 | up to 2^32 - 1 octets of binary data |
string | str8-utf8 | 0xa1 | variable/1 | up to 2^8 - 1 octets worth of UTF-8 Unicode (with no byte order mark) |
string | str32-utf8 | 0xb1 | variable/4 | up to 2^32 - 1 octets worth of UTF-8 Unicode (with no byte order mark) |
symbol | sym8 | 0xa3 | variable/1 | up to 2^8 - 1 seven bit ASCII characters representing a symbolic value |
symbol | sym32 | 0xb3 | variable/4 | up to 2^32 - 1 seven bit ASCII characters representing a symbolic value |
list | list0 | 0x45 | fixed/0 | the empty list (i.e. the list with no elements) |
list | list8 | 0xc0 | compound/1 | up to 2^8 - 1 list elements with total size less than 2^8 octets |
list | list32 | 0xd0 | compound/4 | up to 2^32 - 1 list elements with total size less than 2^32 octets |
map | map8 | 0xc1 | compound/1 | up to 2^8 - 1 octets of encoded map data |
map | map32 | 0xd1 | compound/4 | up to 2^32 - 1 octets of encoded map data |
array | array8 | 0xe0 | array/1 | up to 2^8 - 1 array elements with total size less than 2^8 octets |
array | array32 | 0xf0 | array/4 | up to 2^32 - 1 array elements with total size less than 2^32 octets |
AMQP defines a number of composite types used for encoding structured data such as frame bodies. A composite type describes 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 in the XML documents included with the specification. The following notation is used to define them:
<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).
AMQP composite values are encoded 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.
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 may optionally be omitted according to the encoding rules.
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 |
<< Part 0: Overview | Part 2: Transport >> |