diff options
Diffstat (limited to 'specs/amqp.1-0-draft.xml')
-rw-r--r-- | specs/amqp.1-0-draft.xml | 5102 |
1 files changed, 0 insertions, 5102 deletions
diff --git a/specs/amqp.1-0-draft.xml b/specs/amqp.1-0-draft.xml deleted file mode 100644 index cdca7da05b..0000000000 --- a/specs/amqp.1-0-draft.xml +++ /dev/null @@ -1,5102 +0,0 @@ -<?xml version="1.0"?> - -<!-- - Copyright Notice - ================ - (c) Copyright Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc., - Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, - Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc. - 2006, 2007. All rights reserved. - - License - ======= - - Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,Goldman Sachs, - IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, Novell, Rabbit - Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc. (collectively, - the "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable, - nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue - Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for - the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and - any rights under this Agreement will terminate immediately without notice from any Author if you - bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol - Specification against any Author. Upon termination, you shall destroy all copies of the Advanced - Messaging Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or patent application, - throughout the world, excluding design patents and design registrations, owned or controlled, or - that can be sublicensed without fee and in compliance with the requirements of this Agreement, by - an Author or its affiliates now or at any future time and which would necessarily be infringed by - implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily - infringed hereunder only when it is not possible to avoid infringing it because there is no - plausible non-infringing alternative for implementing the required portions of the Advanced - Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not - include any claims other than as set forth above even if contained in the same patent as Licensed - Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging Queue Protocol - Specification, or that, if licensed, would require a payment of royalties by the licensor to - unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling - technologies that may be necessary to make or use any Licensed Product but are not themselves - expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor - manufacturing technology, compiler technology, object oriented technology, networking technology, - operating system technology, and the like); or (ii) the implementation of other published - standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue - Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced Messaging Queue Protocol - Specification. For purposes of this definition, the Advanced Messaging Queue Protocol - Specification shall be deemed to include both architectural and interconnection requirements - essential for interoperability and may also include supporting source code artifacts where such - architectural, interconnection requirements and source code artifacts are expressly identified as - being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol - Specification. - - As used hereunder, "Licensed Products" means only those specific portions of products (hardware, - software or combinations thereof) that implement and are compliant with all relevant portions of - the Advanced Messaging Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any use you may make of the - Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO - REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS - OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE - IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD - PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL - DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, including advertising or - publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents - without specific, written prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you shall destroy all copies of - the Advanced Messaging Queue Protocol Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are - trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its - subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat, - Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the - United States, other countries, or both. - - Other company, product, or service names may be trademarks or service marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp ---> - -<!-- - XML Notes - ========= - - We use entities to indicate repetition; attributes to indicate properties. - - We use the "name" attribute as an identifier, usually within the context of the surrounding - entities. - - We use hyphens (minus char '-') to seperate words in names. - - We do not enforce any particular validation mechanism but we support all mechanisms. The protocol - definition conforms to a formal grammar that is published seperately in several technologies. - ---> - -<!DOCTYPE amqp SYSTEM "amqp.1-0-draft.dtd"> - -<amqp xmlns="http://www.amqp.org/schema/amqp.xsd" - major="99" minor="0" port="5672" comment="working version"> - - <!-- - ====================== == type definitions == ====================== - --> - - <!-- - 0x00 - 0x0f: Fixed width, 1 octet - --> - - <type name="bin8" code="0x00" fixed-width="1" label="octet of unspecified encoding"> - <doc> - The bin8 type consists of exactly one octet of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET - +----------+ - | bin8 | - +----------+ - </doc> - - <doc type="bnf"> - bin8 = OCTET - </doc> - </type> - - <type name="int8" code="0x01" fixed-width="1" label="8-bit signed integral value (-128 - 127)"> - <doc> - The int8 type is a signed integral value encoded using an 8-bit two's complement - representation. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET - +----------+ - | int8 | - +----------+ - </doc> - - <doc type="bnf"> - int8 = OCTET - </doc> - </type> - - <type name="uint8" code="0x02" fixed-width="1" label="8-bit unsigned integral value (0 - 255)"> - <doc> - The uint8 type is an 8-bit unsigned integral value. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET - +---------+ - | uint8 | - +---------+ - </doc> - - <doc type="bnf"> - uint8 = OCTET - </doc> - </type> - - <type name="char" code="0x04" fixed-width="1" label="an iso-8859-15 character"> - <doc> - The char type encodes a single character from the iso-8859-15 character set. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET - +----------+ - | char | - +----------+ - </doc> - - <doc type="bnf"> - char = OCTET - </doc> - </type> - - <type name="boolean" code="0x08" fixed-width="1" - label="boolean value (zero represents false, nonzero represents true)"> - <doc> - The boolean type is a single octet that encodes a true or false value. If the octet is zero, - then the boolean is false. Any other value represents true. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET - +---------+ - | boolean | - +---------+ - </doc> - - <doc type="bnf"> - boolean = OCTET - </doc> - </type> - - <!-- - 0x10 - 0x1f: Fixed width, 2 octets - --> - - <type name="bin16" code="0x10" fixed-width="2" label="two octets of unspecified binary encoding"> - <doc> - The bin16 type consists of two consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET - +-----------+-----------+ - | octet-one | octet-two | - +-----------+-----------+ - </doc> - - <doc type="bnf"> - bin16 = 2 OCTET - </doc> - </type> - - <type name="int16" code="0x11" fixed-width="2" label="16-bit signed integral value"> - <doc> - The int16 type is a signed integral value encoded using a 16-bit two's complement - representation in network byte order. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET - +-----------+----------+ - | high-byte | low-byte | - +-----------+----------+ - </doc> - - <doc type="bnf"> - int16 = high-byte low-byte - high-byte = OCTET - low-byte = OCTET - </doc> - </type> - - <type name="uint16" code="0x12" fixed-width="2" label="16-bit unsigned integer"> - <doc> - The uint16 type is a 16-bit unsigned integral value encoded in network byte order. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET - +-----------+----------+ - | high-byte | low-byte | - +-----------+----------+ - </doc> - - <doc type="bnf"> - uint16 = high-byte low-byte - high-byte = OCTET - low-byte = OCTET - </doc> - </type> - - <type name="channel" fixed-width="2" label="channel identifier"> - <doc> - The channel type identifies both a direction and a 15 bit channel number packed into a 16 bit - value. The channel number may be computed by treating the channel identifier as a uint16 and - masking off the most significant bit. The most significant bit of the channel identifier - indicates the direction of the channel. If this bit is zero, the channel identifier refers to - a channel number where the initiator of the network connection (i.e. the network client) is - the AMQP client. If this bit is one, the channel identifier refers to a channel number where - the initiator of the network connection (i.e. the network client) is the AMQP server. - </doc> - - <doc type="picture" title="Wire Format"> - 1 BIT 15 BITs - +-----------+----------------+ - | direction | channel-number | - +-----------+----------------+ - MSB LSB - </doc> - - <doc type="bnf"> - channel = direction channel-number - direction = 1 BIT - channel-number = 15 BIT - </doc> - </type> - - <!-- - 0x20 - 0x2f: Fixed width, 4 octets - --> - - <type name="bin32" code="0x20" fixed-width="4" label="four octets of unspecified binary encoding"> - <doc> - The bin32 type consists of 4 consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-------------+------------+ - | octet-one | octet-two | octet-three | octet-four | - +-----------+-----------+-------------+------------+ - </doc> - - <doc type="bnf"> - bin32 = 4 OCTET - </doc> - </type> - - <type name="int32" code="0x21" fixed-width="4" label="32-bit signed integral value"> - <doc> - The int32 type is a signed integral value encoded using a 32-bit two's complement - representation in network byte order. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+------------+----------+----------+ - | byte-four | byte-three | byte-two | byte-one | - +-----------+------------+----------+----------+ - MSB LSB - </doc> - - <doc type="bnf"> - int32 = byte-four byte-three byte-two byte-one - byte-four = OCTET ; most significant byte (MSB) - byte-three = OCTET - byte-two = OCTET - byte-one = OCTET ; least significant byte (LSB) - </doc> - </type> - - <type name="uint32" code="0x22" fixed-width="4" label="32-bit unsigned integral value"> - <doc> - The uint32 type is a 32-bit unsigned integral value encoded in network byte order. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+------------+----------+----------+ - | byte-four | byte-three | byte-two | byte-one | - +-----------+------------+----------+----------+ - MSB LSB - </doc> - - <doc type="bnf"> - uint32 = byte-four byte-three byte-two byte-one - byte-four = OCTET ; most significant byte (MSB) - byte-three = OCTET - byte-two = OCTET - byte-one = OCTET ; least significant byte (LSB) - </doc> - </type> - - <type name="float" code="0x23" fixed-width="4" - label="single precision IEEE 754 32-bit floating point"> - <doc> - The float type encodes a single precision 32-bit floating point number. The format and - operations are defined by the IEEE 754 standard for 32-bit floating point numbers. - </doc> - - <doc type="picture" title="Wire Format"> - 4 OCTETs - +-----------------------+ - | float | - +-----------------------+ - IEEE 754 32-bit float - </doc> - - <doc type="bnf"> - float = 4 OCTET ; IEEE 754 32-bit floating point number - </doc> - </type> - - <type name="char-utf32" code="0x27" fixed-width="4" - label="single unicode character in UTF-32 encoding"> - <doc> - The char-utf32 type consists of a single unicode character in the UTF-32 encoding. - </doc> - - <doc type="picture" title="Wire Format"> - 4 OCTETs - +------------------+ - | char-utf32 | - +------------------+ - UTF-32 character - </doc> - - <doc type="bnf"> - char-utf32 = 4 OCTET ; single UTF-32 character - </doc> - </type> - - <type name="sequence-no" fixed-width="4" label="serial number defined in RFC-1982"> - <doc> - The sequence-no type encodes, in network byte order, a serial number as defined in RFC-1982. - The arithmetic, operators, and ranges for numbers of this type are defined by RFC-1982. - </doc> - - <doc type="picture" title="Wire Format"> - 4 OCTETs - +------------------------+ - | sequence-no | - +------------------------+ - RFC-1982 serial number - </doc> - - <doc type="bnf"> - sequence-no = 4 OCTET ; RFC-1982 serial number - </doc> - </type> - - <!-- - 0x30 - 0x3f: Fixed width types - 8 octets - --> - - <type name="bin64" code="0x30" fixed-width="8" - label="eight octets of unspecified binary encoding"> - <doc> - The bin64 type consists of eight consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-----+-------------+-------------+ - | octet-one | octet-two | ... | octet-seven | octet-eight | - +-----------+-----------+-----+-------------+-------------+ - </doc> - - <doc type="bnf"> - bin64 = 8 OCTET - </doc> - </type> - - <type name="int64" code="0x31" fixed-width="8" label="64-bit signed integral value"> - <doc> - The int64 type is a signed integral value encoded using a 64-bit two's complement - representation in network byte order. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +------------+------------+-----+----------+----------+ - | byte-eight | byte-seven | ... | byte-two | byte-one | - +------------+------------+-----+----------+----------+ - MSB LSB - </doc> - - <doc type="bnf"> - int64 = byte-eight byte-seven byte-six byte-five - byte-four byte-three byte-two byte-one - byte-eight = 1 OCTET ; most significant byte (MSB) - byte-seven = 1 OCTET - byte-six = 1 OCTET - byte-five = 1 OCTET - byte-four = 1 OCTET - byte-three = 1 OCTET - byte-two = 1 OCTET - byte-one = 1 OCTET ; least significant byte (LSB) - </doc> - </type> - - <type name="uint64" code="0x32" fixed-width="8" label="64-bit unsigned integral value"> - <doc> - The uint64 type is a 64-bit unsigned integral value encoded in network byte order. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +------------+------------+-----+----------+----------+ - | byte-eight | byte-seven | ... | byte-two | byte-one | - +------------+------------+-----+----------+----------+ - MSB LSB - </doc> - - <doc type="bnf"> - uint64 = byte-eight byte-seven byte-six byte-five - byte-four byte-three byte-two byte-one - byte-eight = 1 OCTET ; most significant byte (MSB) - byte-seven = 1 OCTET - byte-six = 1 OCTET - byte-five = 1 OCTET - byte-four = 1 OCTET - byte-three = 1 OCTET - byte-two = 1 OCTET - byte-one = 1 OCTET ; least significant byte (LSB) - </doc> - </type> - - <type name="double" code="0x33" fixed-width="8" label="double precision IEEE 754 floating point"> - <doc> - The double type encodes a double precision 64-bit floating point number. The format and - operations are defined by the IEEE 754 standard for 64-bit double precision floating point - numbers. - </doc> - - <doc type="picture" title="Wire Format"> - 8 OCTETs - +-----------------------+ - | double | - +-----------------------+ - IEEE 754 64-bit float - </doc> - - <doc type="bnf"> - double = 8 OCTET ; double precision IEEE 754 floating point number - </doc> - </type> - - <type name="datetime" code="0x38" fixed-width="8" label="datetime in 64 bit POSIX time_t format"> - <doc> - The datetime type encodes a date and time using the 64 bit POSIX time_t format. - </doc> - - <doc type="picture" title="Wire Format"> - 8 OCTETs - +---------------------+ - | datetime | - +---------------------+ - posix time_t format - </doc> - - <doc type="bnf"> - datetime = 8 OCTET ; 64 bit posix time_t format - </doc> - </type> - - <!-- - 0x40 - 0x4f: Fixed width types - 16 octets - --> - - <type name="bin128" code="0x40" fixed-width="16" - label="sixteen octets of unspecified binary encoding"> - <doc> - The bin128 type consists of 16 consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-----+---------------+---------------+ - | octet-one | octet-two | ... | octet-fifteen | octet-sixteen | - +-----------+-----------+-----+---------------+---------------+ - </doc> - - <doc type="bnf"> - bin128 = 16 OCTET - </doc> - </type> - - <type name="uuid" code="0x48" fixed-width="16" label="UUID (RFC-4122 section 4.1.2) - 16 octets"> - <doc> - The uuid type encodes a universally unique id as defined by RFC-4122. The format and - operations for this type can be found in section 4.1.2 of RFC-4122. - </doc> - - <doc type="picture" title="Wire Format"> - 16 OCTETs - +---------------+ - | uuid | - +---------------+ - RFC-4122 UUID - </doc> - - <doc type="bnf"> - uuid = 16 OCTET ; RFC-4122 section 4.1.2 - </doc> - </type> - - <!-- - 0x50 - 0x5f: Fixed width types - 32 octets - --> - - <type name="bin256" code="0x50" fixed-width="32" - label="thirty two octets of unspecified binary encoding"> - <doc> - The bin256 type consists of thirty two consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-----+------------------+------------------+ - | octet-one | octet-two | ... | octet-thirty-one | octet-thirty-two | - +-----------+-----------+-----+------------------+------------------+ - </doc> - - <doc type="bnf"> - bin256 = 32 OCTET - </doc> - </type> - - <!-- - 0x60 - 0x6f: Fixed width types - 64 octets - --> - - <type name="bin512" code="0x60" fixed-width="64" - label="sixty four octets of unspecified binary encoding"> - <doc> - The bin512 type consists of sixty four consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-----+-------------------+------------------+ - | octet-one | octet-two | ... | octet-sixty-three | octet-sixty-four | - +-----------+-----------+-----+-------------------+------------------+ - </doc> - - <doc type="bnf"> - bin512 = 64 OCTET - </doc> - </type> - - <!-- - 0x70 - 0x7f: Fixed width types - 128 octets - --> - - <type name="bin1024" code="0x70" fixed-width="128" - label="one hundred and twenty eight octets of unspecified binary encoding"> - <doc> - The bin1024 type consists of one hundred and twenty eight octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-----+------------------------+------------------------+ - | octet-one | octet-two | ... | octet-one-twenty-seven | octet-one-twenty-eight | - +-----------+-----------+-----+------------------------+------------------------+ - </doc> - - <doc type="bnf"> - bin1024 = 128 OCTET - </doc> - </type> - - <!-- - 0x80 - 0x8f: Variable length - one byte length field (up to 255 octets) - --> - - <type name="vbin8" code="0x80" variable-width="1" label="up to 255 octets of opaque binary data"> - <doc> - The vbin8 type encodes up to 255 octets of opaque binary data. The number of octets is first - encoded as an 8-bit unsigned integral value. This is followed by the actual data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET size OCTETs - +---------+-------------+ - | size | octets | - +---------+-------------+ - uint8 - </doc> - - <doc type="bnf"> - vbin8 = size octets - size = uint8 - octets = 0*255 OCTET ; size OCTETs - </doc> - </type> - - <type name="str8-latin" code="0x84" variable-width="1" label="up to 255 iso-8859-15 characters"> - <doc> - The str8-latin type encodes up to 255 octets of iso-8859-15 characters. The number of octets - is first encoded as an 8-bit unsigned integral value. This is followed by the actual - characters. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET size OCTETs - +---------+------------------------+ - | size | characters | - +---------+------------------------+ - uint16 iso-8859-15 characters - </doc> - - <doc type="bnf"> - str8-latin = size characters - size = uint8 - characters = 0*255 OCTET ; size OCTETs - </doc> - </type> - - <type name="str8" code="0x85" variable-width="1" label="up to 255 octets worth of UTF-8 unicode"> - <doc> - The str8 type encodes up to 255 octets worth of UTF-8 unicode. The number of octets of unicode - is first encoded as an 8-bit unsigned integral value. This is followed by the actual UTF-8 - unicode. Note that the encoded size refers to the number of octets of unicode, not necessarily - the number of characters since the UTF-8 unicode may include multi-byte character sequences. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET size OCTETs - +---------+--------------+ - | size | utf8-unicode | - +---------+--------------+ - uint8 - </doc> - - <doc type="bnf"> - str8 = size utf8-unicode - size = uint8 - utf8-unicode = 0*255 OCTET ; size OCTETs - </doc> - </type> - - <type name="str8-utf16" code="0x86" variable-width="1" - label="up to 255 octets worth of UTF-16 unicode"> - <doc> - The str8-utf16 type encodes up to 255 octets worth of UTF-16 unicode. The number of octets of - unicode is first encoded as an 8-bit unsigned integral value. This is followed by the actual - UTF-16 unicode. Note that the encoded size refers to the number of octets of unicode, not the - number of characters since the UTF-16 unicode will include at least two octets per unicode - character. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET size OCTETs - +---------+---------------+ - | size | utf16-unicode | - +---------+---------------+ - uint8 - </doc> - - <doc type="bnf"> - str8-utf16 = size utf16-unicode - size = uint8 - utf16-unicode = 0*255 OCTET ; size OCTETs - </doc> - </type> - - <!-- - 0x90 - 0x9f: Variable length types - two byte length field (up to 65535 octets) - --> - - <type name="vbin16" code="0x90" variable-width="2" - label="up to 65535 octets of opaque binary data"> - <doc> - The vbin16 type encodes up to 65535 octets of opaque binary data. The number of octets is - first encoded as a 16-bit unsigned integral value in network byte order. This is followed by - the actual data. - </doc> - - <doc type="picture" title="Wire Format"> - 2 OCTETs size OCTETs - +----------+-------------+ - | size | octets | - +----------+-------------+ - uint16 - </doc> - - <doc type="bnf"> - vbin16 = size octets - size = uint16 - octets = 0*65535 OCTET ; size OCTETs - </doc> - </type> - - <type name="str16-latin" code="0x94" variable-width="2" - label="up to 65535 iso-8859-15 characters"> - <doc> - The str16-latin type encodes up to 65535 octets of is-8859-15 characters. The number of octets - is first encoded as a 16-bit unsigned integral value in network byte order. This is followed - by the actual characters. - </doc> - - <doc type="picture" title="Wire Format"> - 2 OCTETs size OCTETs - +----------+------------------------+ - | size | characters | - +----------+------------------------+ - uint16 iso-8859-15 characters - </doc> - - <doc type="bnf"> - str16-latin = size characters - size = uint16 - characters = 0*65535 OCTET ; size OCTETs - </doc> - </type> - - <type name="str16" code="0x95" variable-width="2" - label="up to 65535 octets worth of UTF-8 unicode"> - <doc> - The str16 type encodes up to 65535 octets worth of UTF-8 unicode. The number of octets is - first encoded as a 16-bit unsigned integral value in network byte order. This is followed by - the actual UTF-8 unicode. Note that the encoded size refers to the number of octets of - unicode, not necessarily the number of unicode characters since the UTF-8 unicode may include - multi-byte character sequences. - </doc> - - <doc type="picture" title="Wire Format"> - 2 OCTETs size OCTETs - +----------+--------------+ - | size | utf8-unicode | - +----------+--------------+ - uint16 - </doc> - - <doc type="bnf"> - str16 = size utf8-unicode - size = uint16 - utf8-unicode = 0*65535 OCTET ; size OCTETs - </doc> - </type> - - <type name="str16-utf16" code="0x96" variable-width="2" - label="up to 65535 octets worth of UTF-16 unicode"> - <doc> - The str16-utf16 type encodes up to 65535 octets worth of UTF-16 unicode. The number of octets - is first encoded as a 16-bit unsigned integral value in network byte order. This is followed - by the actual UTF-16 unicode. Note that the encoded size refers to the number of octets of - unicode, not the number of unicode characters since the UTF-16 unicode will include at least - two octets per unicode character. - </doc> - - <doc type="picture" title="Wire Format"> - 2 OCTETs size OCTETs - +----------+---------------+ - | size | utf16-unicode | - +----------+---------------+ - uint16 - </doc> - - <doc type="bnf"> - str16-utf16 = size utf16-unicode - size = uint16 - utf16-unicode = 0*65535 OCTET ; size OCTETs - </doc> - </type> - - <type name="sequence-set" variable-width="2" label="ranged set representation"> - <doc> - The sequence-set type is a set of pairs of RFC-1982 numbers representing a discontinuous range - within an RFC-1982 sequence. Each pair represents a closed interval within the list. - </doc> - - <doc> - Sequence-sets can be represented as lists of pairs of positive 32-bit numbers, each pair - representing a closed interval that does not overlap or touch with any other interval in the - list. For example, a set containing words 0, 1, 2, 5, 6, and 15 can be represented: - </doc> - - <doc type="picture"> - [(0, 2), (5, 6), (15, 15)] - </doc> - - <doc> - 1) The list-of-pairs representation is sorted ascending (as defined by RFC 1982 - (http://www.ietf.org/rfc/rfc1982.txt) ) by the first elements of each pair. - </doc> - - <doc> - 2) The list-of-pairs is flattened into a list-of-words. - </doc> - - <doc> - 3) Each word in the list is packed into ascending locations in memory with network byte - ordering. - </doc> - - <doc> - 4) The size in bytes, represented as a 16-bit network-byte-order unsigned value, is prepended. - </doc> - - <doc> - For instance, the example from above would be encoded: - </doc> - - <doc type="picture"> - [(0, 2), (5, 6), (15, 15)] -- already sorted. - [0, 2, 5, 6, 15, 15] -- flattened. - 000000000000000200000005000000060000000F0000000F -- bytes in hex - 0018000000000000000200000005000000060000000F0000000F -- bytes in hex, - length (24) prepended - </doc> - - <doc type="picture" title="Wire Format"> - +----= size OCTETs =----+ - | | - 2 OCTETs | 8 OCTETs | - +----------+-----+-----------+-----+ - | size | .../| range |\... | - +----------+---/ +-----------+ \---+ - uint16 / / \ \ - / / \ \ - / / \ \ - / / \ \ - / 4 OCTETs 4 OCTETs \ - +-------------+-------------+ - | lower | upper | - +-------------+-------------+ - sequence-no sequence-no - </doc> - - <doc type="bnf"> - sequence-set = size *range - size = uint16 ; length of variable portion in bytes - - range = lower upper ; inclusive - lower = sequence-no - upper = sequence-no - </doc> - </type> - - <!-- - 0xa0 - 0xaf: Variable length types - four byte length field (up to 4294967295 octets) - --> - - <type name="vbin32" code="0xa0" variable-width="4" - label="up to 4294967295 octets of opaque binary data"> - <doc> - The vbin32 type encodes up to 4294967295 octets of opaque binary data. The number of octets is - first encoded as a 32-bit unsigned integral value in network byte order. This is followed by - the actual data. - </doc> - - <doc type="picture" title="Wire Format"> - 4 OCTETs size OCTETs - +----------+-------------+ - | size | octets | - +----------+-------------+ - uint32 - </doc> - - <doc type="bnf"> - vbin32 = size octets - size = uint32 - octets = 0*4294967295 OCTET ; size OCTETs - </doc> - </type> - - <type name="map" code="0xa8" variable-width="4" label="a mapping of keys to typed values"> - <doc> - A map is a set of distinct keys where each key has an associated (type,value) pair. The triple - of the key, type, and value, form an entry within a map. Each entry within a given map MUST - have a distinct key. A map is encoded as a size in octets, a count of the number of entries, - followed by the encoded entries themselves. - </doc> - - <doc> - An encoded map may contain up to (4294967295 - 4) octets worth of encoded entries. The size is - encoded as a 32-bit unsigned integral value in network byte order equal to the number of - octets worth of encoded entries plus 4. (The extra 4 octets is added for the entry count.) The - size is then followed by the number of entries encoded as a 32-bit unsigned integral value in - network byte order. Finally the entries are encoded sequentially. - </doc> - - <doc> - An entry is encoded as the key, followed by the type, and then the value. The key is always a - string encoded as a str8. The type is a single octet that may contain any valid AMQP type - code. The value is encoded according to the rules defined by the type code for that entry. - </doc> - - <doc type="picture" title="Wire Format"> - +------------= size OCTETs =-----------+ - | | - 4 OCTETs | 4 OCTETs | - +----------+----------+-----+---------------+-----+ - | size | count | .../| entry |\... | - +----------+----------+---/ +---------------+ \---+ - uint32 uint32 / / \ \ - / / \ \ - / / \ \ - / / \ \ - / / \ \ - / k OCTETs 1 OCTET n OCTETs \ - +-----------+---------+-----------+ - | key | type | value | - +-----------+---------+-----------+ - str8 *type* - </doc> - - <doc type="bnf"> - map = size count *entry - - size = uint32 ; size of count and entries in octets - count = uint32 ; number of entries in the map - - entry = key type value - key = str8 - type = OCTET ; type code of the value - value = *OCTET ; the encoded value - </doc> - </type> - - <type name="list" code="0xa9" variable-width="4" label="a series of consecutive type-value pairs"> - <doc> - A list is an ordered sequence of (type, value) pairs. The (type, value) pair forms an item - within the list. The list may contain items of many distinct types. A list is encoded as a - size in octets, followed by a count of the number of items, followed by the items themselves - encoded in their defined order. - </doc> - - <doc> - An encoded list may contain up to (4294967295 - 4) octets worth of encoded items. The size is - encoded as a 32-bit unsigned integral value in network byte order equal to the number of - octets worth of encoded items plus 4. (The extra 4 octets is added for the item count.) The - size is then followed by the number of items encoded as a 32-bit unsigned integral value in - network byte order. Finally the items are encoded sequentially in their defined order. - </doc> - - <doc> - An item is encoded as the type followed by the value. The type is a single octet that may - contain any valid AMQP type code. The value is encoded according to the rules defined by the - type code for that item. - </doc> - - <doc type="picture" title="Wire Format"> - +---------= size OCTETs =---------+ - | | - 4 OCTETs | 4 OCTETs | - +----------+----------+-----+----------+-----+ - | size | count | .../| item |\... | - +----------+----------+---/ +----------+ \---+ - uint32 uint32 / / \ \ - / / \ \ - / 1 OCTET n OCTETs \ - +----------+-----------+ - | type | value | - +----------+-----------+ - *type* - </doc> - - <doc type="bnf"> - list = size count *item - - size = uint32 ; size of count and items in octets - count = uint32 ; number of items in the list - - item = type value - type = OCTET ; type code of the value - value = *OCTET ; the encoded value - </doc> - </type> - - <type name="array" code="0xaa" variable-width="4" - label="a defined length collection of values of a single type"> - <doc> - An array is an ordered sequence of values of the same type. The array is encoded in as a size - in octets, followed by a type code, then a count of the number values in the array, and - finally the values encoded in their defined order. - </doc> - - <doc> - An encoded array may contain up to (4294967295 - 5) octets worth of encoded values. The size - is encoded as a 32-bit unsigned integral value in network byte order equal to the number of - octets worth of encoded values plus 5. (The extra 5 octets consist of 4 octets for the count - of the number of values, and one octet to hold the type code for the items in the array.) The - size is then followed by a single octet that may contain any valid AMQP type code. The type - code is then followed by the number of values encoded as a 32-bit unsigned integral value in - network byte order. Finally the values are encoded sequentially in their defined order - according to the rules defined by the type code for the array. - </doc> - - <doc type="picture" title="Wire Format"> - 4 OCTETs 1 OCTET 4 OCTETs (size - 5) OCTETs - +----------+---------+----------+-------------------------+ - | size | type | count | values | - +----------+---------+----------+-------------------------+ - uint32 uint32 *count* encoded *types* - </doc> - - <doc type="bnf"> - array = size type count values - - size = uint32 ; size of type, count, and values in octets - type = OCTET ; the type of the encoded values - count = uint32 ; number of items in the array - - values = 0*4294967290 OCTET ; (size - 5) OCTETs - </doc> - </type> - - <type name="struct32" code="0xab" variable-width="4" label="a coded struct with a 32-bit size"> - <doc> - The struct32 type describes any coded struct with a 32-bit (4 octet) size. The type is - restricted to be only coded structs with a 32-bit size, consequently the first six octets of - any encoded value for this type MUST always contain the size, class-code, and struct-code in - that order. - </doc> - - <doc> - The size is encoded as a 32-bit unsigned integral value in network byte order that is equal to - the size of the encoded field-data, packing-flags, class-code, and struct-code. The class-code - is a single octet that may be set to any valid class code. The struct-code is a single octet - that may be set to any valid struct code within the given class-code. - </doc> - - <doc> - The first six octets are then followed by the packing flags and encoded field data. The - presence and quantity of packing-flags, as well as the specific fields are determined by the - struct definition identified with the encoded class-code and struct-code. - </doc> - - <doc type="picture" title="Wire Format"> - 4 OCTETs 1 OCTET 1 OCTET pack-width OCTETs n OCTETs - +----------+------------+-------------+-------------------+------------+ - | size | class-code | struct-code | packing-flags | field-data | - +----------+------------+-------------+-------------------+------------+ - uint32 - - n = (size - 2 - pack-width) - </doc> - - <doc type="bnf"> - struct32 = size class-code struct-code packing-flags field-data - - size = uint32 - - class-code = OCTET ; zero for top-level structs - struct-code = OCTET ; together with class-code identifies the struct - ; definition which determines the pack-width and - ; fields - - packing-flags = 0*4 OCTET ; pack-width OCTETs - - field-data = *OCTET ; (size - 2 - pack-width) OCTETs - </doc> - </type> - - <!-- - 0xb0 - 0xbf: Reserved - --> - - <!-- - 0xc0 - 0xcf:Fixed width types - 5 octets - --> - - <type name="bin40" code="0xc0" fixed-width="5" label="five octets of unspecified binary encoding"> - <doc> - The bin40 type consists of five consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-------------+------------+------------+ - | octet-one | octet-two | octet-three | octet-four | octet-five | - +-----------+-----------+-------------+------------+------------+ - </doc> - - <doc type="bnf"> - bin40 = 5 OCTET - </doc> - </type> - - <type name="dec32" code="0xc8" fixed-width="5" - label="32-bit decimal value (e.g. for use in financial values)"> - <doc> - The dec32 type is decimal value with a variable number of digits following the decimal point. - It is encoded as an 8-bit unsigned integral value representing the number of decimal places. - This is followed by the signed integral value encoded using a 32-bit two's complement - representation in network byte order. - </doc> - - <doc> - The former value is referred to as the exponent of the divisor. The latter value is the - mantissa. The decimal value is given by: mantissa / 10^exponent. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 4 OCTETs - +----------+----------+ - | exponent | mantissa | - +----------+----------+ - uint8 int32 - </doc> - - <doc type="bnf"> - dec32 = exponent mantissa - exponent = uint8 - mantissa = int32 - </doc> - </type> - - <!-- - 0xd0 - 0xdf: Fixed width types - 9 octets - --> - - <type name="bin72" code="0xd0" fixed-width="9" - label="nine octets of unspecified binary encoding"> - <doc> - The bin72 type consists of nine consecutive octets of opaque binary data. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 1 OCTET 1 OCTET 1 OCTET - +-----------+-----------+-----+-------------+------------+ - | octet-one | octet-two | ... | octet-eight | octet-nine | - +-----------+-----------+-----+-------------+------------+ - </doc> - - <doc type="bnf"> - bin64 = 9 OCTET - </doc> - </type> - - <type name="dec64" code="0xd8" fixed-width="9" - label="64-bit decimal value (e.g. for use in financial values)"> - <doc> - The dec64 type is decimal value with a variable number of digits following the decimal point. - It is encoded as an 8-bit unsigned integral value representing the number of decimal places. - This is followed by the signed integral value encoded using a 64-bit two's complement - representation in network byte order. - </doc> - - <doc> - The former value is referred to as the exponent of the divisor. The latter value is the - mantissa. The decimal value is given by: mantissa / 10^exponent. - </doc> - - <doc type="picture" title="Wire Format"> - 1 OCTET 8 OCTETs - +----------+----------+ - | exponent | mantissa | - +----------+----------+ - uint8 int64 - </doc> - - <doc type="bnf"> - dec64 = exponent mantissa - exponent = uint8 - mantissa = int64 - </doc> - </type> - - <!-- - 0xe0 - 0xef: Reserved - --> - - <!-- - 0xf0 - 0xff: Zero-length types - --> - - <type name="void" code="0xf0" fixed-width="0" label="the void type"> - <doc> - The void type is used within tagged data structures such as maps and lists to indicate an - empty value. The void type has no value and is encoded as an empty sequence of octets. - </doc> - </type> - - <type name="bit" code="0xf1" fixed-width="0" label="presence indicator"> - <doc> - The bit type is used to indicate that a packing flag within a packed struct is being used to - represent a boolean value based on the presence of an empty value. The bit type has no value - and is encoded as an empty sequence of octets. - </doc> - </type> - - <!-- - ====================================================== - == CONSTANTS - ====================================================== - --> - - <!-- Protocol constants --> - - <constant name="MIN-MAX-FRAME-SIZE" value="4096" label="The minimum size (in bytes) which can be - agreed upon as the maximum frame size."> - <doc> - During the initial connection negotiation, the two peers must agree upon a maximum frame size. - This constant defines the minimum value to which the maximum frame size can be set. By - defining this value, the peers can guarantee that they can send frames of up to this size - until they have agreed a definitive maximum frame size for that connection. - </doc> - </constant> - - <!-- - ====================================================== - == DOMAIN TYPES - ====================================================== - --> - - <!-- Segment types --> - - <domain name="segment-type" type="uint8" label="valid values for the frame type indicator."> - <doc> - Segments are defined in <xref ref="specification.transport.assemblies_segments_and_frames"/>. - The segment domain defines the valid values that may be used for the segment indicator within - the frame header. - </doc> - - <enum> - <choice name="control" value="0"> - <doc> - The frame type indicator for Control segments (see <xref - ref="specification.formal_notation.controls"/>). - </doc> - </choice> - <choice name="command" value="1"> - <doc> - The frame type indicator for Command segments (see <xref - ref="specification.formal_notation.commands"/>). - </doc> - </choice> - <choice name="header" value="2" > - <doc> - The frame type indicator for Header segments (see <xref - ref="specification.formal_notation.segments.header"/>). - </doc> - </choice> - <choice name="body" value="3" > - <doc> - The frame type indicator for Body segments (see <xref - ref="specification.formal_notation.segments.body"/>). - </doc> - </choice> - </enum> - </domain> - - - <domain name="str16-array" type="array" label="An array of values of type str16."> - <doc> - An array of values of type str16. - </doc> - </domain> - - - - <!-- == Class: connection ==================================================================== --> - - <class name="connection" code="0x1" label="work with connections"> - <doc> - The connection class provides controls for two peers to establish a network connection, and - for both peers to operate the connection thereafter. Either peer may operate in the server or - client roles. - </doc> - - <doc type="grammar"> - connection = open-connection - *use-connection - close-connection - open-connection = C:protocol-header - S:OPEN C:OPEN - [ sasl-exchange ] - sasl-exchange = C:SASL-INIT *( S:SASL-CHALLENGE C:SASL-RESPONSE ) C:SASL-DONE - use-connection = *channel - close-connection = S:CLOSE C:CLOSE - </doc> - - <role name="server" implement="MUST" /> - <role name="client" implement="MUST" /> - - <domain name="close-code" type="uint16" label="code used in the connection.close control to - indicate reason for closure"> - <enum> - <choice name="normal" value="200"> - <doc> - The connection closed normally. - </doc> - </choice> - - <choice name="connection-forced" value="320"> - <doc> - An operator intervened to close the connection for some reason. The client may retry at - some later date. - </doc> - </choice> - - <choice name="authentication-failure" value="401"> - <doc> - The SASL authentication exchange failed. - </doc> - </choice> - - <choice name="invalid-path" value="402"> - <doc> - The client tried to work with an unknown virtual host. - </doc> - </choice> - - <choice name="framing-error" value="501"> - <doc> - A valid frame header cannot be formed from the incoming byte stream. - </doc> - </choice> - </enum> - </domain> - - <domain name="amqp-host-url" type="str16" label="URL for identifying an AMQP Server"> - <doc> - The amqp-url domain defines a format for identifying an AMQP Server. It is used to provide - alternate hosts in the case where a client has to reconnect because of failure, or because - the server requests the client to do so upon initial connection. - </doc> - <doc type="bnf"><![CDATA[ - amqp_url = "amqp:" prot_addr_list - prot_addr_list = [prot_addr ","]* prot_addr - prot_addr = tcp_prot_addr | tls_prot_addr - - tcp_prot_addr = tcp_id tcp_addr - tcp_id = "tcp:" | "" - tcp_addr = [host [":" port] ] - host = <as per http://www.ietf.org/rfc/rfc3986.txt> - port = number]]> - </doc> - </domain> - - <domain name="amqp-host-array" type="array" label="An array of values of type amqp-host-url"> - <doc> - Used to provide a list of alternate hosts. - </doc> - </domain> - - <domain name="sasl-code" type="uint8" label="indicates the disposition of the sasl dialog"> - <enum> - <choice name="ok" value="0"> - <doc> - The connection was successfully authenticated. - </doc> - </choice> - <choice name="authentication-failed" value="1"> - <doc> - Connection authentication failed. - </doc> - </choice> - </enum> - </domain> - - <!-- - Control: connection.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open" code="0x1" label="open connection to a virtual host"> - <doc> - This control opens a connection to a virtual host, which is a collection of resources, and - acts to separate multiple application domains within a server. The server may apply - arbitrary limits per virtual host, such as the number of each type of entity that may be - used, per connection and/or in total. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <rule name="protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, it MUST close - the socket connection without sending any response control. - </doc> - <doc type="scenario"> - The client sends a protocol header containing an invalid protocol name. The server must - respond by closing the connection. - </doc> - </rule> - - <rule name="client-support"> - <doc> - If the client cannot handle the protocol version suggested by the server it MUST close the - socket connection. - </doc> - <doc type="scenario"> - The server sends a protocol version that is lower than any valid implementation, e.g. 0.1. - The client must respond by closing the connection. - </doc> - </rule> - - <field name="virtual-host" type="str16" default="" label="virtual host name"> - <doc> - The name of the virtual host to which the connection is being opened. The default virtual - host is the virtual host with name of length zero. It is not mandatory to provide such a - virtual host. - </doc> - - <rule name="isolation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full isolation of - exchanges, queues, and all associated entities per virtual host. An application, - connected to a specific virtual host, MUST NOT be able to access resources of another - virtual host. - </doc> - </rule> - </field> - - <field name="max-frame-size" type="uint16" label="proposed maximum frame size"> - <doc> - The largest frame size that the peer proposes for the connection. If this is not set means - that the server does not impose any specific limit. - </doc> - - <rule name="established-max-frame-size"> - <doc> - The max-frame-size established for the connection is the minimum of the two proposed - values. If neither peer sets a max-frame-size the established max-frame-size is - (2^16)-1. - </doc> - </rule> - - <rule name="minimum"> - <doc> - Until the max-frame-size has been negotiated, both peers MUST accept frames of up to - MIN-MAX-FRAME-SIZE octets large. - </doc> - </rule> - - <rule name="frame-size-limit"> - <doc> - A peer MUST NOT send frames larger than the agreed-upon size. A peer that receives an - oversized frame MUST close the connection with the framing-error close-code. - </doc> - </rule> - </field> - - <field name="channel-max" type="uint16" - label="the maximum number of channels available for session attachment"> - <doc> - The maximum number of channels available for session attachment by the recipient. For a - typical client this would be zero. For a typical server this would be the maximum number - of supported channels. - </doc> - - <rule name="upper-limit"> - <doc> - The channel-max value may never exceed 2^15. - </doc> - </rule> - - <rule name="available-channels"> - <doc> - If a peer advertises a channel-max of N channels, then the channels available for - session attachment are precisely the channels numbered 0 to (N-1). - </doc> - </rule> - </field> - - <field name="heartbeat-interval" type="uint16" label="proposed heartbeat interval"> - <doc> - The proposed interval, in seconds, of the connection heartbeat desired by the sender. A - value of zero means heartbeats are not supported. If the value is not set, the sender - supports all heartbeat intervals. - </doc> - - <rule name="established-heartbeat"> - <doc> - The heartbeat-interval established is the minimum of the two proposed - heartbeat-intervals. If neither value is set, there is no heartbeat. - </doc> - </rule> - </field> - - <field name="sasl-server-mechanisms" type="str16-array" label="supported sasl mechanisms"> - <doc> - A list of the sasl security mechanisms supported by the sending peer. If the sending peer - does not require its partner to authenticate with it, this array may be empty or absent. - The server mechanisms are ordered in decreasing level of preference. - </doc> - </field> - - <field name="supported-locales" type="str16-array" label="locales that are supported"> - <doc> - A list of the locales that the peer supports. The locale defines the language in which the - peer will send protocol level error messages. This includes connection close text, reject - text, and session exception text. The default is the en_US locale. - </doc> - - <rule name="required-support"> - <doc> - The peer MUST support at least the en_US locale. Since this value is always supported, - it need not be supplied in the supported-locales array. - </doc> - </rule> - </field> - - <field name="preferred-locales" type="str16-array" - label="acceptable locales in decreasing level of preference"> - <doc> - A list of locales that the sending peer will accept. This list is ordered in decreasing - level of preference. The receiving partner will chose the most preferred locale from its - supported-locales list. If none of the preferred locales are supported, en_US will be - chosen. Note that en_US need not be supplied in this list as it always the fallback. - </doc> - </field> - - <field name="client-properties" type="map" label="client properties"> - <rule name="required-fields"> - <!-- This rule is not testable from the client side --> - <doc> - The properties SHOULD contain at least these fields: "product", giving the name of the - client product, "version", giving the name of the client version, "platform", giving the - name of the operating system, "copyright", if appropriate, and "information", giving - other general information. - </doc> - </rule> - </field> - - <field name="server-properties" type="map" label="server properties"> - <rule name="required-fields"> - <doc> - The properties SHOULD contain at least these fields: "host", specifying the server host - name or address, "product", giving the name of the server product, "version", giving the - name of the server version, "platform", giving the name of the operating system, - "copyright", if appropriate, and "information", giving other general information. - </doc> - <doc type="scenario"> - Client connects to server and inspects the server properties. It checks for the presence - of the required fields. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.sasl-init - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="sasl-init" code="0x2" label="initiate sasl exchange"> - <doc> - Selects the sasl mechanism and provides the initial response if needed. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="mechanism" type="str16" label="selected security mechanism" required="true"> - <doc> - The name of the SASL mechanism used for the SASL exchange. - </doc> - - <rule name="supported-mechanisms"> - <doc> - The mechanism chosen must be the one of the supported mechanisms supplied by the peer. - </doc> - </rule> - - <rule name="security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it can handle - from the list provided by the server. - </doc> - </rule> - - <rule name="validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms proposed by the - server in the connection.open control, the server MUST close the connection without - sending any further data. - </doc> - </rule> - </field> - - - <field name="initial-response" type="vbin32" label="security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this data are - defined by the SASL security mechanism. - </doc> - </field> - </control> - - <!-- - Control: connection.sasl-challenge - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="sasl-challenge" code="0x3" label="security mechanism challenge"> - <implement role="client" handle="MUST" /> - - <response name="sasl-response" /> - - <field name="challenge" type="vbin32" label="security challenge data" required="true"> - <doc> - Challenge information, a block of opaque binary data passed to the security mechanism. - </doc> - </field> - </control> - - <!-- - Control: connection.sasl-response - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="sasl-response" code="0x4" label="security mechanism response"> - <doc> - This control attempts to authenticate, passing a block of SASL data for the security - mechanism at the server side. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="response" type="vbin32" label="security response data" required="true"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this data are - defined by the SASL security mechanism. - </doc> - </field> - </control> - - <!-- - Control: connection.sasl-done - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="sasl-done" code="0x5" label="terminate sasl dialog"> - <doc> - This control terminates the sasl dialog. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="code" type="sasl-code" label="indicates the disposition of the sasl dialog"> - <doc> - A reply-code indicating the disposition of the sasl dialog. - </doc> - </field> - </control> - - <!-- - Control: connection.heartbeat - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="heartbeat" code="0x6" label="indicates connection is still alive"> - <doc> - The heartbeat control may be used to generate artificial network traffic when a connection - is idle. If a connection is idle for more than twice the negotiated heartbeat delay, the - peers MAY be considered disconnected. - </doc> - </control> - - <!-- - Control: connection.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="close" code="0x7" label="request a connection close"> - <doc> - This control indicates that the sender wants to close the connection. The reason for close - is indicated with the reply-code and reply-text. The channel this control is sent on MAY be - used to indicate which channel caused the connection to close. - </doc> - - <implement role="client" handle="MUST" /> - <implement role="server" handle="MUST" /> - - <field name="reply-code" type="close-code" label="the numeric reply code" - required="true"> - <doc> - Indicates the reason for connection closure. - </doc> - </field> - <field name="reply-text" type="str8" label="the localized reply text"> - <doc> - This text can be logged as an aid to resolving issues. - </doc> - </field> - </control> - </class> - - <!-- == Class: session ======================================================================= --> - - <class name="session" code="0x2" label="session controls"> - <doc> - A session is a named interaction between two peers. Session names are chosen by the upper - layers and may be used indefinitely. The model layer may associate long-lived or durable state - with a given session name. The session layer provides transport of commands associated with - this interaction. - </doc> - - <doc type="picture"><![CDATA[ - Sender: Receiver: - |--in-flight--| - +--------------+--------------------------+ +-----------------+-----------+ - | C1 C2 C3 | C4 C5 C6 C7 C8 C9 | ------> | C1 C2 C3 C4 | C5 C6 | - +--------------+--------------------------+ +-----------------+-----------+ - complete replay queue complete work queue - - C1, C2, C3: completed at the receiver, known to be completed by the sender - C4: completed at the receiver, *not* known to be completed by the sender - C5, C6: received by the sender, but not yet completed - C7, C8, C9: transmitted by the sender, but not yet received - - Sender state: - last-completed: marks the tail of replay queue - last-sent: marks the head of replay queue - - Receiver state: - last-completed: marks the tail of the work queue - last-received: marks the head of work queue - - State exchanged periodically between the two endpoints of a full - duplex session. Each endpoint has both a sender and a receiver: - - (sender-completed, receiver-completed) - /|\ /|\ - | | - | allows the sender to shrink replay queue - | - allows the receiver to know that sender won't replay - - State exchanged between the two endpoints on open/resume: - - (last-sent, last-received) - /|\ /|\ - | | - | tells sender where to resume from - | (null for open) - | - tells receiver where to start counting command-ids on open - (null for resume)]]> - </doc> - - <doc> - The controls defined within this class are specified in terms of the "sender" of commands and - the "receiver" of commands. Since both client and server send and receive commands, the - overall session dialog is symmetric, however the semantics of the session controls are defined - in terms of a single sender/receiver pair, and it is assumed that the client and server will - each contain both a sender and receiver implementation. - </doc> - - <rule name="attachment"> - <doc> - The transport MUST be attached in order to use any control other than "attach", "attached", - "detach", or "detached". A peer receiving any other control on a detached transport MUST - discard it and send a session.detached with the "not-attached" reason code. - </doc> - </rule> - - <role name="server" implement="MUST" /> - <role name="client" implement="MUST" /> - - <role name="sender" implement="MUST"> - <doc> - The sender of commands. - </doc> - </role> - <role name="receiver" implement="MUST"> - <doc> - The receiver of commands. - </doc> - </role> - - <domain name="name" type="vbin16" label="opaque session name"> - <doc> - The session name uniquely identifies an interaction between two peers. It is scoped to a - given authentication principal. - </doc> - </domain> - - <domain name="detach-code" type="uint8" label="reason for detach"> - <enum> - <choice name="normal" value="0"> - <doc> - The session was detached by request. - </doc> - </choice> - <choice name="session-busy" value="1"> - <doc> - The session is currently attached to another transport. - </doc> - </choice> - <choice name="transport-busy" value="2"> - <doc> - The transport is currently attached to another session. - </doc> - </choice> - <choice name="not-attached" value="3"> - <doc> - The transport is not currently attached to any session. - </doc> - </choice> - <choice name="unknown-ids" value="4"> - <doc> - Command data was received prior to any use of the command-point control. - </doc> - </choice> - </enum> - </domain> - - <domain name="commands" type="sequence-set" label="identifies a set of commands"> - </domain> - - <struct name="exception" size="2" pack="2" label="notifies a peer of an execution error"> - <doc> - This command informs a peer of an execution exception. The command-id, when given, - correlates the error to a specific command. - </doc> - - <field name="error-code" type="error-code" required="true" label="error code indicating the - type of error"/> - <field name="command-id" type="sequence-no" label="exceptional command"> - <doc> - The command-id of the command which caused the exception. If the exception was not caused - by a specific command, this value is not set. - </doc> - </field> - <field name="class-code" type="uint8" label="the class code of the command whose execution - gave rise to the error (if appropriate)"/> - <field name="command-code" type="uint8" label="the class code of the command whose execution - gave rise to the error (if appropriate)"/> - <field name="field-index" type="uint8" label="index of the exceptional field"> - <doc> - The zero based index of the exceptional field within the arguments to the exceptional - command. If the exception was not caused by a specific field, this value is not set. - </doc> - </field> - <field name="description" type="str16" label="descriptive text on the exception"> - <doc> - The description provided is implementation defined, but MUST be in the language - appropriate for the selected locale. The intention is that this description is suitable - for logging or alerting output. - </doc> - </field> - <field name="error-info" type="map" label="map to carry additional information about the - error"/> - </struct> - - <control name="attach" code="0x1" label="attach to the named session"> - <doc> - Requests that the current transport be attached to the named session. Success or failure - will be indicated with an attached or detached response. This control is idempotent. - </doc> - - <rule name="one-transport-per-session"> - <doc> - A session MUST NOT be attached to more than one transport at a time. - </doc> - </rule> - - <rule name="one-session-per-transport"> - <doc> - A transport MUST NOT be attached to more than one session at a time. - </doc> - </rule> - - <rule name="idempotence"> - <doc> - Attaching a session to its current transport MUST succeed and result in an attached - response. - </doc> - </rule> - - <rule name="scoping"> - <doc> - Attachment to the same session name from distinct authentication principals MUST succeed. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="name" type="name" label="the session name" required="true"> - <doc> - Identifies the session to be attached to the current transport. - </doc> - </field> - - <field name="force" type="bit" label="force attachment to a busy session"> - <doc> - If set then a busy session will be forcibly detached from its other transport and - reattached to the current transport. - </doc> - </field> - - <field name="exists" type="bit" label="true iff the session exists at the endpoint"/> - - <field name="first-unsent" type="sequence-no"> -<!-- XXX - <control name="command-point" code="0x7" - label="the command id and byte offset of subsequent data"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. This - establishes the sequence numbers associated with all subsequent command data sent from the - sender to the receiver. The subsequent command data will be numbered starting with the - values supplied in this control and proceeding sequentially. This must be used at least once - prior to sending any command data on newly attached transports. - </doc> - - <rule name="newly-attached-transports"> - <doc> - If command data is sent on a newly attached transport the session MUST be detached with an - "unknown-id" reason-code. - </doc> - </rule> - - <rule name="zero-offset"> - <doc> - If the offset is zero, the next data frame MUST have the first-frame and first-segment - flags set. Violation of this is a framing error. - </doc> - </rule> - - <rule name="nonzero-offset"> - <doc> - If the offset is nonzero, the next data frame MUST NOT have both the first-frame and - first-segment flag set. Violation of this is a framing error. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="command-id" type="sequence-no" label="the command-id of the next command" - required="true"/> - </control> ---> - </field> - - <field name="first-resendable" type="sequence-no"> - <doc> - The id of the first command the peer can resend, this may be null. - </doc> - </field> - - <field name="last-received" type="sequence-no" label="the id of the last command received"> - <doc> - This field carries the id of the last command received by this peer for the session. This - field MUST be set if and only if the session has received commands. - </doc> - </field> - - <field name="requested-timeout" type="uint32" label="the requested timeout"> - <doc> - The requested timeout for execution state in seconds. If not set, this control requests - that execution state is preserved for the maximum duration permitted by the receiving - peer. - </doc> - -<!-- XXX - <control name="request-timeout" code="0x5" label="requests the execution timeout be changed"> - <doc> - This control may be sent by either the sender or receiver of commands. It requests that the - execution timeout be changed. This is the minimum amount of time that a peer must preserve - execution state for a detached session. - </doc> - - <rule name="maximum-granted-timeout"> - <doc> - The handler of this request MUST set his timeout to the maximum allowed value less than or - equal to the requested timeout, and MUST convey the chosen timeout in the response. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - <implement role="receiver" handle="MUST" /> - - <response name="timeout"/> - - <field name="timeout" type="uint32" label="the requested timeout"> - <doc> - The requested timeout for execution state in seconds. If not set, this control requests - that execution state is preserved indefinitely. - </doc> - </field> - </control> - - <control name="timeout" code="0x6" label="the granted timeout"> - <doc> - This control may be sent by the either the sender or receiver of commands. It is a - one-to-one reply to the request-timeout control that indicates the granted timeout for - execution state. - </doc> - - <implement role="sender" handle="MUST" /> - <implement role="receiver" handle="MUST" /> - - <field name="timeout" type="uint32" label="the execution timeout"> - <doc> - The timeout for execution state. If not set, then execution state is preserved - indefinitely. - </doc> - </field> - </control> ---> - </field> - </control> - - <control name="detach" code="0x3" label="detach from the named session"> - <doc> - Signals the end of communication on this channel for this session in this direction. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="name" type="name" label="the session name" required="true"> - <doc> - Identifies the detached session. - </doc> - </field> - <field name="code" type="detach-code" label="the reason for detach" required="true"> - <doc> - Identifies the reason for detaching from the named session. - </doc> - </field> - <field name="last-successful" type="sequence-no"/> - <field name="exception" type="exception"/> - </control> - - <!-- - Execution state is the set of completed incoming commands, as well as the set of outgoing - in-doubt commands held for replay. - --> - - <control name="state" code="0xa" label="carries periodic updates of session state between - endpoints"> - <doc> - This control carries ongoing session state between the two session endpoints. - </doc> - - <implement role="sender" handle="MUST" /> - <implement role="receiver" handle="MUST" /> - - <field name="flush" type="bit" label="requests that the peer send its state"> - <doc> - If set, the peer must respond with the state if its own session endpoint. - </doc> - </field> - - <field name="receiver-completed" type="sequence-no" label="last incoming command completed"> - <doc> - The id of the last incoming command completed by the receiver. - </doc> - </field> - - <field name="sender-completed" type="sequence-no" label="last outgoing command completed"> - <doc> - The id of the last outgoing command known by the sender to be complete. - </doc> - </field> - </control> - -<!-- </class> --> - - <!-- == Class: execution ===================================================================== --> - -<!-- <class name="execution" code="0x3" label="execution commands"> --> - <doc> - The execution class provides commands that carry execution information about other model level - commands. - </doc> - - <role name="server" implement="MUST"/> - <role name="client" implement="MUST"/> - - <domain name="error-code" type="uint16"> - <enum> - <choice name="unauthorized-access" value="403"> - <doc> - The client attempted to work with a server entity to which it has no access due to - security settings. - </doc> - </choice> - - <choice name="not-found" value="404"> - <doc> - The client attempted to work with a server entity that does not exist. - </doc> - </choice> - - <choice name="resource-locked" value="405"> - <doc> - The client attempted to work with a server entity to which it has no access because - another client is working with it. - </doc> - </choice> - - <choice name="precondition-failed" value="406"> - <doc> - The client requested a command that was not allowed because some precondition failed. - </doc> - </choice> - - <choice name="resource-deleted" value="408"> - <doc> - A server entity the client is working with has been deleted. - </doc> - </choice> - - <choice name="illegal-state" value="409"> - <doc> - The peer sent a command that is not permitted in the current state of the session. - </doc> - </choice> - - <choice name="command-invalid" value="503"> - <doc> - The command segments could not be decoded. - </doc> - </choice> - - <choice name="resource-limit-exceeded" value="506"> - <doc> - The client exceeded its resource allocation. - </doc> - </choice> - - <choice name="not-allowed" value="530"> - <doc> - The peer tried to use a command a manner that is inconsistent with the rules described - in the specification. - </doc> - </choice> - - <choice name="illegal-argument" value="531"> - <doc> - The command argument is malformed, i.e. it does not fall within the specified domain. - The illegal-argument exception can be raised on execution of any command which has - domain valued fields. - </doc> - </choice> - - <choice name="not-implemented" value="540"> - <doc> - The peer tried to use functionality that is not implemented in its partner. - </doc> - </choice> - - <choice name="internal-error" value="541"> - <doc> - The peer could not complete the command because of an internal error. The peer may - require intervention by an operator in order to resume normal operations. - </doc> - </choice> - - <choice name="invalid-argument" value="542"> - <doc> - An invalid argument was passed to a command, and the operation could not - proceed. An invalid argument is not illegal (see illegal-argument), i.e. it matches - the domain definition; however the particular value is invalid in this context. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: execution.sync - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="sync" code="0xb" label="request notification of completion for issued commands"> - <doc> - This command is complete when all prior commands are completed. - </doc> - - <implement role="server" handle="MUST"/> - <implement role="client" handle="MUST"/> - </command> - - <!-- - Command: execution.result - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="result" code="0xc" label="carries execution results"> - <doc> - This command carries data resulting from the execution of a command. - </doc> - - <implement role="server" handle="MUST"/> - <implement role="client" handle="MUST"/> - - <field name="command-id" type="sequence-no" required="true"/> - <field name="value" type="struct32"/> - </command> - - </class> - - <!-- == Class: message ======================================================================= --> - - <class name="message" code="0x4" label="message transfer"> - <doc> - The message class provides commands that support an industry-standard messaging model. - </doc> - - <doc type="picture" title="Transfer States"> - START: - - The message has yet to be sent to the recipient. - - NOT-ACQUIRED: - - The message has been sent to the recipient, but is not - acquired by the recipient. - - ACQUIRED: - - The message has been sent to and acquired by the recipient. - - END: - - The transfer is complete. - </doc> - - <doc type="picture" title="State Transitions"><![CDATA[ - *:TRANSFER (accept-mode=none) *:TRANSFER (acquire-mode=pre-acquired) - +---------------------------------START------------------------------------------+ - | | | - | | *:TRANSFER (acquire-mode=not-acquired) | - | | | - | R:RELEASE \|/ | - | +-------------NOT-ACQUIRED<--+ | - | | | | | R:ACQUIRE (if unavailable) | - | | | +-----+ | - | | | | - | | | R:ACQUIRE (if available) | - | | | | - | | \|/ | - | | ACQUIRED<-------------------------------------------+ - | | | - | | | R:ACCEPT / R:REJECT / R:RELEASE - | | | - | | \|/ - | +------------->END - | /|\ - | | - +-------------------------------+]]> - </doc> - - <doc type="grammar"> - message = *:TRANSFER [ R:ACQUIRE ] [ R:ACCEPT / R:REJECT / R:RELEASE ] - / *:RESUME - / *:SET-FLOW-MODE - / *:FLOW - / *:STOP - / C:SUBSCRIBE - / C:CANCEL - / C:FLUSH - </doc> - - <rule name="persistent-message"> - <doc> - The server SHOULD respect the delivery-mode property of messages and SHOULD make a - best-effort to hold persistent messages on a reliable storage mechanism. - </doc> - <doc type="scenario"> - Send a persistent message to queue, stop server, restart server and then verify whether - message is still present. Assumes that queues are durable. Persistence without durable - queues makes no sense. - </doc> - </rule> - - <rule name="no-persistent-message-discard"> - <doc> - The server MUST NOT discard a persistent message in case of a queue overflow. - </doc> - <doc type="scenario"> - Create a queue overflow situation with persistent messages and verify that messages do not - get lost (presumably the server will write them to disk). - </doc> - </rule> - - <rule name="throttling"> - <doc> - The server MAY use the message.flow command to slow or stop a message publisher when - necessary. - </doc> - </rule> - - <rule name="non-persistent-message-overflow"> - <doc> - The server MAY overflow non-persistent messages to persistent storage. - </doc> - </rule> - - <rule name="non-persistent-message-discard"> - <doc> - The server MAY discard or dead-letter non-persistent messages on a priority basis if the - queue size exceeds some configured limit. - </doc> - </rule> - - <rule name="min-priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for messages, where priorities 0 and - 9 are treated as two distinct levels. - </doc> - </rule> - - <rule name="priority-level-implementation"> - <doc> - The server SHOULD implement distinct priority levels in the following manner: - </doc> - <doc> - If the server implements n distinct priorities then priorities 0 to 5 - ceiling(n/2) should - be treated equivalently and should be the lowest effective priority. The priorities 4 + - floor(n/2) should be treated equivalently and should be the highest effective priority. The - priorities (5 - ceiling(n/2)) to (4 + floor(n/2)) inclusive must be treated as distinct - priorities. - </doc> - <doc> - Thus, for example, if 2 distinct priorities are implemented, then levels 0 to 4 are - equivalent, and levels 5 to 9 are equivalent and levels 4 and 5 are distinct. If 3 distinct - priorities are implements the 0 to 3 are equivalent, 5 to 9 are equivalent and 3, 4 and 5 - are distinct. - </doc> - <doc> - This scheme ensures that if two priorities are distinct for a server which implements m - separate priority levels they are also distinct for a server which implements n different - priority levels where n > m. - </doc> - </rule> - - <rule name="priority-delivery"> - <doc> - The server MUST deliver messages of the same priority in order irrespective of their - individual persistence. - </doc> - <doc type="scenario"> - Send a set of messages with the same priority but different persistence settings to a queue. - Subscribe and verify that messages arrive in same order as originally published. - </doc> - </rule> - - <role name="server" implement="MUST" /> - <role name="client" implement="MUST" /> - - <domain name="message-id" type="uuid" label="globally unique message id"/> - - <domain name="accept-mode" type="uint8" label="indicates a confirmation mode"> - <doc> - Controls how the sender of messages is notified of successful transfer. - </doc> - - <enum> - <choice name="explicit" value="0"> - <doc> - Successful transfer is signaled by message.accept. An acquired message (whether - acquisition was implicit as in pre-acquired mode or explicit as in not-acquired mode) is - not considered transferred until a message.accept that includes the transfer command is - received. - </doc> - </choice> - - <choice name="none" value="1"> - <doc> - Successful transfer is assumed when accept-mode is "pre-acquired". Messages transferred - with an accept-mode of "not-acquired" cannot be acquired when accept-mode is "none". - </doc> - </choice> - </enum> - </domain> - - <domain name="acquire-mode" type="uint8" label="indicates the transfer mode"> - <doc> - Indicates whether a transferred message can be considered as automatically acquired or - whether an explicit request is necessary in order to acquire it. - </doc> - - <enum> - <choice name="pre-acquired" value="0"> - <doc> - the message is acquired when the transfer starts - </doc> - </choice> - - <choice name="not-acquired" value="1"> - <doc> - the message is not acquired when it arrives, and must be explicitly acquired by the - recipient - </doc> - </choice> - </enum> - </domain> - - <domain name="reject-code" type="uint16" label="reject code for transfer"> - <doc> - Code specifying the reason for a message reject. - </doc> - <enum> - <choice name="unspecified" value="0"> - <doc> - Rejected for an unspecified reason. - </doc> - </choice> - <choice name="unroutable" value="1"> - <doc> - Delivery was attempted but there were no queues which the message could be routed to. - </doc> - </choice> - </enum> - </domain> - -<!-- - <domain name="resume-id" type="str16"> - <doc> - A resume-id serves to identify partially transferred message content. The id is chosen by - the sender, and must be unique to a given user. A resume-id is not expected to be unique - across users. - </doc> - </domain> ---> - - <domain name="delivery-mode" type="uint8" - label="indicates whether a message should be treated as transient or durable"> - <doc> - - Used to set the reliability requirements for a message which is transferred to the server. - </doc> - <enum> - <choice name="non-persistent" value="1"> - <doc> - A non-persistent message may be lost in event of a failure, but the nature of the - communication is such that an occasional message loss is tolerable. This is the lowest - overhead mode. Non-persistent messages are delivered at most once only. - </doc> - </choice> - - <choice name="persistent" value="2"> - <doc> - A persistent message is one which must be stored on a persistent medium (usually hard - drive) at every stage of delivery so that it will not be lost in event of failure (other - than of the medium itself). This is normally accomplished with some additional overhead. - A persistent message may be delivered more than once if there is uncertainty about the - state of its delivery after a failure and recovery. - </doc> - </choice> - </enum> - </domain> - - <domain name="delivery-priority" type="uint8" - label="indicates the desired priority to assign to a message transfer"> - <doc> - Used to assign a priority to a message transfer. Priorities range from 0 (lowest) to 9 - (highest). - </doc> - <enum> - <choice name="lowest" value="0"> - <doc> - Lowest possible priority message. - </doc> - </choice> - - <choice name="lower" value="1"> - <doc> - Very low priority message - </doc> - </choice> - - <choice name="low" value="2"> - <doc> - Low priority message. - </doc> - </choice> - - <choice name="below-average" value="3"> - <doc> - Below average priority message. - </doc> - </choice> - - <choice name="medium" value="4"> - <doc> - Medium priority message. - </doc> - </choice> - - - <choice name="above-average" value="5"> - <doc> - Above average priority message - </doc> - </choice> - - - <choice name="high" value="6"> - <doc> - High priority message - </doc> - </choice> - - <choice name="higher" value="7"> - <doc> - Higher priority message - </doc> - </choice> - - <choice name="very-high" value="8"> - <doc> - Very high priority message. - </doc> - </choice> - - <choice name="highest" value="9"> - <doc> - Highest possible priority message. - </doc> - </choice> - </enum> - </domain> - - <struct name="delivery-properties" size="4" code="0x1" pack="2"> - <field name="accept-mode" type="accept-mode" required="true"> - <doc> - Indicates whether message.accept, session.complete, or nothing at all is required to - indicate successful transfer of the message. - </doc> - </field> - - <field name="acquire-mode" type="acquire-mode" required="true"> - <doc> - Indicates whether or not the transferred message has been acquired. - </doc> - </field> - - <field name="discard-unroutable" type="bit" label="controls discard of unroutable messages"> - <doc> - If set on a message that is not routable the broker can discard it. If not set, an - unroutable message should be handled by reject when accept-mode is explicit; or by routing - to the alternate-exchange if defined when accept-mode is none. - </doc> - </field> - - <field name="redelivered" type="bit" label="redelivery flag"> - <doc> - This boolean flag indicates that the message may have been previously delivered to this - or another client. - </doc> - <doc> - If the redelivered flag is set on transfer to a Server, then any delivery of the message - from that Server to a Client must also have the redelivered flag set to true. - </doc> - <rule name="implementation"> - <doc> - The server MUST try to signal redelivered messages when it can. When redelivering a - message that was not successfully accepted, the server SHOULD deliver it to the original - client if possible. - </doc> - <doc type="scenario"> - Create a shared queue and publish a message to the queue. Subscribe using explicit - accept-mode, but do not accept the message. Close the session, reconnect, and subscribe - to the queue again. The message MUST arrive with the redelivered flag set. - </doc> - </rule> - <rule name="hinting"> - <doc> - The client should not rely on the redelivered field to detect duplicate messages where - publishers may themselves produce duplicates. A fully robust client should be able to - track duplicate received messages on non-transacted, and locally-transacted sessions. - </doc> - </rule> - </field> - - <field name="priority" type="delivery-priority" label="message priority, 0 to 9" - required="true"> - <doc> Message priority, which can be between 0 and 9. Messages with higher priorities may be - delivered before those with lower priorities. </doc> - </field> - - <field name="delivery-mode" type="delivery-mode" label="message persistence requirement" - required="true"> - <doc> The delivery mode may be non-persistent or persistent. </doc> - </field> - - <field name="ttl" type="uint64" label="time to live in ms"> - <doc> Duration in milliseconds for which the message should be considered "live". If this is - set then a message expiration time will be computed based on the current time plus this - value. Messages that live longer than their expiration time will be discarded (or dead - lettered).</doc> - <rule name="ttl-decrement"> - <doc> - If a message is transferred between brokers before delivery to a final subscriber the - ttl should be decremented before peer to peer transfer and both timestamp and expiration - should be cleared. - </doc> - </rule> - </field> - - <field name="timestamp" type="datetime" label="message timestamp"> - <doc> - The timestamp is set by the broker on arrival of the message. - </doc> - </field> - - <field name="expiration" type="datetime" label="message expiration time"> - <doc> - The expiration header assigned by the broker. After receiving the message the broker sets - expiration to the sum of the ttl specified in the publish command and the current time. - (ttl=expiration - timestamp) - </doc> - </field> - - <field name="exchange" type="exchange.name" label="originating exchange"> - <doc> - Identifies the exchange specified in the destination field of the message.transfer used to - publish the message. This MUST be set by the broker upon receipt of a message. - </doc> - </field> - - <field name="routing-key" type="str8" label="message routing key"> - <doc> - The value of the key determines to which queue the exchange will send the message. The way - in which keys are used to make this routing decision depends on the type of exchange to - which the message is sent. For example, a direct exchange will route a message to a queue - if that queue is bound to the exchange with a binding-key identical to the routing-key of - the message. - </doc> - </field> - -<!-- - <field name="resume-id" type="resume-id" label="global id for message transfer"> - <doc> - When a resume-id is provided the recipient MAY use it to retain message data should the - session expire while the message transfer is still incomplete. - </doc> - </field> ---> - - <field name="resume-ttl" type="uint64" label="ttl in ms for interrupted message data"> - <doc> - When a resume-ttl is provided the recipient MAY use it has a guideline for how long to - retain the partially complete data. - </doc> - </field> - </struct> - -<!-- XXX - <struct name="reply-to" size="2" pack="2"> - <doc>The reply-to domain provides a simple address structure for replying to to a message to a - destination within the same virtual-host.</doc> - <field name="exchange" type="exchange.name" label="the name of the exchange to reply to"/> - <field name="routing-key" type="str8" label="the routing-key to use when replying"/> - </struct> ---> - - <struct name="message-properties" size="4" code="0x3" pack="2"> - <field name="content-length" type="uint64" label="length of the body segment in bytes"> - <doc> - The length of the body segment in bytes. - </doc> - </field> - - <field name="message-id" type="message-id" label="application message identifier"> - <doc> - Message-id is an optional property of UUID type which uniquely identifies a message within - the message system. The message producer is usually responsible for setting the - message-id. The server MAY discard a message as a duplicate if the value of the message-id - matches that of a previously received message. Duplicate messages MUST still be accepted - if transferred with an accept-mode of "explicit". - </doc> - - <rule name="unique"> - <doc> - A message-id MUST be unique within a given server instance. A message-id SHOULD be - globally unique (i.e. across different systems). - </doc> - </rule> - - <rule name="immutable"> - <doc> - A message ID is immutable. Once set, a message-id MUST NOT be changed or reassigned, - even if the message is replicated, resent or sent to multiple queues. - </doc> - </rule> - </field> - - <field name="correlation-id" type="vbin16" label="application correlation identifier"> - <doc> - This is a client-specific id that may be used to mark or identify messages between - clients. The server ignores this field. - </doc> - </field> - - <field name="reply-to" type="route.address" label="destination to reply to"> - <doc> - The destination of any message that is sent in reply to this message. - </doc> - </field> - - <field name="content-type" type="str8" label="MIME content type"> - <doc> - The RFC-2046 MIME type for the message content (such as "text/plain"). This is set by the - originating client. - </doc> - </field> - - <field name="content-encoding" type="str8" label="MIME content encoding"> - <doc> - The encoding for character-based message content. This is set by the originating client. - Examples include UTF-8 and ISO-8859-15. - </doc> - </field> - - <field name="user-id" type="vbin16" label="creating user id"> - <doc> - The identity of the user responsible for producing the message. The client sets this - value, and it is authenticated by the broker. - </doc> - - <rule name="authentication"> - <doc> - The server MUST produce an unauthorized-access exception if the user-id field is set to - a principle for which the client is not authenticated. - </doc> - </rule> - </field> - - <field name="app-id" type="vbin16" label="creating application id"> - <doc> - The identity of the client application responsible for producing the message. - </doc> - </field> - -<!-- XXX: moved to top level headers map - <field name="application-headers" type="map" label="application specific headers table"> - <doc> - This is a collection of user-defined headers or properties which may be set by the - producing client and retrieved by the consuming client. - </doc> - </field> ---> - </struct> - - <!-- - Command: message.transfer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="transfer" code="0x1" label="transfer a message"> - <doc> - This command transfers a message between two peers. When a client uses this command to - publish a message to a broker, the destination identifies a specific exchange. The message - will then be routed to queues as defined by the exchange configuration. - - The client may request a broker to transfer messages to it, from a particular queue, by - issuing a subscribe command. The subscribe command specifies the destination that the broker - should use for any resulting transfers. - </doc> - - <rule name="transactional-publish"> - <doc> - If a transfer to an exchange occurs within a transaction, then it is not available from - the queue until the transaction commits. It is not specified whether routing takes place - when the transfer is received or when the transaction commits. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - - <field name="route" type="uint64" label="handle for message route"> - <doc> - Specifies the destination to which the message is to be transferred. - </doc> - - <rule name="blank-destination"> - <doc> - The server MUST accept a blank destination to mean the default exchange. - </doc> - </rule> - - <exception name="nonexistent-exchange" error-code="not-found"> - <doc> - If the destination refers to an exchange that does not exist, the peer MUST raise a - session exception. - </doc> - </exception> - </field> - - <field name="more" type="bit" label="indicates that this message has more content"/> - - <field name="fragment-offset" type="uint64" label="the offset of payload within the message"/> - - <field name="headers" type="map" label="message headers"> - <doc type="picture" title="Standard Entries"> - "delivery-properties" -> delivery-properties - "message-properties" -> message-properties - "application-headers" -> map - </doc> - </field> - - <field name="payload" type="vbin32" label="message data"/> - </command> - - <!-- - Command: message.accept - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="accept" code="0x2" label="reject a message"> - <doc> - Accepts the message. Once a transfer is accepted, the command-id may no longer be referenced - from other commands. - </doc> - - <rule name="acquisition"> - <doc> - The recipient MUST have acquired a message in order to accept it. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="transfers" type="session.commands" required="true"> - <doc> - Identifies the messages previously transferred that should be accepted. - </doc> - </field> - </command> - - <!-- - Command: message.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="reject" code="0x3" label="reject a message"> - <doc> - Indicates that the message transfers are unprocessable in some way. A server may reject a - message if it is unroutable. A client may reject a message if it is invalid. A message may - be rejected for other reasons as well. Once a transfer is rejected, the command-id may no - longer be referenced from other commands. - </doc> - - <rule name="alternate-exchange"> - <doc> - When a client rejects a message, the server MUST deliver that message to the - alternate-exchange on the queue from which it was delivered. If no alternate-exchange is - defined for that queue the broker MAY discard the message. - </doc> - </rule> - - <rule name="acquisition"> - <doc> - The recipient MUST have acquired a message in order to reject it. If the message is not - acquired any reject MUST be ignored. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="transfers" type="session.commands" required="true"> - <doc> - Identifies the messages previously transferred that should be rejected. - </doc> - </field> - <field name="code" type="reject-code" required="true"> - <doc> - Code describing the reason for rejection. - </doc> - </field> - <field name="text" type="str8" label="informational text for message reject"> - <doc> - Text describing the reason for rejection. - </doc> - </field> - </command> - - <!-- - Command: message.release - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="release" code="0x4" label="release a message"> - <doc> - Release previously transferred messages. When acquired messages are released, they become - available for acquisition by any subscriber. Once a transfer is released, the command-id may - no longer be referenced from other commands. - </doc> - - <rule name="ordering"> - <doc> - Acquired messages that have been released MAY subsequently be delivered out of order. - Implementations SHOULD ensure that released messages keep their position with respect to - undelivered messages of the same priority. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MAY" /> - - <field name="transfers" type="session.commands" required="true"> - <doc> - Indicates the messages to be released. - </doc> - </field> - <field name="set-redelivered" type="bit" label="mark the released messages as redelivered"> - <doc> - By setting set-redelivered to true, any acquired messages released to a queue with this - command will be marked as redelivered on their next transfer from that queue. If this flag - is not set, then an acquired message will retain its original redelivered status on the - queue. Messages that are not acquired are unaffected by the value of this flag. - </doc> - </field> - </command> - - <!-- - Command: message.acquire - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="acquire" code="0x5" label="acquire messages for consumption"> - <doc> - Acquires previously transferred messages for consumption. The acquired ids (if any) are - sent via message.acquired. - </doc> - - <rule name="one-to-one"> - <doc> - Each acquire MUST produce exactly one message.acquired even if it is empty. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="transfers" type="session.commands" required="true"> - <doc> - Indicates the messages to be acquired. - </doc> - </field> - - <result> - <struct name="acquired" size="4" code="0x4" pack="2" label="indicates acquired messages"> - <doc> - Identifies a set of previously transferred messages that have now been acquired. - </doc> - - <field name="transfers" type="session.commands" required="true"> - <doc> - Indicates the acquired messages. - </doc> - </field> - </struct> - </result> - </command> - - </class> - - <!-- == Class: route ========================================================================= --> - - <class name="route" code="0xff" label="flow control routes"> - - <role name="server" implement="MUST" /> - <role name="client" implement="MUST" /> - - <domain name="address" type="str16" label="source or destination for a message"> - <doc> - Specifies the source or destination to which the message is to be transferred to or from. - </doc> - </domain> - - <domain name="flow-mode" type="uint8" label="the flow-mode for allocating flow credit"> - <enum> - <choice name="credit" value="0"> - <doc> - Credit based flow control. - </doc> - </choice> - - <choice name="window" value="1"> - <doc> - Window based flow control. - </doc> - </choice> - </enum> - </domain> - - <command name="open" code="0xfe" label="open a destination for transfer"> - <implement role="server" handle="MUST" /> - - <field name="name" type="str8" label="the name of the route" required="true" /> - - <field name="address" type="address" required="true"> - <exception name="destination-not-found" error-code="not-found"> - <doc>If the destination does not exist, the recipient MUST close the session.</doc> - </exception> - </field> - - <field name="durable" type="bit" label="indicates that the route is durable"/> - - <field name="read" type="bit" label="requests that messages be sent from the address"/> - - <field name="write" type="bit" label="indicates that messages will be sent to the address"/> - - <field name="resume-id" type="message.message-id"> - <doc> - If present, indicates that the sender can resume transfer of the given message-id. - </doc> - </field> - </command> - - <command name="close" code="0xff" label="notify of destination closure"> - <!-- XXX - <doc> - This command cancels a subscription. This does not affect already delivered messages, but - it does mean the server will not send any more messages for that subscription. The client - may receive an arbitrary number of messages in between sending the cancel command and - receiving notification that the cancel command is complete. - </doc> - --> - - <field name="name" type="str8" required="true"/> - <field name="read" type="bit" label="close for read"/> - <field name="write" type="bit" label="close for write"/> - </command> - - <!-- - Command: route.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="start" code="0x7" label="start a queue subscription"> - <doc> - This command asks the server to start a "subscription", which is a request for messages from - a specific queue. Subscriptions last as long as the session they were created on, or until - the client cancels them. - </doc> - - <rule name="simultaneous-subscriptions"> - <doc> - The server SHOULD support at least 16 subscriptions per queue, and ideally, impose no - limit except as defined by available resources. - </doc> - <doc type="scenario"> - Create a queue and create subscriptions on that queue until the server closes the - connection. Verify that the number of subscriptions created was at least sixteen and - report the total number. - </doc> - </rule> - - <rule name="default-flow-mode"> - <doc> The default flow mode for new subscriptions is window-mode. </doc> - </rule> - - <exception name="queue-deletion" error-code="resource-deleted"> - <doc> - If the queue for this subscription is deleted, any subscribing sessions MUST be closed. - This exception may occur at any time after the subscription has been completed. - </doc> - </exception> - - <exception name="queue-not-found" error-code="not-found"> - <doc> - If the queue for this subscription does not exist, then the subscribing session MUST be - closed. - </doc> - </exception> - - <rule name="initial-credit"> - <doc> - Immediately after a subscription is created, the initial byte and message credit for that - destination is zero. - </doc> - </rule> - - <implement role="server" handle="MUST"/> - -<!-- XXX rolled into destination - <field name="queue" type="queue.name" required="true"> - <doc> - Specifies the name of the subscribed queue. - </doc> - </field> ---> - - <field name="name" type="str8" label="the route name"> - <doc> The client specified name for the subscription. This is used as the destination for - all messages transferred from this subscription. The destination is scoped to the session. - </doc> - - <exception name="unique-subscriber-destination" error-code="not-allowed"> - <doc> - The client MUST NOT specify a destination that refers to an existing subscription on the - same session. - </doc> - <doc type="scenario"> - Attempt to create two subscriptions on the same session with the same non-empty - destination. - </doc> - </exception> - </field> - - <field name="handle" type="uint64" label="route handle"/> - - <field name="accept-mode" type="message.accept-mode" required="true"> - <doc> - The accept-mode to use for messages transferred from this subscription. - </doc> - </field> - - <field name="acquire-mode" type="message.acquire-mode" required="true"> - <doc> - The acquire-mode to use for messages transferred from this subscription. - </doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request an exclusive subscription. This prevents other subscribers from subscribing to the - queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - The server MUST NOT grant an exclusive subscription to a queue that already has - subscribers. - </doc> - <doc type="scenario"> - Open two connections to a server, and in one connection create a shared (non-exclusive) - queue and then subscribe to the queue. In the second connection attempt to subscribe to - the same queue using the exclusive option. - </doc> - </exception> - </field> - - <field name="resume-id" type="message.message-id"> - <doc> - Requests that the sender resume the given message-id if it is still available. - </doc> - </field> - - <field name="resume-offset" type="uint64"> - <doc> - Indicates the amount of data already transferred. - </doc> - </field> - - <field name="flow-mode" type="flow-mode" label="set the flow control mode" required="true"> - <doc> - The new flow control mode. - </doc> - - <doc> - Sets the mode of flow control used for a given destination to either window or credit - based flow control. - - With credit based flow control, the sender of messages continually maintains its current - credit balance with the recipient. The credit balance consists of two values, a message - count, and a byte count. Whenever message data is sent, both counts must be decremented. - If either value reaches zero, the flow of message data must stop. Additional credit is - received via the message.flow command. - - The sender MUST NOT send partial commands. This means that if there is not enough byte - credit available to send a complete command, the sender must either wait or use message - fragmentation (multiple message.transfer commands) to send the first part of the message - data in a complete command. - - Window based flow control is identical to credit based flow control, however message - transfer completion implicitly grants a single unit of message credit, and the size of the - message in byte credits for each completed message transfer. Completion of the transfer - command with session.completed is the only way credit is implicitly updated; - message.accept, message.release, message.reject, tx.commit and tx.rollback have no effect - on the outstanding credit balances. - </doc> - - <rule name="byte-accounting"> - <doc> - The byte count is decremented by the payload size of each transmitted frame with segment - type header or body appearing within a message.transfer command. Note that the payload - size is the frame size less the frame header size. - </doc> - </rule> - - <rule name="mode-switching"> - <doc> - Mode switching may only occur if both the byte and message credit balance are zero. - There are three ways for a recipient of messages to be sure that the sender's credit - balances are zero: - - 1) The recipient may send a message.stop command to the sender. When the recipient - receives notification of completion for the message.stop command, it knows that the - sender's credit is zero. - - 2) The recipient may perform the same steps described in (1) with the message.fetch - command substituted for the message.stop command. - - 3) Immediately after a subscription is created with message.subscribe, the credit for - that destination is zero. - </doc> - </rule> - - <rule name="default-flow-mode"> - <doc> - Prior to receiving an explicit set-flow-mode command, a peer MUST consider the flow-mode - to be window. - </doc> - </rule> - </field> - - <field name="initial-message-credit" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - - <field name="initial-byte-credit" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for vendor extensions"> - <doc> - The syntax and semantics of these arguments depends on the providers implementation. - </doc> - </field> - </command> - - <!-- - Command: route.stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stop" code="0x8" label="stop the sending of messages"> - <doc> - On receipt of this command, a producer of messages MUST set his credit to zero for the - given destination. When notifying of completion, credit MUST be zero and no further - messages will be sent until such a time as further credit is received. - </doc> - - <rule name="post-cancel-transfer-resolution"> - <doc> - Canceling a subscription MUST NOT affect pending transfers. A transfer made prior to - canceling transfers to the destination MUST be able to be accepted, released, acquired, or - rejected after the subscription is canceled. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="handle" type="uint64" required="true"> - <exception name="subscription-not-found" error-code="not-found"> - <doc> - If the subscription specified by the destination is not found, the server MUST close the - session. - </doc> - </exception> - </field> - </command> - - <!-- - Command: route.flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="flow" code="0xa" label="control message flow"> - <doc> - This command controls the flow of message data to a given destination. It is used by the - recipient of messages to dynamically match the incoming rate of message flow to its - processing or forwarding capacity. Upon receipt of this command, the sender must add "value" - number of the specified messages and bytes to the available credit balances for the - specified destination. If a value is unset it indicates an infinite amount of credit. This - disables any limit for the given unit until the credit balance is zeroed with message.stop - or message.fetch. - </doc> - - <!-- throws no-such-destination --> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="uint64"/> - <field name="messages" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - <field name="bytes" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - </command> - - <!-- - Command: route.fetch - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="fetch" code="0xb" label="force the sending of available messages"> - <doc> - Forces the sender to exhaust his credit supply. The sender's credit will always be zero when - this command completes. The command completes when immediately available message data has - been transferred, or when the credit supply is exhausted. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="destination" type="uint64"/> - </command> - - </class> - - <!-- == Class: tx ============================================================================ --> - - <class name="tx" code="0x5" label="work with standard transactions"> - <doc> - Standard transactions provide so-called "1.5 phase commit". We can ensure that work is never - lost, but there is a chance of confirmations being lost, so that messages may be resent. - Applications that use standard transactions must be able to detect and ignore duplicate - messages. - </doc> - - <doc type="grammar"> - tx = C:SELECT - / C:COMMIT - / C:ROLLBACK - </doc> - - <!-- XXX: this isn't really a rule, as stated there is no way for - a client library to implement this --> - <rule name="duplicate-tracking"> - <doc> - An client using standard transactions SHOULD be able to track all messages received within a - reasonable period, and thus detect and reject duplicates of the same message. It SHOULD NOT - pass these to the application layer. - </doc> - </rule> - - <role name="server" implement="SHOULD" /> - - <!-- - Command: tx.select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="select" code="0x1" label="select standard transaction mode"> - <doc> - This command sets the session to use standard transactions. The client must use this command - exactly once on a session before using the Commit or Rollback commands. - </doc> - - <exception name="exactly-once" error-code="illegal-state"> - <doc> - A client MUST NOT select standard transactions on a session that is already transactional. - </doc> - </exception> - - <exception name="no-dtx" error-code="illegal-state"> - <doc> - A client MUST NOT select standard transactions on a session that is already enlisted in a - distributed transaction. - </doc> - </exception> - - <exception name="explicit-accepts" error-code="not-allowed"> - <doc> - On a session on which tx.select has been issued, a client MUST NOT issue a - message.subscribe command with the accept-mode property set to any value other than - explicit. Similarly a tx.select MUST NOT be issued on a session on which a there is a non - cancelled subscriber with accept-mode of none. - </doc> - </exception> - - <implement role="server" handle="MUST" /> - </command> - - <!-- - Command: tx.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="commit" code="0x2" label="commit the current transaction"> - <doc> - This command commits all messages published and accepted in the current transaction. A - new transaction starts immediately after a commit. - </doc> - <doc> - In more detail, the commit acts on all messages which have been transferred from the Client - to the Server, and on all acceptances of messages sent from Server to Client. Since the - commit acts on commands sent in the same direction as the commit command itself, there is no - ambiguity on the scope of the commands being committed. Further, the commit will not be - completed until all preceding commands which it affects have been completed. - </doc> - <doc> - Since transactions act on explicit accept commands, the only valid accept-mode for message - subscribers is explicit. For transferring messages from Client to Server (publishing) all - accept-modes are permitted. - </doc> - - <exception name="select-required" error-code="illegal-state"> - <doc> - A client MUST NOT issue tx.commit on a session that has not been selected for standard - transactions with tx.select. - </doc> - </exception> - - - - <implement role="server" handle="MUST" /> - </command> - - <!-- - Command: tx.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="rollback" code="0x3" label="abandon the current transaction"> - <doc> - This command abandons the current transaction. In particular the transfers from Client to - Server (publishes) and accepts of transfers from Server to Client which occurred in the - current transaction are discarded. A new transaction starts immediately after a rollback. - </doc> - <doc> - In more detail, when a rollback is issued, any the effects of transfers which occurred from - Client to Server are discarded. The Server will issue completion notification for all such - transfers prior to the completion of the rollback. Similarly the effects of any - message.accept issued from Client to Server prior to the issuance of the tx.rollback will be - discarded; and notification of completion for all such commands will be issued before the - issuance of the completion for the rollback. - </doc> - <doc> - After the completion of the rollback, the client will still hold the messages which it has - not yet accepted (including those for which accepts were previously issued within the - transaction); i.e. the messages remain "acquired". If the Client wishes to release those - messages back to the Server, then appropriate message.release commands must be issued. - </doc> - - <exception name="select-required" error-code="illegal-state"> - <doc> - A client MUST NOT issue tx.rollback on a session that has not been selected for standard - transactions with tx.select. - </doc> - </exception> - - <implement role="server" handle="MUST" /> - </command> - - </class> - - <!-- == Class: dtx =========================================================================== --> - - <class name="dtx" code="0x6" label="Demarcates dtx branches"> - <doc> - This provides the X-Open XA distributed transaction protocol support. It allows a session - to be selected for use with distributed transactions, the transactional boundaries for work on - that session to be demarcated and allows the transaction manager to coordinate transaction - outcomes. - </doc> - - <doc type="grammar"> - dtx-demarcation = C:SELECT *demarcation - demarcation = C:START C:END - </doc> - - <doc type="grammar"> - dtx-coordination = *coordination - coordination = command - / outcome - / recovery - command = C:SET-TIMEOUT - / C:GET-TIMEOUT - outcome = one-phase-commit - / one-phase-rollback - / two-phase-commit - / two-phase-rollback - one-phase-commit = C:COMMIT - one-phase-rollback = C:ROLLBACK - two-phase-commit = C:PREPARE C:COMMIT - two-phase-rollback = C:PREPARE C:ROLLBACK - recovery = C:RECOVER *recovery-outcome - recovery-outcome = one-phase-commit - / one-phase-rollback - / C:FORGET - - </doc> - - <rule name="transactionality"> - <doc> - Enabling XA transaction support on a session requires that the server MUST manage - transactions demarcated by start-end blocks. That is to say that on this XA-enabled session, - work undergone within transactional blocks is performed on behalf a transaction branch - whereas work performed outside of transactional blocks is NOT transactional. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- XA domains --> - - <domain name="xa-status" type="uint16" label="XA return codes"> - <enum> - <choice name="xa-ok" value="0"> - <doc> - Normal execution completion (no error). - </doc> - </choice> - - <choice name="xa-rbrollback" value="1"> - <doc> - The rollback was caused for an unspecified reason. - </doc> - </choice> - - <choice name="xa-rbtimeout" value="2"> - <doc> - A transaction branch took too long. - </doc> - </choice> - - <choice name="xa-heurhaz" value="3"> - <doc> - The transaction branch may have been heuristically completed. - </doc> - </choice> - - <choice name="xa-heurcom" value="4"> - <doc> - The transaction branch has been heuristically committed. - </doc> - </choice> - - <choice name="xa-heurrb" value="5"> - <doc> - The transaction branch has been heuristically rolled back. - </doc> - </choice> - - <choice name="xa-heurmix" value="6"> - <doc> - The transaction branch has been heuristically committed and rolled back. - </doc> - </choice> - - <choice name="xa-rdonly" value="7"> - <doc> - The transaction branch was read-only and has been committed. - </doc> - </choice> - </enum> - </domain> - - <struct name="xa-result" size="4" code="0x1" pack="2"> - <field name="status" type="xa-status" required="true"/> - </struct> - - <!-- Struct for xid --> - - <struct name="xid" size="2" pack="2" label="dtx branch identifier"> - <doc> - An xid uniquely identifies a transaction branch. - </doc> - - <field name="format" type="uint32" label="implementation specific format code" - required="true"/> - <field name="global-id" type="vbin8" label="global transaction id" required="true"/> - <field name="branch-id" type="vbin8" label="branch qualifier" required="true"/> - </struct> - - <!-- - Command: dtx.select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="select" code="0x1" label="Select dtx mode"> - <doc> - This command sets the session to use distributed transactions. The client must use this - command at least once on a session before using XA demarcation operations. - </doc> - - <implement role="server" handle="MAY" /> - </command> - - <!-- - Command: dtx.start - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="start" code="0x2" label="Start a dtx branch"> - <doc> - This command is called when messages should be produced and consumed on behalf a transaction - branch identified by xid. - </doc> - - <exception name="illegal-state" error-code="illegal-state"> - <doc> - If the command is invoked in an improper context (see class grammar) then the server MUST - send a session exception. - </doc> - </exception> - - <exception name="already-known" error-code="not-allowed"> - <doc> - If neither join nor resume is specified is specified and the transaction branch specified - by xid has previously been seen then the server MUST raise an exception. - </doc> - </exception> - - <exception name="join-and-resume" error-code="not-allowed"> - <doc> - If join and resume are specified then the server MUST raise an exception. - </doc> - </exception> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch to be started. - </doc> - - <exception name="unknown-xid" error-code="not-allowed"> - <doc> - If xid is already known by the broker then the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="join" type="bit" label="Join with existing xid flag"> - <doc> - Indicate whether this is joining an already associated xid. Indicate that the start - applies to joining a transaction previously seen. - </doc> - - <exception name="unsupported" error-code="not-implemented"> - <doc> - If the broker does not support join the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="resume" type="bit" label="Resume flag"> - <doc> - Indicate that the start applies to resuming a suspended transaction branch specified. - </doc> - </field> - - <result type="xa-result"> - <doc> - This confirms to the client that the transaction branch is started or specify the error - condition. - - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - </result> - </command> - - <!-- - Command: dtx.end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="end" code="0x3" label="End a dtx branch"> - <doc> - This command is called when the work done on behalf a transaction branch finishes or needs - to be suspended. - </doc> - - <exception name="illegal-state" error-code="illegal-state"> - <doc> - If the command is invoked in an improper context (see class grammar) then the server MUST - raise an exception. - </doc> - </exception> - - <exception name="suspend-and-fail" error-code="not-allowed"> - <doc> - If suspend and fail are specified then the server MUST raise an exception. - </doc> - </exception> - - <rule name="success"> - <doc> - If neither fail nor suspend are specified then the portion of work has completed - successfully. - </doc> - </rule> - - <rule name="session-closed"> - <doc> - When a session is closed then the currently associated transaction branches MUST be marked - rollback-only. - </doc> - </rule> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch to be ended. - </doc> - - <exception name="not-associated" error-code="illegal-state"> - <doc> - The session MUST be currently associated with the given xid (through an earlier start - call with the same xid). - </doc> - </exception> - </field> - - <field name="fail" type="bit" label="Failure flag"> - <doc> - If set, indicates that this portion of work has failed; otherwise this portion of work has - completed successfully. - </doc> - - <rule name="failure"> - <doc> - An implementation MAY elect to roll a transaction back if this failure notification is - received. Should an implementation elect to implement this behavior, and this bit is - set, then then the transaction branch SHOULD be marked as rollback-only and the end - result SHOULD have the xa-rbrollback status set. - </doc> - </rule> - </field> - - <field name="suspend" type="bit" label="Temporary suspension flag"> - <doc> - Indicates that the transaction branch is temporarily suspended in an incomplete state. - </doc> - - <rule name="resume"> - <doc> - The transaction context is in a suspended state and must be resumed via the start - command with resume specified. - </doc> - </rule> - - </field> - - <result type="xa-result"> - <doc> - This command confirms to the client that the transaction branch is ended or specify the - error condition. - - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. If an implementation chooses to implement rollback-on-failure behavior, then - this value should be selected if the dtx.end.fail bit was set. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - </result> - </command> - - <!-- - Command: dtx.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="commit" code="0x4" label="Commit work on dtx branch"> - <doc> - Commit the work done on behalf a transaction branch. This command commits the work - associated with xid. Any produced messages are made available and any consumed messages are - discarded. - </doc> - - <exception name="illegal-state" error-code="illegal-state"> - <doc> - If the command is invoked in an improper context (see class grammar) then the server MUST - raise an exception. - </doc> - </exception> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch to be committed. - </doc> - - <exception name="unknown-xid" error-code="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-disassociated" error-code="illegal-state"> - <doc> - If this command is called when xid is still associated with a session then the server - MUST raise an exception. - </doc> - </exception> - </field> - - <field name="one-phase" type="bit" label="One-phase optimization flag"> - <doc> - Used to indicate whether one-phase or two-phase commit is used. - </doc> - - <exception name="one-phase" error-code="illegal-state"> - <doc> - The one-phase bit MUST be set if a commit is sent without a preceding prepare. - </doc> - </exception> - - <exception name="two-phase" error-code="illegal-state"> - <doc> - The one-phase bit MUST NOT be set if the commit has been preceded by prepare. - </doc> - </exception> - </field> - - <result type="xa-result"> - <doc> - This confirms to the client that the transaction branch is committed or specify the - error condition. - - The value of this field may be one of the following constants: - - xa-ok: Normal execution - - xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction - branch may have been heuristically completed. - - xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was committed. - - xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was rolled back. - - xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was partially committed and partially rolled back. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - </result> - </command> - - <!-- - Command: dtx.forget - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="forget" code="0x5" label="Discard dtx branch"> - <doc> - This command is called to forget about a heuristically completed transaction branch. - </doc> - - <exception name="illegal-state" error-code="illegal-state"> - <doc> - If the command is invoked in an improper context (see class grammar) then the server MUST - raise an exception. - </doc> - </exception> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch to be forgotten. - </doc> - - <exception name="unknown-xid" error-code="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-disassociated" error-code="illegal-state"> - <doc> - If this command is called when xid is still associated with a session then the server - MUST raise an exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: dtx.get-timeout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="get-timeout" code="0x6" label="Obtain dtx timeout in seconds"> - <doc> - This command obtains the current transaction timeout value in seconds. If set-timeout was - not used prior to invoking this command, the return value is the default timeout; otherwise, - the value used in the previous set-timeout call is returned. - </doc> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch for getting the timeout. - </doc> - - <exception name="unknown-xid" error-code="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise an exception. - </doc> - </exception> - </field> - - <result> - <struct name="get-timeout-result" size="4" code="0x2" pack="2"> - <doc> Returns the value of the timeout last specified through set-timeout. </doc> - - <field name="timeout" type="uint32" label="The current transaction timeout value" - required="true"> - <doc> The current transaction timeout value in seconds. </doc> - </field> - </struct> - </result> - </command> - - <!-- - Command: dtx.prepare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="prepare" code="0x7" label="Prepare a dtx branch"> - <doc> - This command prepares for commitment any message produced or consumed on behalf of xid. - </doc> - - <exception name="illegal-state" error-code="illegal-state"> - <doc> - If the command is invoked in an improper context (see class grammar) then the server MUST - raise an exception. - </doc> - </exception> - - <rule name="obligation-1"> - <doc> - Once this command successfully returns it is guaranteed that the transaction branch may be - either committed or rolled back regardless of failures. - </doc> - </rule> - - <rule name="obligation-2"> - <doc> - The knowledge of xid cannot be erased before commit or rollback complete the branch. - </doc> - </rule> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch that can be prepared. - </doc> - - <exception name="unknown-xid" error-code="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-disassociated" error-code="illegal-state"> - <doc> - If this command is called when xid is still associated with a session then the server - MUST raise an exception. - </doc> - </exception> - </field> - - <result type="xa-result"> - <doc> - This command confirms to the client that the transaction branch is prepared or specify the - error condition. - - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rdonly: The transaction branch was read-only and has been committed. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - </result> - </command> - - <!-- - Command: dtx.recover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="recover" code="0x8" label="Get prepared or completed xids"> - <doc> - This command is called to obtain a list of transaction branches that are in a prepared or - heuristically completed state. - </doc> - - <implement role="server" handle="MAY" /> - - <result> - <struct name="recover-result" size="4" code="0x3" pack="2"> - <doc> - Returns to the client a table with single item that is a sequence of transaction xids - that are in a prepared or heuristically completed state. - </doc> - - <field name="in-doubt" type="array" label="array of xids to be recovered" required="true"> - <doc> Array containing the xids to be recovered (xids that are in a prepared or - heuristically completed state). </doc> - - </field> - </struct> - </result> - </command> - - <!-- - Command: dtx.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="rollback" code="0x9" label="Rollback a dtx branch"> - <doc> - This command rolls back the work associated with xid. Any produced messages are discarded - and any consumed messages are re-enqueued. - </doc> - - <exception name="illegal-state" error-code="illegal-state"> - <doc> - If the command is invoked in an improper context (see class grammar) then the server MUST - raise an exception. - </doc> - </exception> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch that can be rolled back. - </doc> - - <exception name="unknown-xid" error-code="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-disassociated" error-code="illegal-state"> - <doc> - If this command is called when xid is still associated with a session then the server - MUST raise an exception. - </doc> - </exception> - </field> - - <result type="xa-result"> - <doc> - This command confirms to the client that the transaction branch is rolled back or specify - the error condition. - - The value of this field may be one of the following constants: - - xa-ok: Normal execution - - xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction - branch may have been heuristically completed. - - xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was committed. - - xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was rolled back. - - xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was partially committed and partially rolled back. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - </result> - </command> - - <!-- - Command: dtx.set-timeout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="set-timeout" code="0xa" label="Set dtx timeout value"> - <doc> - Sets the specified transaction branch timeout value in seconds. - </doc> - - <rule name="effective"> - <doc> - Once set, this timeout value is effective until this command is reinvoked with a different - value. - </doc> - </rule> - - <rule name="reset"> - <doc> - A value of zero resets the timeout value to the default value. - </doc> - </rule> - - <implement role="server" handle="MAY" /> - - <field name="xid" type="xid" label="Transaction xid" required="true"> - <doc> - Specifies the xid of the transaction branch for setting the timeout. - </doc> - - <exception name="unknown-xid" error-code="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise an exception. - </doc> - </exception> - - </field> - - <field name="timeout" type="uint32" label="Dtx timeout in seconds" required="true"> - <doc> - The transaction timeout value in seconds. - </doc> - </field> - </command> - - </class> - - <!-- == Class: exchange ====================================================================== --> - - <class name="exchange" code="0x7" label="work with exchanges"> - <doc> - Exchanges match and distribute messages across queues. Exchanges can be configured in the - server or created at runtime. - </doc> - - <doc type="grammar"> - exchange = C:DECLARE - / C:DELETE - / C:QUERY - </doc> - - <rule name="required-types"> - <doc> - The server MUST implement these standard exchange types: fanout, direct. - </doc> - <doc type="scenario"> - Client attempts to declare an exchange with each of these standard types. - </doc> - </rule> - - <rule name="recommended-types"> - <doc> - The server SHOULD implement these standard exchange types: topic, headers. - </doc> - <doc type="scenario"> - Client attempts to declare an exchange with each of these standard types. - </doc> - </rule> - - <rule name="required-instances"> - <doc> - The server MUST, in each virtual host, pre-declare an exchange instance for each standard - exchange type that it implements, where the name of the exchange instance, if defined, is - "amq." followed by the exchange type name. - - The server MUST, in each virtual host, pre-declare at least two direct exchange instances: - one named "amq.direct", the other with no public name that serves as a default exchange for - publish commands (such as message.transfer). - </doc> - <doc type="scenario"> - Client creates a temporary queue and attempts to bind to each required exchange instance - ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" if those types are defined). - </doc> - </rule> - - <rule name="default-exchange"> - <doc> - The server MUST pre-declare a direct exchange with no public name to act as the default - exchange for content publish commands (such as message.transfer) and for default queue - bindings. - </doc> - <doc type="scenario"> - Client checks that the default exchange is active by publishing a message with a suitable - routing key but without specifying the exchange name, then ensuring that the message arrives - in the queue correctly. - </doc> - </rule> - - <rule name="default-access"> - <doc> - The default exchange MUST NOT be accessible to the client except by specifying an empty - exchange name in a content publish command (such as message.transfer). That is, the server - must not let clients explicitly bind, unbind, delete, or make any other reference to this - exchange. - </doc> - </rule> - - <rule name="extensions"> - <doc> - The server MAY implement other exchange types as wanted. - </doc> - </rule> - - <role name="server" implement="MUST" /> - <role name="client" implement="MUST" /> - - <domain name="name" type="str8" label="exchange name"> - <doc> - The exchange name is a client-selected string that identifies the exchange for publish - commands. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - </doc> - </domain> - - <!-- - Command: exchange.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="declare" code="0x1" label="verify exchange exists, create if needed"> - <doc> - This command creates an exchange if it does not already exist, and if the exchange exists, - verifies that it is of the correct and expected class. - </doc> - - <rule name="minimum"> - <doc> - The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose - no limit except as defined by available resources. - </doc> - <doc type="scenario"> - The client creates as many exchanges as it can until the server reports an error; the - number of exchanges successfully created must be at least sixteen. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="name" required="true"> - <exception name="reserved-names" error-code="not-allowed"> - <doc> - Exchange names starting with "amq." are reserved for pre-declared and standardized - exchanges. The client MUST NOT attempt to create an exchange starting with "amq.". - </doc> - </exception> - - <exception name="exchange-name-required" error-code="invalid-argument"> - <doc> - The name of the exchange MUST NOT be a blank or empty string. - </doc> - </exception> - </field> - - <field name="type" type="str8" label="exchange type" required="true"> - <doc> - Each exchange belongs to one of a set of exchange types implemented by the server. The - exchange types define the functionality of the exchange - i.e. how messages are routed - through it. It is not valid or meaningful to attempt to change the type of an existing - exchange. - </doc> - - <exception name="typed" error-code="not-allowed"> - <doc> - Exchanges cannot be redeclared with different types. The client MUST NOT attempt to - redeclare an existing exchange with a different type than used in the original - exchange.declare command. - </doc> - </exception> - - <exception name="exchange-type-not-found" error-code="not-found"> - <doc> - If the client attempts to create an exchange which the server does not recognize, an - exception MUST be sent. - </doc> - </exception> - </field> - - <field name="alternate-exchange" type="name" label= "exchange name for unroutable messages"> - <doc> - In the event that a message cannot be routed, this is the name of the exchange to which - the message will be sent. Messages transferred using message.transfer will be routed to - the alternate-exchange only if they are sent with the "none" accept-mode, and the - discard-unroutable delivery property is set to false, and there is no queue to route to - for the given message according to the bindings on this exchange. - </doc> - - <rule name="empty-name"> - <doc> - If alternate-exchange is not set (its name is an empty string), unroutable messages - that would be sent to the alternate-exchange MUST be dropped silently. - </doc> - </rule> - - <exception name="pre-existing-exchange" error-code="not-allowed"> - <doc> - If the alternate-exchange is not empty and if the exchange already exists with a - different alternate-exchange, then the declaration MUST result in an exception. - </doc> - </exception> - - <rule name="double-failure"> - <doc> - A message which is being routed to a alternate exchange, MUST NOT be re-routed to a - secondary alternate exchange if it fails to route in the primary alternate exchange. - After such a failure, the message MUST be dropped. This prevents looping. - </doc> - </rule> - </field> - - <field name="passive" type="bit" label="do not create exchange"> - <doc> - If set, the server will not create the exchange. The client can use this to check whether - an exchange exists without modifying the server state. - </doc> - <exception name="not-found" error-code="not-found"> - <doc> - If set, and the exchange does not already exist, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="durable" type="bit" label="request a durable exchange"> - <doc> - If set when creating a new exchange, the exchange will be marked as durable. Durable - exchanges remain active when a server restarts. Non-durable exchanges (transient - exchanges) are purged if/when a server restarts. - </doc> - - <rule name="support"> - <doc> - The server MUST support both durable and transient exchanges. - </doc> - </rule> - - <rule name="sticky"> - <doc> - The server MUST ignore the durable field if the exchange already exists. - </doc> - </rule> - </field> - - <field name="auto-delete" type="bit" label="auto-delete when unused"> - <doc> - If set, the exchange is deleted automatically when there remain no bindings between the - exchange and any queue. Such an exchange will not be automatically deleted until at least - one binding has been made to prevent the immediate deletion of the exchange upon creation. - </doc> - <rule name="sticky"> - <doc> - The server MUST ignore the auto-delete field if the exchange already exists. - </doc> - </rule> - </field> - - <field name="arguments" type="map" label="arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these arguments - depends on the server implementation. This field is ignored if passive is 1. - </doc> - - <exception name="unknown-argument" error-code="not-implemented"> - <doc> - If the arguments field contains arguments which are not understood by the server, - it MUST raise an exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: exchange.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="delete" code="0x2" label="delete an exchange"> - <doc> - This command deletes an exchange. When an exchange is deleted all queue bindings on the - exchange are cancelled. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="name" required="true"> - <exception name="exists" error-code="not-found"> - <doc> - The client MUST NOT attempt to delete an exchange that does not exist. - </doc> - </exception> - - <exception name="exchange-name-required" error-code="invalid-argument"> - <doc> - The name of the exchange MUST NOT be a missing or empty string. - </doc> - </exception> - - <exception name="used-as-alternate" error-code="not-allowed"> - <doc> - An exchange MUST NOT be deleted if it is in use as an alternate-exchange by a queue or - by another exchange. - </doc> - </exception> - - </field> - - <field name="if-unused" type="bit" label="delete only if unused"> - <doc> - If set, the server will only delete the exchange if it has no queue bindings. If the - exchange has queue bindings the server does not delete it but raises an exception - instead. - </doc> - <exception name="exchange-in-use" error-code="precondition-failed"> - <doc> - If the exchange has queue bindings, and the if-unused flag is set, the server MUST NOT - delete the exchange, but MUST raise and exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: exchange.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="query" code="0x3" label="request information about an exchange"> - <doc> - This command is used to request information on a particular exchange. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="name" type="str8" label="the exchange name"> - <doc> - The name of the exchange for which information is requested. If not specified explicitly - the default exchange is implied. - </doc> - </field> - - <result> - <struct name="exchange-query-result" size="4" code="0x1" pack="2"> - <doc> - This is sent in response to a query request and conveys information on a particular - exchange. - </doc> - - <field name="type" type="str8" label="indicate the exchange type"> - <doc> - The type of the exchange. Will be empty if the exchange is not found. - </doc> - </field> - - <field name="durable" type="bit" label="indicate the durability"> - <doc> - The durability of the exchange, i.e. if set the exchange is durable. Will not be set - if the exchange is not found. - </doc> - </field> - - <field name="not-found" type="bit" label="indicate an unknown exchange"> - <doc> - If set, the exchange for which information was requested is not known. - </doc> - </field> - - <field name="arguments" type="map" label="other unspecified exchange properties"> - <doc> - A set of properties of the exchange whose syntax and semantics depends on the server - implementation. Will be empty if the exchange is not found. - </doc> - </field> - </struct> - </result> - </command> - - <!-- - Command: exchange.bind - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="bind" code="0x4" label="bind queue to an exchange"> - <doc> This command binds a queue to an exchange. Until a queue is bound it will not receive - any messages. In a classic messaging model, store-and-forward queues are bound to a direct - exchange and subscription queues are bound to a topic exchange. </doc> - - <rule name="duplicates"> - <doc> - A server MUST ignore duplicate bindings - that is, two or more bind commands with the - same exchange, queue, and binding-key - without treating these as an error. The value of - the arguments used for the binding MUST NOT be altered by subsequent binding requests. - </doc> - <doc type="scenario"> - A client binds a named queue to an exchange. The client then repeats the bind (with - identical exchange, queue, and binding-key). The second binding should use a different - value for the arguments field. - </doc> - </rule> - - <rule name="durable-exchange"> - <doc> Bindings between durable queues and durable exchanges are automatically durable and - the server MUST restore such bindings after a server restart. </doc> - <doc type="scenario"> A server creates a named durable queue and binds it to a durable - exchange. The server is restarted. The client then attempts to use the queue/exchange - combination. </doc> - </rule> - - <rule name="binding-count"> - <doc> The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit - except as defined by available resources. </doc> - <doc type="scenario"> A client creates a named queue and attempts to bind it to 4 different - exchanges. </doc> - </rule> - - <rule name="multiple-bindings"> - <doc> Where more than one binding exists between a particular exchange instance and a - particular queue instance any given message published to that exchange should be delivered - to that queue at most once, regardless of how many distinct bindings match. </doc> - <doc type="scenario"> A client creates a named queue and binds it to the same topic exchange - at least three times using intersecting binding-keys (for example, "animals.*", - "animals.dogs.*", "animal.dogs.chihuahua"). Verify that a message matching all the - bindings (using previous example, routing key = "animal.dogs.chihuahua") is delivered once - only. </doc> - </rule> - - <implement role="server" handle="MUST"/> - - <field name="queue" type="queue.name" required="true"> - <doc> Specifies the name of the queue to bind. </doc> - - <exception name="empty-queue" error-code="invalid-argument"> - <doc> A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. empty - queue name) to an exchange. </doc> - <doc type="scenario"> A client attempts to bind with an unnamed (empty) queue name to an - exchange. </doc> - </exception> - - <exception name="queue-existence" error-code="not-found"> - <doc> A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously - declared) to an exchange. </doc> - <doc type="scenario"> A client attempts to bind an undeclared queue name to an exchange. - </doc> - </exception> - </field> - - <field name="exchange" type="name" label="name of the exchange to bind to" required="true"> - <exception name="exchange-existence" error-code="not-found"> - <doc> A client MUST NOT be allowed to bind a queue to a non-existent exchange. </doc> - <doc type="scenario"> A client attempts to bind a named queue to a undeclared exchange. - </doc> - </exception> - - <exception name="exchange-name-required" error-code="invalid-argument"> - <doc> The name of the exchange MUST NOT be a blank or empty string. </doc> - </exception> - </field> - - <field name="binding-key" type="str8" - label="identifies a binding between a given exchange and queue" required="true"> - <doc> The binding-key uniquely identifies a binding between a given (exchange, queue) pair. - Depending on the exchange configuration, the binding key may be matched against the - message routing key in order to make routing decisions. The match algorithm depends on the - exchange type. Some exchange types may ignore the binding key when making routing - decisions. Refer to the specific exchange type documentation. The meaning of an empty - binding key depends on the exchange implementation. </doc> - </field> - - <field name="arguments" type="map" label="arguments for binding"> - <doc> A set of arguments for the binding. The syntax and semantics of these arguments - depends on the exchange class. </doc> - - <exception name="unknown-argument" error-code="not-implemented"> - <doc> If the arguments field contains arguments which are not understood by the server, it - MUST raise an exception. </doc> - </exception> - </field> - </command> - - <!-- - Command: exchange.unbind - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="unbind" code="0x5" label="unbind a queue from an exchange"> - <doc> - This command unbinds a queue from an exchange. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="queue" type="queue.name" required="true"> - <doc> - Specifies the name of the queue to unbind. - </doc> - <exception name="non-existent-queue" error-code="not-found"> - <doc> - If the queue does not exist the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="exchange" type="name" required="true"> - <doc> - The name of the exchange to unbind from. - </doc> - - <exception name="non-existent-exchange" error-code="not-found"> - <doc> - If the exchange does not exist the server MUST raise an exception. - </doc> - </exception> - - <exception name="exchange-name-required" error-code="invalid-argument"> - <doc> - The name of the exchange MUST NOT be a blank or empty string. - </doc> - </exception> - </field> - - <field name="binding-key" type="str8" label="the key of the binding" required="true"> - <doc> - Specifies the binding-key of the binding to unbind. - </doc> - - <exception name="non-existent-binding-key" error-code="not-found"> - <doc> - If there is no matching binding-key the server MUST raise an exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: exchange.bound - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="bound" code="0x6" label="request information about bindings to an exchange"> - <doc> - This command is used to request information on the bindings to a particular exchange. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="str8" label="the exchange name"> - <doc> - The name of the exchange for which binding information is being requested. If not - specified explicitly the default exchange is implied. - </doc> - </field> - - <field name="queue" type="str8" label="a queue name" required="true"> - <doc> - If populated then determine whether the given queue is bound to the exchange. - </doc> - </field> - - <field name="binding-key" type="str8" label="a binding-key"> - <doc> - If populated defines the binding-key of the binding of interest, if not populated the - request will ignore the binding-key on bindings when searching for a match. - </doc> - </field> - - <field name="arguments" type="map" label="a set of binding arguments"> - <doc> - If populated defines the arguments of the binding of interest if not populated the request - will ignore the arguments on bindings when searching for a match - </doc> - </field> - - <result> - <struct name="exchange-bound-result" size="4" code="0x2" pack="2"> - <field name="exchange-not-found" type="bit" label="indicate an unknown exchange"> - <doc> - If set, the exchange for which information was requested is not known. - </doc> - </field> - - <field name="queue-not-found" type="bit" label="indicate an unknown queue"> - <doc> - If set, the queue specified is not known. - </doc> - </field> - - <field name="queue-not-matched" type="bit" label="indicate no matching queue"> - <doc> - A bit which if set indicates that no binding was found from the specified exchange to - the specified queue. - </doc> - </field> - - <field name="key-not-matched" type="bit" label="indicate no matching binding-key"> - <doc> - A bit which if set indicates that no binding was found from the specified exchange - with the specified binding-key. - </doc> - </field> - - <field name="args-not-matched" type="bit" label="indicate no matching arguments"> - <doc> - A bit which if set indicates that no binding was found from the specified exchange - with the specified arguments. - </doc> - </field> - </struct> - </result> - </command> - - </class> - - <!-- == Class: queue ========================================================================= --> - - <class name="queue" code="0x8" label="work with queues"> - <doc> - Queues store and forward messages. Queues can be configured in the server or created at - runtime. Queues must be attached to at least one exchange in order to receive messages from - publishers. - </doc> - - <doc type="grammar"> - queue = C:DECLARE - / C:BIND - / C:PURGE - / C:DELETE - / C:QUERY - / C:UNBIND - </doc> - - <rule name="any-content"> - <doc> - A server MUST allow any content class to be sent to any queue, in any mix, and queue and - deliver these content classes independently. Note that all commands that fetch content off - queues are specific to a given content class. - </doc> - <doc type="scenario"> - Client creates an exchange of each standard type and several queues that it binds to each - exchange. It must then successfully send each of the standard content types to each of the - available queues. - </doc> - </rule> - - <role name="server" implement="MUST" /> - <role name="client" implement="MUST" /> - - <domain name="name" type="str8" label="queue name"> - <doc> - The queue name identifies the queue within the virtual host. Queue names must have a length - of between 1 and 255 characters inclusive, must start with a digit, letter or underscores - ('_') character, and must be otherwise encoded in UTF-8. - </doc> - </domain> - - <!-- - Command: queue.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="declare" code="0x1" label="declare queue"> - <doc> - This command creates or checks a queue. When creating a new queue the client can specify - various properties that control the durability of the queue and its contents, and the level - of sharing for the queue. - </doc> - - <rule name="default-binding"> - <doc> - The server MUST create a default binding for a newly-created queue to the default - exchange, which is an exchange of type 'direct' and use the queue name as the binding-key. - </doc> - <doc type="scenario"> - Client creates a new queue, and then without explicitly binding it to an exchange, - attempts to send a message through the default exchange binding, i.e. publish a message to - the empty exchange, with the queue name as binding-key. - </doc> - </rule> - - <rule name="minimum-queues"> - <doc> - The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no - limit except as defined by available resources. - </doc> - <doc type="scenario"> - Client attempts to create as many queues as it can until the server reports an error. The - resulting count must at least be 256. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="queue" type="name" required="true"> - <exception name="reserved-prefix" error-code="not-allowed"> - <doc> - Queue names starting with "amq." are reserved for pre-declared and standardized server - queues. A client MUST NOT attempt to declare a queue with a name that starts with "amq." - and the passive option set to zero. - </doc> - <doc type="scenario"> - A client attempts to create a queue with a name starting with "amq." and with the - passive option set to zero. - </doc> - </exception> - </field> - - <field name="alternate-exchange" type="exchange.name" - label= "exchange name for messages with exceptions"> - <doc> - The alternate-exchange field specifies how messages on this queue should be treated when - they are rejected by a subscriber, or when they are orphaned by queue deletion. When - present, rejected or orphaned messages MUST be routed to the alternate-exchange. In all - cases the messages MUST be removed from the queue. - </doc> - - <exception name="pre-existing-exchange" error-code="not-allowed"> - <doc> - If the alternate-exchange is not empty and if the queue already exists with a different - alternate-exchange, then the declaration MUST result in an exception. - </doc> - </exception> - - <exception name="unknown-exchange" error-code="not-found"> - <doc> - if the alternate-exchange does not match the name of any existing exchange on the - server, then an exception must be raised. - </doc> - </exception> - </field> - - <field name="passive" type="bit" label="do not create queue"> - <doc> - If set, the server will not create the queue. This field allows the client to assert the - presence of a queue without modifying the server state. - </doc> - - <exception name="passive" error-code="not-found"> - <doc> - The client MAY ask the server to assert that a queue exists without creating the queue - if not. If the queue does not exist, the server treats this as a failure. - </doc> - <doc type="scenario"> - Client declares an existing queue with the passive option and expects the command to - succeed. Client then attempts to declare a non-existent queue with the passive option, - and the server must close the session with the correct exception. - </doc> - </exception> - </field> - - <field name="durable" type="bit" label="request a durable queue"> - <doc> - If set when creating a new queue, the queue will be marked as durable. Durable queues - remain active when a server restarts. Non-durable queues (transient queues) are purged - if/when a server restarts. Note that durable queues do not necessarily hold persistent - messages, although it does not make sense to send persistent messages to a transient - queue. - </doc> - - <rule name="persistence"> - <doc> - The queue definition MUST survive the server losing all transient memory, e.g. a - machine restart. - </doc> - <doc type="scenario"> - Client creates a durable queue; server is then restarted. Client then attempts to send - message to the queue. The message should be successfully delivered. - </doc> - </rule> - - <rule name="types"> - <doc> - The server MUST support both durable and transient queues. - </doc> - <doc type="scenario"> - A client creates two named queues, one durable and one transient. - </doc> - </rule> - - <rule name="pre-existence"> - <doc> - The server MUST ignore the durable field if the queue already exists. - </doc> - <doc type="scenario"> - A client creates two named queues, one durable and one transient. The client then - attempts to declare the two queues using the same names again, but reversing the value - of the durable flag in each case. Verify that the queues still exist with the original - durable flag values. - </doc> - </rule> - </field> - - <field name="exclusive" type="bit" label="request an exclusive queue"> - <doc> - Exclusive queues can only be used from one session at a time. Once a session - declares an exclusive queue, that queue cannot be used by any other session until the - declaring session closes. - </doc> - - <rule name="types"> - <doc> - The server MUST support both exclusive (private) and non-exclusive (shared) queues. - </doc> - <doc type="scenario"> - A client creates two named queues, one exclusive and one non-exclusive. - </doc> - </rule> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server receives a declare, bind, consume or get request for a queue that has been - declared as exclusive by an existing client session, it MUST raise an exception. - </doc> - <doc type="scenario"> - A client declares an exclusive named queue. A second client on a different session - attempts to declare a queue of the same name. - </doc> - </exception> - </field> - - <field name="auto-delete" type="bit" label="auto-delete queue when unused"> - <doc> - If this field is set and the exclusive field is also set, then the queue MUST be deleted - when the session closes. - - If this field is set and the exclusive field is not set the queue is deleted when all - the consumers have finished using it. Last consumer can be cancelled either explicitly - or because its session is closed. If there was no consumer ever on the queue, it won't - be deleted. - </doc> - - <rule name="pre-existence"> - <doc> - The server MUST ignore the auto-delete field if the queue already exists. - </doc> - <doc type="scenario"> - A client creates two named queues, one as auto-delete and one explicit-delete. The - client then attempts to declare the two queues using the same names again, but reversing - the value of the auto-delete field in each case. Verify that the queues still exist with - the original auto-delete flag values. - </doc> - </rule> - </field> - - <field name="arguments" type="map" label="arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these arguments - depends on the server implementation. This field is ignored if passive is 1. - </doc> - - <exception name="unknown-argument" error-code="not-implemented"> - <doc> - If the arguments field contains arguments which are not understood by the server, - it MUST raise an exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: queue.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="delete" code="0x2" label="delete a queue"> - <doc> - This command deletes a queue. When a queue is deleted any pending messages are sent to the - alternate-exchange if defined, or discarded if it is not. - </doc> - - - <implement role="server" handle="MUST" /> - - <field name="queue" type="name" required="true"> - <doc> - Specifies the name of the queue to delete. - </doc> - - <exception name="empty-name" error-code="invalid-argument"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - - <exception name="queue-exists" error-code="not-found"> - <doc> - The queue must exist. If the client attempts to delete a non-existing queue the server - MUST raise an exception. - </doc> - </exception> - </field> - - <field name="if-unused" type="bit" label="delete only if unused"> - <doc> - If set, the server will only delete the queue if it has no consumers. If the queue has - consumers the server does does not delete it but raises an exception instead. - </doc> - - <exception name="if-unused-flag" error-code="precondition-failed"> - <doc> - The server MUST respect the if-unused flag when deleting a queue. - </doc> - </exception> - </field> - - <field name="if-empty" type="bit" label="delete only if empty"> - <doc> - If set, the server will only delete the queue if it has no messages. - </doc> - <exception name="not-empty" error-code="precondition-failed"> - <doc> - If the queue is not empty the server MUST raise an exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: queue.purge - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="purge" code="0x3" label="purge a queue"> - <doc> - This command removes all messages from a queue. It does not cancel subscribers. Purged - messages are deleted without any formal "undo" mechanism. - </doc> - - <rule name="empty"> - <doc> - A call to purge MUST result in an empty queue. - </doc> - </rule> - - <rule name="pending-messages"> - <doc> - The server MUST NOT purge messages that have already been sent to a client but not yet - accepted. - </doc> - </rule> - - <rule name="purge-recovery"> - <doc> - The server MAY implement a purge queue or log that allows system administrators to recover - accidentally-purged messages. The server SHOULD NOT keep purged messages in the same - storage spaces as the live messages since the volumes of purged messages may get very - large. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="queue" type="name" required="true"> - <doc> - Specifies the name of the queue to purge. - </doc> - - <exception name="empty-name" error-code="invalid-argument"> - <doc> - If the the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - - <exception name="queue-exists" error-code="not-found"> - <doc> - The queue MUST exist. Attempting to purge a non-existing queue MUST cause an exception. - </doc> - </exception> - </field> - </command> - - <!-- - Command: queue.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="query" code="0x4" label="request information about a queue"> - <doc> - This command requests information about a queue. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="queue" type="name" label="the queried queue" required="true"/> - - <result> - <struct name="queue-query-result" size="4" code="0x1" pack="2"> - <doc> - This is sent in response to queue.query, and conveys the requested information about a - queue. If no queue with the specified name exists then none of the fields within the - returned result struct will be populated. - </doc> - - <field name="queue" type="name" required="true"> - <doc> - Reports the name of the queue. - </doc> - </field> - - <field name="alternate-exchange" type="exchange.name" /> - - <field name="durable" type="bit" /> - - <field name="exclusive" type="bit" /> - - <field name="auto-delete" type="bit" /> - - <field name="arguments" type="map" /> - - <field name="message-count" type="uint32" label="number of messages in queue" - required="true"> - <doc> Reports the number of messages in the queue. </doc> - </field> - - <field name="subscriber-count" type="uint32" label="number of subscribers" - required="true"> - <doc> - Reports the number of subscribers for the queue. - </doc> - </field> - </struct> - </result> - </command> - - </class> - -</amqp> |