You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by gs...@apache.org on 2007/07/24 14:46:23 UTC
svn commit: r559029 [2/3] -
/incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml
Added: incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml
URL: http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml?view=auto&rev=559029
==============================================================================
--- incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml (added)
+++ incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml Tue Jul 24 05:46:22 2007
@@ -0,0 +1,7265 @@
+<?xml version="1.0"?>
+
+<!--
+ EDITORS: (PH) Pieter Hintjens <ph...@imatix.com>
+ (KvdR) Kim van der Riet <ki...@redhat.com>
+
+ These editors have been assigned by the AMQP working group. Please do not edit/commit this file
+ without consulting with one of the above editors.
+ ========================================================
+
+ TODOs
+ - see TODO comments in the text
+-->
+
+<!--
+ Copyright Notice
+ ================
+ (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix
+ Corporation, IONA\ufffd Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc.
+ 2006. All rights reserved.
+
+ License
+ =======
+ JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA
+ Technologies, Red Hat, Inc., TWIST Process Innovations, 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.
+
+-->
+
+<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
+ major="0" minor="10" port="5672" comment="AMQ Protocol (Working version)">
+
+ <!-- Need these for the transition from 0-9 to 0-10, while still on 0-9 framing: -->
+ <constant name = "frame-request" value = "9" />
+ <constant name = "frame-response" value = "10" />
+
+
+ <!--
+ ======================================================
+ == CONSTANTS
+ ======================================================
+ -->
+ <!-- Frame types -->
+ <constant name="frame-method" value="1" />
+ <constant name="frame-header" value="2" />
+ <constant name="frame-body" value="3" />
+ <constant name="frame-oob-method" value="4" />
+ <constant name="frame-oob-header" value="5" />
+ <constant name="frame-oob-body" value="6" />
+ <constant name="frame-trace" value="7" />
+ <constant name="frame-heartbeat" value="8" />
+
+ <!-- Protocol constants -->
+ <constant name="frame-min-size" value="4096" />
+ <constant name="frame-end" value="206" />
+
+ <!-- Reply codes -->
+ <constant name="reply-success" value="200">
+ <doc>
+ Indicates that the method completed successfully. This reply code is reserved for future use -
+ the current protocol design does not use positive confirmation and reply codes are sent only
+ in case of an error.
+ </doc>
+ </constant>
+
+ <constant name="not-delivered" value="310" class="soft-error">
+ <doc>
+ The client asked for a specific message that is no longer available. The message was delivered
+ to another client, or was purged from the queue for some other reason.
+ </doc>
+ </constant>
+
+ <constant name="content-too-large" value="311" class="soft-error">
+ <doc>
+ The client attempted to transfer content larger than the server could accept at the present
+ time. The client may retry at a later time.
+ </doc>
+ </constant>
+
+ <constant name="no-route" value="312" class="soft-error">
+ <doc>
+ When the exchange cannot route the result of a .Publish, most likely due to an invalid routing
+ key. Only when the mandatory flag is set.
+ </doc>
+ </constant>
+
+ <constant name="no-consumers" value="313" class="soft-error">
+ <doc>
+ When the exchange cannot deliver to a consumer when the immediate flag is set. As a result of
+ pending data on the queue or the absence of any consumers of the queue.
+ </doc>
+ </constant>
+
+ <constant name="connection-forced" value="320" class="hard-error">
+ <doc>
+ An operator intervened to close the connection for some reason. The client may retry at some
+ later date.
+ </doc>
+ </constant>
+
+ <constant name="invalid-path" value="402" class="hard-error">
+ <doc>
+ The client tried to work with an unknown virtual host.
+ </doc>
+ </constant>
+
+ <constant name="access-refused" value="403" class="soft-error">
+ <doc>
+ The client attempted to work with a server entity to which it has no access due to security
+ settings.
+ </doc>
+ </constant>
+
+ <constant name="not-found" value="404" class="soft-error">
+ <doc>
+ The client attempted to work with a server entity that does not exist.
+ </doc>
+ </constant>
+
+ <constant name="resource-locked" value="405" class="soft-error">
+ <doc>
+ The client attempted to work with a server entity to which it has no access because another
+ client is working with it.
+ </doc>
+ </constant>
+
+ <constant name="precondition-failed" value="406" class="soft-error">
+ <doc>
+ The client requested a method that was not allowed because some precondition failed.
+ </doc>
+ </constant>
+
+ <constant name="frame-error" value="501" class="hard-error">
+ <doc>
+ The client sent a malformed frame that the server could not decode. This strongly implies a
+ programming error in the client.
+ </doc>
+ </constant>
+
+ <constant name="syntax-error" value="502" class="hard-error">
+ <doc>
+ The client sent a frame that contained illegal values for one or more fields. This strongly
+ implies a programming error in the client.
+ </doc>
+ </constant>
+
+ <constant name="command-invalid" value="503" class="hard-error">
+ <doc>
+ The client sent an invalid sequence of frames, attempting to perform an operation that was
+ considered invalid by the server. This usually implies a programming error in the client.
+ </doc>
+ </constant>
+
+ <!-- TODO: Should this be renamed to "session-error" since class channel has been replaced by
+ class session? -->
+ <constant name="channel-error" value="504" class="hard-error">
+ <doc>
+ The client attempted to work with a channel that had not been correctly opened. This most
+ likely indicates a fault in the client layer.
+ </doc>
+ </constant>
+
+ <constant name="resource-error" value="506" class="hard-error">
+ <doc>
+ The server could not complete the method because it lacked sufficient resources. This may be
+ due to the client creating too many of some type of entity.
+ </doc>
+ </constant>
+
+ <constant name="not-allowed" value="530" class="hard-error">
+ <doc>
+ The client tried to work with some entity in a manner that is prohibited by the server, due to
+ security settings or by some other criteria.
+ </doc>
+ </constant>
+
+ <constant name="not-implemented" value="540" class="hard-error">
+ <doc>
+ The client tried to use functionality that is not implemented in the server.
+ </doc>
+ </constant>
+
+ <constant name="internal-error" value="541" class="hard-error">
+ <doc>
+ The server could not complete the method because of an internal error. The server may require
+ intervention by an operator in order to resume normal operations.
+ </doc>
+ </constant>
+
+ <constant name="invalid-argument" value="542" class="hard-error">
+ <doc>
+ An invalid or illegal argument was passed to a method, and the operation could not proceed.
+ </doc>
+ </constant>
+
+ <!-- XA constants -->
+
+ <constant name="xa-ok" value="0">
+ <doc>
+ XA return code: Normal execution completion (no error).
+ </doc>
+ </constant>
+
+ <constant name="xa-rbrollback" value="1">
+ <doc>
+ XA return code: The rollback was caused for an unspecified reason.
+ </doc>
+ </constant>
+
+ <constant name="xa-rbtimeout" value="2">
+ <doc>
+ XA return code: A transaction branch took too long.
+ </doc>
+ </constant>
+
+ <constant name="xa-heurhaz" value="3">
+ <doc>
+ XA return code: The transaction branch may have been heuristically completed.
+ </doc>
+ </constant>
+
+ <constant name="xa-heurcom" value="4">
+ <doc>
+ XA return code: The transaction branch has been heuristically committed.
+ </doc>
+ </constant>
+
+ <constant name="xa-heurrb" value="5">
+ <doc>
+ XA return code: The transaction branch has been heuristically rolled back.
+ </doc>
+ </constant>
+
+ <constant name="xa-heurmix" value="6">
+ <doc>
+ XA return code: The transaction branch has been heuristically committed and rolled back.
+ </doc>
+ </constant>
+
+ <constant name="xa-rdonly" value="7">
+ <doc>
+ XA return code: The transaction branch was read-only and has been committed.
+ </doc>
+ </constant>
+
+ <!--
+ ================================
+ == Field Table type constants ==
+ ================================
+ -->
+
+ <!--
+ 0x00 - 0x0f: Fixed width, 1 octet
+ -->
+
+ <constant name="field-table-octet" value="0x00" width="1" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Octet of unspecified encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-signed-byte" value="0x01" width="1" datatype="signed-integer"
+ class="field-table-type">
+ <doc>
+ 8-bit signed integral value (-128 - 127)
+ </doc>
+ </constant>
+
+ <constant name="field-table-unsigned-byte" value="0x02" width="1" datatype="unsigned-integer"
+ class="field-table-type">
+ <doc>
+ 8-bit unsigned integral value (0 - 255)
+ </doc>
+ </constant>
+
+ <constant name="field-table-char" value="0x04" width="1" datatype="char"
+ class="field-table-type">
+ <doc>
+ 8-bit representation of single character in the iso-8859-15 character set
+ </doc>
+ </constant>
+
+ <constant name="field-table-boolean" value="0x08" width="1" datatype="boolean"
+ class="field-table-type">
+ <doc>
+ Boolean value (0 represents false, 1 represents true)
+ </doc>
+ </constant>
+
+ <!--
+ 0x10 - 0x1f: Fixed width, 2 octets
+ -->
+
+ <constant name="field-table-two-octets" value="0x10" width="2" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Two octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-signed-short" value="0x11" width="2" datatype="signed-integer"
+ class="field-table-type">
+ <doc>
+ 16-bit signed integral value
+ </doc>
+ </constant>
+
+ <constant name="field-table-unsigned-short" value="0x12" width="2" datatype="unsigned-integer"
+ class="field-table-type">
+ <doc>
+ 16-bit unsigned integral value
+ </doc>
+ </constant>
+
+ <!--
+ 0x20 - 0x2f: Fixed width, 4 octets
+ -->
+
+ <constant name="field-table-four-octets" value="0x20" width="4" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Four octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-signed-int" value="0x21" width="4" datatype="signed-integer"
+ class="field-table-type">
+ <doc>
+ 32-bit signed integral value
+ </doc>
+ </constant>
+
+ <constant name="field-table-unsigned-int" value="0x22" width="4" datatype="unsigned-integer"
+ class="field-table-type">
+ <doc>
+ 32-bit unsigned integral value
+ </doc>
+ </constant>
+
+ <constant name="field-table-float" value="0x23" width="4" datatype="ieee-float"
+ class="field-table-type">
+ <doc>
+ Single precision IEEE 754 32-bit floating point
+ </doc>
+ </constant>
+
+ <constant name="field-table-utf32-char" value="0x27" width="4" datatype="char"
+ class="field-table-type">
+ <doc>
+ Single unicode character in UTF-32 encoding
+ </doc>
+ </constant>
+
+ <!--
+ 0x30 - 0x3f: Fixed width types - 8 octets
+ -->
+
+ <constant name="field-table-eight-octets" value="0x30" width="8" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Eight octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-signed-long" value="0x31" width="8" datatype="signed-integer"
+ class="field-table-type">
+ <doc>
+ 64-bit signed integral value
+ </doc>
+ </constant>
+
+ <constant name="field-table-unsigned-long" value="0x32" width="8" datatype="unsigned-integer"
+ class="field-table-type">
+ <doc>
+ 64-bit unsigned integral value
+ </doc>
+ </constant>
+
+ <constant name="field-table-double" value="0x33" width="8" datatype="ieee-float"
+ class="field-table-type">
+ <doc>
+ Double precision IEEE 754 floating point
+ </doc>
+ </constant>
+
+ <constant name="field-table-datetime" value="0x38" width="8" datatype="special"
+ class="field-table-type">
+ <doc>
+ Datetime in POSIX time_t format
+ </doc>
+ </constant>
+
+ <!--
+ 0x40 - 0x4f: Fixed width types - 16 octets
+ -->
+
+ <constant name="field-table-sixteen-octets" value="0x40" width="16" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Sixteen octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-uuid" value="0x48" width="16" datatype="special"
+ class="field-table-type">
+ <doc>
+ UUID as defined by RFC4122
+ </doc>
+ </constant>
+
+ <!--
+ 0x50 - 0x5f: Fixed width types - 32 octets
+ -->
+
+ <constant name="field-table-thirty-two-octets" value="0x50" width="32" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Thirty two octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <!--
+ 0x60 - 0x6f: Fixed width types - 64 octets
+ -->
+
+ <constant name="field-table-sixty-four-octets" value="0x60" width="64" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Sixty four octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <!--
+ 0x70 - 0x7f: Fixed width types - 128 octets
+ -->
+
+ <constant name="field-table-128-octets" value="0x70" width="128" datatype="binary"
+ class="field-table-type">
+ <doc>
+ One hundred and twenty eight octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <!--
+ 0x80 - 0x8f: Variable length - one byte length field (up to 255 octets)
+ -->
+
+ <constant name="field-table-short-binary" value="0x80" lfwidth="1" datatype="binary"
+ class="field-table-type">
+ <doc>
+ A sequence of up to 255 octets representing opaque binary data
+ </doc>
+ </constant>
+
+ <constant name="field-table-short-string" value="0x84" lfwidth="1" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of up to 255 characters in the iso-8859-15 character set
+ </doc>
+ </constant>
+
+ <constant name="field-table-short-utf8-string" value="0x85" lfwidth="1" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most
+ 255 bytes
+ </doc>
+ </constant>
+
+ <constant name="field-table-short-utf16-string" value="0x86" lfwidth="1" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most
+ 255 bytes
+ </doc>
+ </constant>
+
+ <constant name="field-table-short-utf32-string" value="0x87" lfwidth="1" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most
+ 255 bytes (i.e. of 0-63 utf32 characters)
+ </doc>
+ </constant>
+
+ <!--
+ 0x90 - 0x9f: Variable length types - two byte length field (up to 65535 octets)
+ -->
+
+ <constant name="field-table-binary" value="0x90" lfwidth="2" datatype="binary"
+ class="field-table-type">
+ <doc>
+ A sequence of up to 65535 octets representing opaque binary data
+ </doc>
+ </constant>
+
+ <constant name="field-table-string" value="0x94" lfwidth="2" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of up to 65535 characters in the iso-8859-15 character set
+ </doc>
+ </constant>
+
+ <constant name="field-table-utf8-string" value="0x95" lfwidth="2" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most
+ 65535 bytes
+ </doc>
+ </constant>
+
+ <constant name="field-table-utf16-string" value="0x96" lfwidth="2" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most
+ 65535 bytes
+ </doc>
+ </constant>
+
+ <constant name="field-table-utf32-string" value="0x97" lfwidth="2" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most
+ 65535 bytes (i.e. of 0-16383 utf32 characters)
+ </doc>
+ </constant>
+
+ <!--
+ 0xa0 - 0xaf: Variable length types - four byte length field (up to 4294967295 octets)
+ -->
+
+ <constant name="field-table-long-binary" value="0xa0" lfwidth="4" datatype="binary"
+ class="field-table-type">
+ <doc>
+ A sequence of up to 4294967295 octets representing opaque binary data
+ </doc>
+ </constant>
+
+ <constant name="field-table-long-string" value="0xa4" lfwidth="4" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of up to 4294967295 characters in the iso-8859-15 character set
+ </doc>
+ </constant>
+
+ <constant name="field-table-long-utf8-string" value="0xa5" lfwidth="4" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most
+ 4294967295 bytes
+ </doc>
+ </constant>
+
+ <constant name="field-table-long-utf16-string" value="0xa6" lfwidth="4" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most
+ 4294967295 bytes
+ </doc>
+ </constant>
+
+ <constant name="field-table-long-utf32-string" value="0xa7" lfwidth="4" datatype="string"
+ class="field-table-type">
+ <doc>
+ A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most
+ 4294967295 bytes (i.e. of 0-1073741823 utf32 characters)
+ </doc>
+ </constant>
+
+ <constant name="field-table-table" value="0xa8" lfwidth="4" datatype="field-table"
+ class="field-table-type">
+ <doc>
+ A field table following the encoding specification given here
+ </doc>
+ </constant>
+
+ <constant name="field-table-sequence" value="0xa9" lfwidth="4" datatype="sequence"
+ class="field-table-type">
+ <doc>
+ A sequence is a series of consecutive type-value pairs; using the same type designators as the
+ field table
+ </doc>
+ </constant>
+
+ <constant name="field-table-array" value="0xaa" lfwidth="4" datatype="array"
+ class="field-table-type">
+ <doc>
+ An array represents a collection of values of the same type. The array is encoded as a single
+ octet type designator (using the same system as given here for the field table), followed by a
+ four-octet unsigned integer which represents the number of elements in the collection,
+ followed by the encoding of that number of values of the given type
+ </doc>
+ </constant>
+
+ <!--
+ 0xb0 - 0xbf: Reserved
+ -->
+
+ <!--
+ 0xc0 - 0xcf:Fixed width types - 5 octets
+ -->
+
+ <constant name="field-table-five-octets" value="0xc0" width="5" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Five octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-decimal" value="0xc8" width="5" datatype="decimal"
+ class="field-table-type">
+ <doc>
+ Encoded as an octet representing the number of decimal places followed by a signed 4 octet
+ integer. The 'decimals' octet is not signed
+ </doc>
+ </constant>
+
+ <!--
+ 0xd0 - 0xdf: Fixed width types - 9 octets
+ -->
+
+ <constant name="field-table-nine-octets" value="0xd0" width="9" datatype="binary"
+ class="field-table-type">
+ <doc>
+ Eight octets of unspecified binary encoding
+ </doc>
+ </constant>
+
+ <constant name="field-table-long-decimal" value="0xd8" width="9" datatype="decimal"
+ class="field-table-type">
+ <doc>
+ Encoded as an octet representing the number of decimal places followed by a signed 8 octet
+ integer. The 'decimals' octet is not signed
+ </doc>
+ </constant>
+
+ <!--
+ 0xe0 - 0xef: Reserved
+ -->
+
+ <!--
+ 0xf0 - 0xff: Zero-length types
+ -->
+
+ <constant name="field-table-void" value="0xf0" width="0" datatype="void"
+ class="field-table-type">
+ <doc>
+ The void type
+ </doc>
+ </constant>
+
+ <!--
+ ======================================================
+ == DOMAIN TYPES
+ ======================================================
+ -->
+
+ <domain name="access-ticket" type="short" label="access ticket granted by server">
+ <doc>
+ An access ticket granted by the server for a certain set of access rights within a specific
+ realm. Access tickets are valid within the session where they were created, and expire when
+ the session closes.
+ </doc>
+ <assert check="ne" value="0" />
+ </domain>
+
+ <domain name="class-id" type="short">
+ <doc>
+ <!-- TODO: Description required for docs -->
+ </doc>
+ </domain>
+ <domain name="method-id" type="short">
+ </domain>
+
+ <domain name="consumer-tag" type="shortstr" label="consumer tag">
+ <doc>
+ Identifier for the consumer, valid within the current connection.
+ </doc>
+ </domain>
+
+ <domain name="delivery-tag" type="longlong" label="server-assigned delivery tag">
+ <doc>
+ The server-assigned and session-specific delivery tag
+ </doc>
+ <rule name="session-local">
+ <doc>
+ The delivery tag is valid only within the session from which the message was received. i.e.
+ A client MUST NOT receive a message on one session and then acknowledge it on another.
+ </doc>
+ </rule>
+ <rule name="non-zero">
+ <doc>
+ The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use,
+ meaning "all messages so far received".
+ </doc>
+ </rule>
+ <assert check="ne" value="0" />
+ </domain>
+
+ <domain name="exchange-name" type="shortstr" label="exchange name">
+ <doc>
+ The exchange name is a client-selected string that identifies the exchange for publish
+ methods. Exchange names may consist of any mixture of digits, letters, and underscores.
+ Exchange names are scoped by the virtual host.
+ </doc>
+ <assert check="regexp" value="[a-zA-Z0-9_]{1,127}">
+ <doc>
+ This regular expression checks that all characters are one of a-z (lower case), A-Z (upper
+ case), 0-9 (any digit) and the underscore character. There may be between 1 and 127 of these
+ characters.
+ </doc>
+ </assert>
+ </domain>
+
+ <domain name="known-hosts" type="shortstr" label="list of known hosts">
+ <doc>
+ Specifies the list of equivalent or alternative hosts that the server knows about, which will
+ normally include the current server itself. Clients can cache this information and use it when
+ reconnecting to a server after a failure. This field may be empty.
+ </doc>
+ </domain>
+
+ <domain name="message-id" type="uuid">
+ <doc>
+ Message-id is an optional property of UUID type which uniquly identifies a message within the
+ message system. The message producer is usually responsible for setting the message-id. Note
+ that the server may discard a message as a duplicate if the value of the message-id matches
+ that of a previously received message.
+ </doc>
+ <rule name="unique">
+ <doc>
+ A message MUST be unique within a given server instance. A message 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>
+ </domain>
+
+ <domain name="no-ack" type="bit" label="no acknowledgement needed">
+ <doc>
+ If this field is set the server does not expect acknowledgements for messages. That is, when a
+ message is delivered to the client the server automatically and silently acknowledges it on
+ behalf of the client. This functionality increases performance but at the cost of reliability.
+ Messages can get lost if a client dies before it can deliver them to the application.
+ </doc>
+ </domain>
+
+ <domain name="no-local" type="bit" label="do not deliver own messages">
+ <doc>
+ If the no-local field is set the server will not send messages to the connection that
+ published them.
+ </doc>
+ </domain>
+
+ <domain name="path" type="shortstr">
+ <doc>
+ Must start with a slash "/" and continue with path names separated by slashes. A path name
+ consists of any combination of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:].
+ </doc>
+ <assert check="notnull" />
+ <assert check="syntax" rule="path" />
+ <assert check="length" value="127" />
+ </domain>
+
+ <domain name="peer-properties" type="table">
+ <doc>
+ This string provides a set of peer properties, used for identification, debugging, and general
+ information.
+ </doc>
+ </domain>
+
+ <domain name="queue-name" type="shortstr" label="queue name">
+ <doc>
+ The queue name identifies the queue within the vhost. Queue names must have a length of
+ between 1 and 255 chatacters inclusive, must start with a digit, letter or underscores ('_')
+ character, and must be otherwise encoded in UTF-8.
+ </doc>
+ <assert check="regexp" value="[a-zA-Z0-9_].{0,254}">
+ <doc>
+ This regular expression checks that the first character is one of a-z (lower case), A-Z
+ (upper case), 0-9 (any digit) and the underscore character. Following may be between 0 and
+ 254 characters of any value.
+ </doc>
+ </assert>
+ </domain>
+
+ <domain name="redelivered" type="bit" label="message is being redelivered">
+ <doc>
+ This indicates that the message has been previously delivered to this or another client.
+ </doc>
+ <rule name="implementation">
+ <doc>
+ The server SHOULD try to signal redelivered messages when it can. When redelivering a
+ message that was not successfully acknowledged, 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. Consume the message using explicit
+ acknowledgements, but do not acknowledge the message. Close the connection, reconnect, and
+ consume from the queue again. The message should arrive with the redelivered flag set.
+ </doc>
+ </rule>
+ <rule name="hinting">
+ <doc>
+ The client MUST NOT rely on the redelivered field but should take it as a hint that the
+ message may already have been processed. A fully robust client must be able to track
+ duplicate received messages on non-transacted, and locally-transacted sessions.
+ </doc>
+ </rule>
+ </domain>
+
+ <domain name="rfc1982-long" type="long" label="serial number with arithmetic per RFC1982">
+ <doc>
+ Serial number defined in RFC1982 which defines the arithmatic, operators and ranges of such
+ numbers.
+ </doc>
+ </domain>
+
+ <domain name="reply-code" type="short" label="reply code from server">
+ <doc>
+ The reply code. The AMQ reply codes are defined as constants at the start of this formal
+ specification.
+ </doc>
+ <assert check="notnull" />
+ </domain>
+
+ <domain name="reply-text" type="shortstr" label="localised reply text">
+ <doc>
+ The localised reply text. This text can be logged as an aid to resolving issues.
+ </doc>
+ <assert check="notnull" />
+ </domain>
+
+ <!-- Domains for the message class -->
+
+ <domain name="duration" type="longlong" label="duration in milliseconds">
+ <doc>
+ Duration of an event or process measured in milliseconds.
+ </doc>
+ </domain>
+
+ <domain name="offset" type="longlong" label="offset into a message body">
+ <doc>
+ Offset in bytes into a message body.
+ </doc>
+ </domain>
+
+ <domain name="reference" type="longstr" label="pointer to a message body">
+ <doc>
+ Identifier to be used as a reference to a message body.
+ </doc>
+ </domain>
+
+ <domain name="destination" type="shortstr" label="destination for a message">
+ <doc>
+ Specifies the destination to which the message is to be transferred. The destination can be
+ empty, meaning the default exchange or consumer.
+ </doc>
+ </domain>
+
+ <domain name="reject-code" type="short" label="reject code for transfer">
+ <doc>
+ Code specifying the reason for a message reject.
+ </doc>
+ <rule name="allowed-values">
+ <doc>
+ The reject code must be one of 0 (generic) or 1 (immediate delivery was attempted but
+ failed).
+ </doc>
+ </rule>
+ </domain>
+
+ <domain name="reject-text" type="shortstr" label="informational text for message reject">
+ <doc>
+ String describing the reason for a message transfer rejection.
+ </doc>
+ </domain>
+
+ <domain name="security-token" type="longstr" label="security token">
+ <doc>
+ A security token used for authentication, replay prevention, and encrypted message bodies.
+ </doc>
+ </domain>
+
+ <!-- Domians for DTX -->
+
+ <domain name="xid" type="longstr" label="Dtx branch identifier">
+ <doc>
+ An xid uniquely identifies a transaction branch.
+ </doc>
+
+ <rule name="implementation">
+ <doc>
+ xid contains a format identifier, two length fields and a data field:
+
+ format_id long
+
+ gtrid_length octet
+
+ bqual_length octet
+
+ data gtrid_length + bqual_length
+ </doc>
+ <doc type="picture">
+ 4 1 1 g b
+ +---+---+---+---+---+---+---+- -+---+---+- -+---+
+ | format_id | g | b | txn-id | br-id |
+ +---+---+---+---+---+---+---+- -+---+---+- -+---+
+ 0 4 5 6 6+g 6+g+b
+ </doc>
+ <doc>
+ format_id: an implementation specific format identifier
+
+ gtrid_length: how many bytes of this form the transaction id
+
+ bqual_length: how many bytes of this form the branch id
+
+ data: a sequence of octets of at most 128 bytes containing the txn id and the
+ branch id
+
+ Note - The sum of the two lengths must equal the length of the data field.
+ </doc>
+ </rule>
+ </domain>
+
+ <!-- Domains for session class -->
+
+ <domain name="detached-lifetime" type="long" label="possibly unbounded duration in seconds">
+ <doc>
+ Detached-lifetime is an integer encoded as follows:
+
+ * the maximum representable value means unbounded - the maximum length permitted by the peer
+
+ * otherwise, any other value (including zero) is the number of seconds the session's state
+ is retained during periods when no channel (or equivalent) is attached to the session
+ (DetachedLifetimeFinite above).
+ </doc>
+ </domain>
+
+ <domain name="session-id" type="uuid" label="session identifier" />
+
+ <!-- Elementary domains -->
+ <domain name="bit" type="bit" label="single bit" />
+ <domain name="octet" type="octet" label="single octet" />
+ <domain name="short" type="short" label="16-bit integer" />
+ <domain name="long" type="long" label="32-bit integer" />
+ <domain name="longlong" type="longlong" label="64-bit integer" />
+ <domain name="shortstr" type="shortstr" label="short string" />
+ <domain name="longstr" type="longstr" label="long string" />
+ <domain name="timestamp" type="timestamp" label="64-bit POSIX timestamp" />
+ <domain name="table" type="table" label="field table" />
+ <domain name="uuid" type="uuid" label="UUID (RFC4122 section 4.1.2) - 16 octets" />
+
+ <domain name="content" type="content" label="message content">
+ <doc>
+ Content of a message. It should be considered opaque binary data. The length of the message is
+ determined from the context of this type (the message length field of the message.transfer
+ method).
+ </doc>
+ </domain>
+
+ <domain name="rfc1982-long-set" type="rfc1982-long-set" label="ranged set representation">
+ <doc>
+ Set of pairs of RFC-1982 numbers representing a discontinuous range. Each pair represents a
+ closed interval within the list.
+
+ For example, the set (1,3), (6,6), (8,9) represents the sequence 1,2,3,6,8,9.
+ </doc>
+ </domain>
+
+ <!-- == Class: connextion ==================================================================== -->
+
+ <!-- TODO 0.81 - the 'handler' attribute of methods needs to be reviewed, and if no current
+ implementations use it, removed. /PH 2006/07/20
+ -->
+
+ <class name="connection" handler="connection" index="10" label="work with socket connections">
+ <doc>
+ The connection class provides methods for a client to establish a network connection to a
+ server, and for both peers to operate the connection thereafter.
+ </doc>
+
+ <doc type="grammar">
+ connection = open-connection
+ *use-connection
+ close-connection
+ open-connection = C:protocol-header
+ S:START C:START-OK
+ *challenge
+ S:TUNE C:TUNE-OK
+ C:OPEN S:OPEN-OK | S:REDIRECT
+ challenge = S:SECURE C:SECURE-OK
+ use-connection = *channel
+ close-connection = C:CLOSE S:CLOSE-OK
+ / S:CLOSE C:CLOSE-OK
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <!-- - Method: connextion.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="start" synchronous="1" index="10" label="start connection negotiation">
+ <doc>
+ This method starts the connection negotiation process by telling the client the protocol
+ version that the server proposes, along with a list of security mechanisms which the client
+ can use for authentication.
+ </doc>
+
+ <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 method.
+ </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="server-support">
+ <doc>
+ The server MUST provide a protocol version that is lower than or equal to that requested
+ by the client in the protocol header.
+ </doc>
+ <doc type="scenario">
+ The client requests a protocol version that is higher than any valid implementation, e.g.
+ 9.0. The server must respond with a current protocol version, e.g. 1.0.
+ </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>
+
+ <chassis name="client" implement="MUST" />
+
+ <response name="start-ok" />
+
+ <field name="version-major" domain="octet" label="protocol major version">
+ <doc>
+ The protocol version, major component, as transmitted in the AMQP protocol header. This,
+ combined with the protocol minor component fully describe the protocol version, which is
+ written in the format major-minor. Hence, with major=1, minor=3, the protocol version
+ would be "1-3".
+ </doc>
+ </field>
+
+ <field name="version-minor" domain="octet" label="protocol minor version">
+ <doc>
+ The protocol version, minor component, as transmitted in the AMQP protocol header. This,
+ combined with the protocol major component fully describe the protocol version, which is
+ written in the format major-minor. Hence, with major=1, minor=3, the protocol version
+ would be "1-3".
+ </doc>
+ </field>
+
+ <field name="server-properties" domain="peer-properties" 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>
+
+ <field name="mechanisms" domain="longstr" label="available security mechanisms">
+ <doc>
+ A list of the security mechanisms that the server supports, delimited by spaces.
+ </doc>
+ <assert check="notnull" />
+ </field>
+
+ <field name="locales" domain="longstr" label="available message locales">
+ <doc>
+ A list of the message locales that the server supports, delimited by spaces. The locale
+ defines the language in which the server will send reply texts.
+ </doc>
+
+ <rule name="required-support">
+ <doc>
+ The server MUST support at least the en_US locale.
+ </doc>
+ <doc type="scenario">
+ Client connects to server and inspects the locales field. It checks for the presence of
+ the required locale(s).
+ </doc>
+ </rule>
+
+ <assert check="notnull" />
+ </field>
+ </method>
+
+ <!-- - Method: connextion.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="start-ok" synchronous="1" index="11"
+ label="select security mechanism and locale">
+ <doc>
+ This method selects a SASL security mechanism.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+
+ <field name="client-properties" domain="peer-properties" 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="mechanism" domain="shortstr" label="selected security mechanism">
+ <doc>
+ A single security mechanisms selected by the client, which must be one of those specified
+ by the server.
+ </doc>
+
+ <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 Start method, the server MUST close the connection without sending any
+ further data.
+ </doc>
+ <doc type="scenario">
+ Client connects to server and sends an invalid security mechanism. The server must
+ respond by closing the connection (a socket close, with no connection close
+ negotiation).
+ </doc>
+ </rule>
+
+ <assert check="notnull" />
+ </field>
+
+ <field name="response" domain="longstr" 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>
+ <assert check="notnull" />
+ </field>
+
+ <field name="locale" domain="shortstr" label="selected message locale">
+ <doc>
+ A single message locale selected by the client, which must be one of those specified by
+ the server.
+ </doc>
+ <assert check="notnull" />
+ </field>
+ </method>
+
+ <!-- - Method: connextion.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="secure" synchronous="1" index="20" label="security mechanism challenge">
+ <doc>
+ The SASL protocol works by exchanging challenges and responses until both peers have
+ received sufficient information to authenticate each other. This method challenges the
+ client to provide more information.
+ </doc>
+
+ <chassis name="client" implement="MUST" />
+
+ <response name="secure-ok" />
+
+ <field name="challenge" domain="longstr" label="security challenge data">
+ <doc>
+ Challenge information, a block of opaque binary data passed to the security mechanism.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: connextion.secure-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="secure-ok" synchronous="1" index="21" label="security mechanism response">
+ <doc>
+ This method attempts to authenticate, passing a block of SASL data for the security
+ mechanism at the server side.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+
+ <field name="response" domain="longstr" 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>
+ <assert check="notnull" />
+ </field>
+ </method>
+
+ <!-- - Method: connextion.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="tune" synchronous="1" index="30" label="propose connection tuning parameters">
+ <doc>
+ This method proposes a set of connection configuration values to the client. The client can
+ accept and/or adjust these.
+ </doc>
+
+ <chassis name="client" implement="MUST" />
+
+ <response name="tune-ok" />
+
+ <field name="channel-max" domain="short" label="proposed maximum channels">
+ <doc>
+ The maximum total number of channels that the server allows per connection. Zero means
+ that the server does not impose a fixed limit, but the number of allowed channels may be
+ limited by available server resources.
+ </doc>
+ </field>
+
+ <field name="frame-max" domain="long" label="proposed maximum frame size">
+ <doc>
+ The largest frame size that the server proposes for the connection. The client can
+ negotiate a lower value. Zero means that the server does not impose any specific limit but
+ may reject very large frames if it cannot allocate resources for them.
+ </doc>
+
+ <rule name="minimum">
+ <doc>
+ Until the frame-max has been negotiated, both peers MUST accept frames of up to
+ frame-min-size octets large, and the minimum negotiated value for frame-max is also
+ frame-min-size.
+ </doc>
+ <doc type="scenario">
+ Client connects to server and sends a large properties field, creating a frame of
+ frame-min-size octets. The server must accept this frame.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="heartbeat" domain="short" label="desired heartbeat delay">
+ <!-- TODO 0.82 - the heartbeat negotiation mechanism was changed during implementation
+ because the model documented here does not actually work properly. The best model we
+ found is that the server proposes a heartbeat value to the client; the client can reply
+ with zero, meaning 'do not use heartbeats (as documented here), or can propose its own
+ heartbeat value, which the server should then accept. This is different from the model
+ here which is disconnected - e.g. each side requests a heartbeat independently. Basically
+ a connection is heartbeated in both ways, or not at all, depending on whether both peers
+ support heartbeating or not, and the heartbeat value should itself be chosen by the client
+ so that remote links can get a higher value. Also, the actual heartbeat mechanism needs
+ documentation, and is as follows: so long as there is activity on a connection - in or out
+ - both peers assume the connection is active. When there is no activity, each peer must
+ send heartbeat frames. When no heartbeat frame is received after N cycles (where N is at
+ least 2), the connection can be considered to have died. /PH 2006/07/19
+ -->
+ <doc>
+ The delay, in seconds, of the connection heartbeat that the server wants. Zero means the
+ server does not want a heartbeat.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: connextion.tune-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="tune-ok" synchronous="1" index="31"
+ label="negotiate connection tuning parameters">
+ <doc>
+ This method sends the client's connection tuning parameters to the server. Certain fields
+ are negotiated, others provide capability information.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+
+ <field name="channel-max" domain="short" label="negotiated maximum channels">
+ <doc>
+ The maximum total number of channels that the client will use per connection.
+ </doc>
+
+ <rule name="upper-limit">
+ <doc>
+ If the client specifies a channel max that is higher than the value provided by the
+ server, the server MUST close the connection without attempting a negotiated close. The
+ server may report the error in some fashion to assist implementors.
+ </doc>
+ </rule>
+
+ <assert check="notnull" />
+ <assert check="le" value="channel-max" />
+ </field>
+
+ <field name="frame-max" domain="long" label="negotiated maximum frame size">
+ <doc>
+ The largest frame size that the client and server will use for the connection. Zero means
+ that the client does not impose any specific limit but may reject very large frames if it
+ cannot allocate resources for them. Note that the frame-max limit applies principally to
+ content frames, where large contents can be broken into frames of arbitrary size.
+ </doc>
+
+ <rule name="minimum">
+ <doc>
+ Until the frame-max has been negotiated, both peers MUST accept frames of up to
+ frame-min-size octets large, and the minimum negotiated value for frame-max is also
+ frame-min-size.
+ </doc>
+ </rule>
+
+ <rule name="upper-limit">
+ <doc>
+ If the client specifies a frame max that is higher than the value provided by the
+ server, the server MUST close the connection without attempting a negotiated close. The
+ server may report the error in some fashion to assist implementors.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="heartbeat" domain="short" label="desired heartbeat delay">
+ <doc>
+ The delay, in seconds, of the connection heartbeat that the client wants. Zero means the
+ client does not want a heartbeat.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: connextion.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="open" synchronous="1" index="40" label="open connection to virtual host">
+ <doc>
+ This method 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>
+
+ <chassis name="server" implement="MUST" />
+
+ <response name="open-ok" />
+ <response name="redirect" />
+
+ <field name="virtual-host" domain="path" label="virtual host name">
+ <!-- TODO 0.82 - the entire vhost model needs review. This concept was prompted by the HTTP
+ vhost concept but does not fit very well into AMQP. Currently we use the vhost as a
+ "cluster identifier" which is inaccurate usage. /PH 2006/07/19
+ -->
+ <doc>
+ The name of the virtual host to work with.
+ </doc>
+
+ <rule name="separation">
+ <doc>
+ If the server supports multiple virtual hosts, it MUST enforce a full separation 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>
+
+ <rule name="security">
+ <doc>
+ The server SHOULD verify that the client has permission to access the specified virtual
+ host.
+ </doc>
+ </rule>
+ <assert check="regexp" value="^[a-zA-Z0-9/-_]+$" />
+ </field>
+
+ <field name="capabilities" domain="shortstr" label="required capabilities">
+ <doc>
+ The client can specify zero or more capability names, delimited by spaces. The server can
+ use this string to how to process the client's connection request.
+ </doc>
+ </field>
+
+ <field name="insist" domain="bit" label="insist on connecting to server">
+ <doc>
+ In a configuration with multiple collaborating servers, the server may respond to a
+ Connection.Open method with a Connection.Redirect. The insist option tells the server that
+ the client is insisting on a connection to the specified server.
+ </doc>
+ <rule name="behaviour">
+ <doc>
+ When the client uses the insist option, the server MUST NOT respond with a
+ Connection.Redirect method. If it cannot accept the client's connection request it
+ should respond by closing the connection with a suitable reply code.
+ </doc>
+ </rule>
+ </field>
+ </method>
+
+ <!-- - Method: connextion.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="open-ok" synchronous="1" index="41" label="signal that connection is ready">
+ <doc>
+ This method signals to the client that the connection is ready for use.
+ </doc>
+
+ <chassis name="client" implement="MUST" />
+
+ <field name="known-hosts" domain="known-hosts" />
+ </method>
+
+ <!-- - Method: connextion.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="redirect" synchronous="1" index="42" label="redirects client to other server">
+ <doc>
+ This method redirects the client to another server, based on the requested virtual host
+ and/or capabilities.
+ </doc>
+
+ <rule name="usage">
+ <doc>
+ When getting the Connection.Redirect method, the client SHOULD reconnect to the host
+ specified, and if that host is not present, to any of the hosts specified in the
+ known-hosts list.
+ </doc>
+ </rule>
+
+ <chassis name="client" implement="MUST" />
+
+ <field name="host" domain="shortstr" label="server to connect to">
+ <doc>
+ Specifies the server to connect to. This is an IP address or a DNS name, optionally
+ followed by a colon and a port number. If no port number is specified, the client should
+ use the default port number for the protocol.
+ </doc>
+ <assert check="notnull" />
+ </field>
+
+ <field name="known-hosts" domain="known-hosts" />
+ </method>
+
+ <!-- - Method: connection.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="close" synchronous="1" index="50" label="request a connection close">
+ <doc>
+ This method indicates that the sender wants to close the connection. This may be due to
+ internal conditions (e.g. a forced shut-down) or due to an error handling a specific method,
+ i.e. an exception. When a close is due to an exception, the sender provides the class and
+ method id of the method which caused the exception.
+ </doc>
+ <!-- TODO: The connection close mechanism needs to be reviewed from the ODF documentation and
+ better expressed as rules here. /PH 2006/07/20
+ -->
+
+ <rule name="stability">
+ <doc>
+ After sending this method any received method except the Close-OK method MUST be
+ discarded.
+ </doc>
+ </rule>
+
+ <chassis name="client" implement="MUST" />
+ <chassis name="server" implement="MUST" />
+
+ <response name="close-ok" />
+
+ <field name="reply-code" domain="reply-code" />
+ <field name="reply-text" domain="reply-text" />
+
+ <field name="class-id" domain="class-id" label="failing method class">
+ <doc>
+ When the close is provoked by a method exception, this is the class of the method.
+ </doc>
+ </field>
+
+ <field name="method-id" domain="method-id" label="failing method ID">
+ <doc>
+ When the close is provoked by a method exception, this is the ID of the method.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: connextion.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="close-ok" synchronous="1" index="51" label="confirm a connection close">
+ <doc>
+ This method confirms a Connection.Close method and tells the recipient that it is safe to
+ release resources for the connection and close the socket.
+ </doc>
+
+ <rule name="reporting">
+ <doc>
+ A peer that detects a socket closure without having received a Close-Ok handshake method
+ SHOULD log the error.
+ </doc>
+ </rule>
+
+ <chassis name="client" implement="MUST" />
+ <chassis name="server" implement="MUST" />
+ </method>
+
+ </class>
+
+ <!-- == Class: session ======================================================================= -->
+
+ <class name="session" handler="session" index="20" label="session control methods">
+ <doc>
+ The session class provides methods for a client to establish a session with a server and for
+ both peers to operate the session thereafter.
+ </doc>
+
+ <doc type="grammar">
+ session = open-session
+ *use-session
+ close-session
+ open-session = C:OPEN S:ATTACHED
+ / C:RESUME S:ATTACHED
+ use-session = C:FLOW S:FLOW-OK
+ / S:FLOW C:FLOW-OK
+ / S:PING
+ / C:PONG
+ / C:PING
+ / S:PONG
+ close-session = C:SUSPEND S:DETACHED
+ / C:CLOSE S:CLOSED
+ / S:CLOSED
+ / S:CLOSE C:CLOSED
+ / C:CLOSED
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <!-- - Method: session.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="open" synchronous="1" index="10" label="open a session for use">
+ <doc>
+ This method opens a session with the server.
+
+ When the responding peer creates the session, it MUST create a new, appropriately-unique
+ name for the session and return this to the creator with the rest of the session details.
+
+ Note that the timer controlling a session's automatic expiry, if any, counts down
+ immediately from the moment of its creation, unless simultaneously with that moment a
+ channel (or equivalent) is attached to the session. For this reason, it is recommended that
+ network protocol mappings create sessions simultaneously with the creation and attachment of
+ their channel-equivalents, since a zero lease time is perfectly valid and indicates that the
+ session should be destroyed as soon as it first finds itself inactive.
+
+ During the period that a channel (or equivalent) is attached to a session, the session has
+ no deletion timer. Every time a channel is detached from a session such that the session is
+ left without any attached network-level entities, the timer is created, set to its declared
+ value and started.
+
+ Note that if the peer decides that the requested detached-lifetime timeout is too long,
+ either because the replying peer does not support sessions with non-zero requested timeouts,
+ or because the requested timeout exceeds some peer-specific limitation, it may substitute an
+ acceptable value for the detached-lifetime parameter in its reply to the creation request.
+ An exception is not required.
+ </doc>
+
+ <rule name="expiration">
+ <doc>
+ Whether the detachment is explicit or implicit, as a result of application action or of
+ application error, the channel (or equivalent) is detached from its session and the
+ session timer MUST start counting down as defined in session.open.
+ </doc>
+ </rule>
+
+ <rule name="channel-busy">
+ <!-- TODO: Figure out how to make this error conditional to stateful network mappings with
+ channels.
+ -->
+ <doc>
+ The client MUST NOT send session.open on a channel that is already associated with a
+ session. A "channel busy" connection exception will occur if the channel down which the
+ open request was sent was already attached to a session.
+ </doc>
+ <doc type="scenario">
+ Client sends session.open twice down the same channel.
+ </doc>
+ </rule>
+
+ <!--
+ <throws name="out-of-resources"/>
+ -->
+
+ <chassis name="server" implement="MUST" />
+
+ <response name="attached" />
+
+ <field name="detached-lifetime" domain="detached-lifetime">
+ <doc>
+ The number of seconds the session's state is retained during periods when no channel (or
+ equivalent) is attached to the session.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.attached - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="attached" synchronous="1" index="11" label="signal that the session is ready">
+ <doc>
+ This method signals to the client that the session is ready for use.
+
+ Once a session.attached is received by the client, everything is in place for normal
+ transmission of frames. However, depending on the network protocol mapping in use, the
+ frame-id be undefined until certain control frames have been sent. Please see the specific
+ details for each protocol mapping.
+
+ If the attached session was freshly created, the session-id here will be a freshly-generated
+ UUID.
+
+ Note that the actual session detached-lifetime value, as decided by the peer, is returned
+ using this method. The value returned may not be the same as that requested in the
+ corresponding session creation request. In particular, a request for an unbounded
+ detached-lifetime of may be fulfilled by creation of a session with a bounded actual
+ lifetime parameter. The requesting peer SHOULD take the lifetime value returned as
+ authoritative for its own session-related record-keeping.
+ </doc>
+
+ <chassis name="client" implement="MUST" />
+
+ <field name="session-id" domain="session-id">
+ <doc>
+ The session identifier (a UUID) used to identify this session.
+ </doc>
+ </field>
+
+ <field name="detached-lifetime" domain="detached-lifetime">
+ <doc>
+ The number of seconds the session's state is retained during periods when no channel (or
+ equivalent) is attached to the session.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="flow" synchronous="1" index="20" label="enable/disable flow from peer">
+ <doc>
+ This method asks the peer to pause or restart the flow of content data. This is a simple
+ flow-control mechanism that a peer can use to avoid overflowing its queues or otherwise
+ finding itself receiving more messages than it can process. Note that this method is not
+ intended for window control. The peer that receives a disable flow method should finish
+ sending the current content frame, if any, then pause.
+ </doc>
+
+ <rule name="initial-state">
+ <doc>
+ When a new session is opened, it is active (flow is active). Some applications assume that
+ sessions are inactive until started. To emulate this behaviour a client MAY open the
+ session, then pause it.
+ </doc>
+ </rule>
+
+ <rule name="bidirectional">
+ <doc>
+ When sending content frames, a peer SHOULD monitor the session for incoming methods and
+ respond to a Session.Flow as rapidly as possible.
+ </doc>
+ </rule>
+
+ <rule name="throttling">
+ <doc>
+ A peer MAY use the Session.Flow method to throttle incoming content data for internal
+ reasons, for example, when exchanging data over a slower connection.
+ </doc>
+ </rule>
+
+ <rule name="expected-behaviour">
+ <doc>
+ The peer that requests a Session.Flow method MAY disconnect and/or ban a peer that does
+ not respect the request. This is to prevent badly-behaved clients from overwhelming a
+ broker.
+ </doc>
+ </rule>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <response name="flow-ok" />
+
+ <field name="active" domain="bit" label="start/stop content frames">
+ <doc>
+ If true (1), the peer starts sending content frames. If false (0), the peer stops sending
+ content frames.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.flow-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="flow-ok" index="21" label="confirm a flow method">
+ <doc>
+ Confirms to the peer that a flow command was received and processed.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <field name="active" domain="bit" label="current flow setting">
+ <doc>
+ Confirms the setting of the processed flow method: true (1) means the peer will start
+ sending or continue to send content frames; false (0) means it will not.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="close" index="40" label="request a session close">
+ <doc>
+ Requests that the receiving peer destroy a session, implicitly detaching any attached
+ channels or channel-equivalents.
+
+ Note that the reply, session.closed, is also used for asynchronous exception notifications.
+ For normal closure, such as in response to a session.close request, reason code 200 ("ok")
+ is to be used.
+ </doc>
+
+ <chassis name="client" implement="MUST" />
+ <chassis name="server" implement="MUST" />
+
+ <response name="closed" />
+ </method>
+
+ <!-- - Method: session.closed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="closed" index="41" label="notify of a session close">
+ <doc>
+ Notifies the receiver that not only has the current channel been detached from its
+ underlying session, but that the session itself has been destroyed.
+
+ This method confirms a session.close method and tells the recipient that it is safe to
+ release resources for the channel.
+
+ Note also that for normal closure, reason code 200 ("ok") is to be used.
+ </doc>
+
+ <chassis name="client" implement="MUST" />
+ <chassis name="server" implement="MUST" />
+
+ <field name="reply-code" domain="reply-code">
+ <doc>
+ The numeric reply code.
+ </doc>
+ </field>
+
+ <field name="reply-text" domain="reply-text">
+ <doc>
+ The localised reply text.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.resume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="resume" index="50" label="resume an interrupted session">
+ <doc>
+ Attaches to an already-existing session.
+ </doc>
+
+ <rule name="session-busy">
+ <doc>
+ A "session busy" exception is returned if the session exists, but is not in a condition
+ where it can accept the requested attachment. Peers receiving this exception may wish to
+ retain their session state and retry the session.resume operation after a delay.
+ </doc>
+ </rule>
+
+ <chassis name="server" implement="MAY" />
+
+ <response name="attached" />
+
+ <field name="session-id" domain="session-id">
+ <doc>
+ The session identifier (a UUID) used to identify this session.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.ping - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="ping" index="60" label="[WORK IN PROGRESS] initiates a pong">
+ <doc>
+ [WORK IN PROGRESS] Request that the recipient issue a pong request.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+ </method>
+
+ <!-- - Method: session.pong - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="pong" index="70" label="[WORK IN PROGRESS] issued after receiving a ping">
+ <doc>
+ [WORK IN PROGRESS] Issued after a ping request is received. Note that this is a request
+ issued after receiving a ping, not a response to receiving a ping.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+ </method>
+
+ <!-- - Method: session.suspend - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="suspend" index="90" label="suspend the session">
+ <doc>
+ Indicates the sending peer wishes to detach from this session, but not necessarily to
+ destroy it.
+ </doc>
+
+ <!-- TODO: Ratify the inclusion of the chassis element in the XML. -->
+ <chassis name="server" implement="MAY" />
+
+ <response name="detached"/>
+ </method>
+
+ <!-- - Method: session.detached - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="detached" index="100" label="signal detachment of the session">
+ <doc>
+ Signal detachment from the session.
+ </doc>
+ <!-- TODO: Ratify the inclusion of the chassis element in the XML. -->
+ <chassis name="client" implement="MAY" />
+ </method>
+
+ <!-- - Method: session.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <!-- TODO: This method does not appear in any grammar as yet... -->
+ <method name="ack" index="110" label="acknowledge receipt of frames">
+ <doc>
+ Signals receipt of all frames such that frame-id <= cumulative-seen-mark, or frame-id is
+ in the set defined by seen-frame-set. This can be sent spontaneously, or in response to
+ either session.solicit-ack or session.high-water-mark.
+
+ Note that an encoded acknowledgement frame carried over the TCP network mapping (in the
+ absence of cross-protocol use of a session) will never have any entries in its
+ seen-frame-set.
+
+ <!-- TODO: See chapter (TBD here) for how frame ids are computed. -->
+ </doc>
+
+ <rule name="unique-encoding">
+ <doc>
+ In order to ensure a canonical wire representation, the value cumulative-seen-mark +
+ 1 must not be covered by the seen-frame-set.
+ </doc>
+ </rule>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <field name="cumulative-seen-mark" domain="rfc1982-long" label="Low-water mark for seen ids">
+ <doc>
+ The low-water mark for seen frame-ids. All ids below this mark have been seen; above this
+ mark, there are gaps containing unseen ids (i.e. discontinuous). By definition, the first
+ frame-id above this mark (if it exists) is an unseen id.
+ </doc>
+ </field>
+
+ <field name="seen-frame-set" domain="rfc1982-long-set"
+ label="Set of discontinuous seen ids above cumulative-seen-mark">
+ <doc>
+ This set contains a sequence of discontinuous seen-frame-ids above the low-water mark
+ (i.e. above the first gap of unseen ids). In some transports where out-of-order delivery
+ is not possible (such as TCP), this set will always be empty.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.high-water-mark - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="high-water-mark" index="120" label="Inform the peer of most recent sent frame-id">
+ <doc>
+ Carries information about the highest (most recent) frame-id number that the sending peer
+ has sent through this session so far.
+
+ The receiver should issue a session.ack at the earliest possible opportunity.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <field name="last-sent-mark" domain="rfc1982-long" label="Frame-id of last sent frame">
+ <doc>
+ Highest frame-id sent by the sending peer through this session so far.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: session.solicit-ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="solicit-ack" index="130" label="request an ack">
+ <doc>
+ Requests a session.ack from the peer. The peer should issue one at the earliest possible
+ opportunity.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+ </method>
+
+ </class>
+
+ <!-- == Class: access ======================================================================== -->
+
+ <!-- TODO 0.82 - this class must be implemented by two teams before we can consider it matured.
+ -->
+
+ <class name="access" handler="connection" index="30" label="work with access tickets">
+ <doc>
+ The protocol control access to server resources using access tickets. A client must explicitly
+ request access tickets before doing work. An access ticket grants a client the right to use a
+ specific set of resources - called a "realm" - in specific ways.
+ </doc>
+
+ <doc type="grammar">
+ access = C:REQUEST S:REQUEST-OK
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <!-- - Method: access.request - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="request" synchronous="1" index="10" label="request an access ticket">
+ <doc>
+ This method requests an access ticket for an access realm. The server responds by granting
+ the access ticket. If the client does not have access rights to the requested realm this
+ causes a connection exception. Access tickets are a per-session resource.
+ </doc>
+
+ <chassis name="server" implement="MUST" />
+
+ <response name="request-ok" />
+
+ <field name="realm" domain="shortstr" label="name of requested realm">
+ <doc>
+ Specifies the name of the realm to which the client is requesting access. The realm is a
+ configured server-side object that collects a set of resources (exchanges, queues, etc.).
+ If the session has already requested an access ticket onto this realm, the previous ticket
+ is destroyed and a new ticket is created with the requested access rights, if allowed.
+ </doc>
+ <rule name="validity" on-failure="access-refused">
+ <doc>
+ The client MUST specify a realm that is known to the server. The server makes an
+ identical response for undefined realms as it does for realms that are defined but
+ inaccessible to this client.
+ </doc>
+ <doc type="scenario">
+ Client specifies an undefined realm.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="exclusive" domain="bit" label="request exclusive access">
+ <doc>
+ Request exclusive access to the realm, meaning that this will be the only session that
+ uses the realm's resources.
+ </doc>
+ <rule name="in-use" on-failure="access-refused">
+ <doc>
+ The client MUST NOT request exclusive access to a realm that has active access tickets,
+ unless the same session already had the only access ticket onto that realm.
+ </doc>
+ <doc type="scenario">
+ Client opens two sessions and requests exclusive access to the same realm.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="passive" domain="bit" label="request passive access">
+ <doc>
+ Request message passive access to the specified access realm. Passive access lets a client
+ get information about resources in the realm but not to make any changes to them.
+ </doc>
+ </field>
+
+ <field name="active" domain="bit" label="request active access">
+ <doc>
+ Request message active access to the specified access realm. Active access lets a client
+ get create and delete resources in the realm.
+ </doc>
+ </field>
+
+ <field name="write" domain="bit" label="request write access">
+ <doc>
+ Request write access to the specified access realm. Write access lets a client publish
+ messages to all exchanges in the realm.
+ </doc>
+ </field>
+
+ <field name="read" domain="bit" label="request read access">
+ <doc>
+ Request read access to the specified access realm. Read access lets a client consume
+ messages from queues in the realm.
+ </doc>
+ </field>
+ </method>
+
+ <!-- - Method: access.request-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="request-ok" synchronous="1" index="11" label="grant access to server resources">
+ <doc>
+ This method provides the client with an access ticket. The access ticket is valid within the
+ current session and for the lifespan of the session.
+ </doc>
+
+ <rule name="per-session" on-failure="not-allowed">
+ <doc>
+ The client MUST NOT use access tickets except within the same session as originally
+ granted.
+ </doc>
+ <doc type="scenario">
+ Client opens two sessions, requests a ticket on one session and then tries to use that
+ ticket in a second session.
+ </doc>
+ </rule>
+
+ <chassis name="client" implement="MUST" />
+
+ <field name="ticket" domain="access-ticket">
+ <doc>
+ A valid access ticket to be used for gaining access to the server.
+ </doc>
+ </field>
+ </method>
+
+ </class>
+
+ <!-- == Class: exchange ====================================================================== -->
+
+ <class name="exchange" handler="channel" index="40" 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
+ </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 methods (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 methods (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 method (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>
+
+ <chassis name="server" implement="MUST" />
+ <chassis name="client" implement="MUST" />
+
+ <!-- - Method: exchange.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <method name="declare" synchronous="1" index="10"
+ label="verify exchange exists, create if needed">
+ <doc>
+ This method 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>
+
+ <chassis name="server" implement="MUST" />
+
+ <field name="ticket" domain="access-ticket">
+ <doc>
+ When a client defines a new exchange, this belongs to the access realm of the ticket used.
+ All further work done with that exchange must be done with an access ticket for the same
+ realm.
+ </doc>
+
+ <rule name="validity" on-failure="access-refused">
+ <doc>
+ The client MUST provide a valid access ticket giving "active" access to the realm in
+ which the exchange exists or will be created, or "passive" access if the if-exists flag
+ is set.
+ </doc>
+ <doc type="scenario">
+ Client creates access ticket with wrong access rights and attempts to use in this
+ method.
+ </doc>
+ </rule>
+
+ <assert check="notnull" />
+ </field>
+
+ <field name="exchange" domain="exchange-name">
+ <rule name="reserved-names" on-failure="access-refused">
+ <doc>
+ Exchange names starting with "amq." are reserved for pre-declared and standardised
[... 4996 lines stripped ...]