You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@activemq.apache.org by ch...@apache.org on 2006/10/10 01:06:49 UTC
svn commit: r454545 [2/3] - in /incubator/activemq/sandbox/qpid: ./ specs/
src/ src/main/ stylesheets/
Added: incubator/activemq/sandbox/qpid/specs/amqp-8.0.xml
URL: http://svn.apache.org/viewvc/incubator/activemq/sandbox/qpid/specs/amqp-8.0.xml?view=auto&rev=454545
==============================================================================
--- incubator/activemq/sandbox/qpid/specs/amqp-8.0.xml (added)
+++ incubator/activemq/sandbox/qpid/specs/amqp-8.0.xml Mon Oct 9 16:06:48 2006
@@ -0,0 +1,3959 @@
+<?xml version="1.0"?>
+
+<!--
+ 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\ufffd 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, 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
+
+-->
+
+<!--
+========================================================
+EDITORS: (PH) Pieter Hintjens <ph...@imatix.com>
+ (KvdR) Kim van der Riet <ki...@redhat.com>
+
+NOTE: 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.
+========================================================
+
+Revision history:
+ 2006-06-07 (PH) - version number changed to 0.8 to conform to public
+ release documentation.
+
+ 2006-05-15 (PH) - fixed comments on queue name in basic.get to clarify
+ use of current queue in this method.
+
+ 2006-05-15 (PH) - fixed comments on routing key in queue.bind to clarify
+ how routing key is filled when empty (to allow asynch queue.declare).
+
+ 2006-05-11 (PH) - reset version to 0.70 so that putatitive standards
+ group can release 2-3 major new versions before hitting 1.0 (again).
+
+ 2006-05-11 (PH) - TODO in documentation: cycle field in frame header
+ has been removed.
+
+ 2006-05-11 (PH) - added nowait option to exchange.declare, delete,
+ queue.declare, delete, bind, purge, basic.consume, cancel,
+ file.consume, cancel, stream.consume and cancel methods.
+
+ 2006-05-11 (PH) - removed notnull rule and added explanations on queue
+ name in queue.bind, purge, delete, basic.consume, cancel, file.consume,
+ cancel, stream.consume and cancel methods.
+
+ 2006-05-11 (PH) - added basic.qos, file.qos, and stream.qos methods that
+ regroup all prefetch options from the consume methods. Also removed the
+ prefetch option from channel.open.
+
+ 2006-05-11 (PH) - renumbered method indexes to show request-response
+ nature of methods; requests are 10, 20, 30 while responses are 11, 21,
+ etc.
+
+ 2006-05-11 (PH) - removed OpenAMQ extension methods from this definition
+ since these are maintained seperately.
+
+ 2006-05-26 (RG) - added Basic.Recover method to allow replay of
+ unacknowledged messages on a channel.
+
+ 2006-07-03 (PH) - cosmetic clean-up of Basic.Recover comments.
+-->
+
+<amqp major="8" minor="0" port="5672" comment="AMQ protocol 0.80">
+ AMQ Protocol 0.80
+
+<!--
+======================================================
+== CONSTANTS
+======================================================
+-->
+ <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"/>
+ <constant name="frame min size" value="4096"/>
+ <constant name="frame end" value="206"/>
+ <constant name="reply success" value="200">
+ 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.
+</constant>
+ <constant name="not delivered" value="310" class="soft error">
+ 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.
+</constant>
+ <constant name="content too large" value="311" class="soft error">
+ The client attempted to transfer content larger than the server
+ could accept at the present time. The client may retry at a later
+ time.
+</constant>
+ <constant name="connection forced" value="320" class="hard error">
+ An operator intervened to close the connection for some reason.
+ The client may retry at some later date.
+</constant>
+ <constant name="invalid path" value="402" class="hard error">
+ The client tried to work with an unknown virtual host or cluster.
+</constant>
+ <constant name="access refused" value="403" class="soft error">
+ The client attempted to work with a server entity to which it has
+ no due to security settings.
+</constant>
+ <constant name="not found" value="404" class="soft error">
+ The client attempted to work with a server entity that does not exist.
+</constant>
+ <constant name="resource locked" value="405" class="soft error">
+ The client attempted to work with a server entity to which it has
+ no access because another client is working with it.
+</constant>
+ <constant name="frame error" value="501" class="hard error">
+ The client sent a malformed frame that the server could not decode.
+ This strongly implies a programming error in the client.
+</constant>
+ <constant name="syntax error" value="502" class="hard error">
+ The client sent a frame that contained illegal values for one or more
+ fields. This strongly implies a programming error in the client.
+</constant>
+ <constant name="command invalid" value="503" class="hard error">
+ 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.
+</constant>
+ <constant name="channel error" value="504" class="hard error">
+ The client attempted to work with a channel that had not been
+ correctly opened. This most likely indicates a fault in the client
+ layer.
+</constant>
+ <constant name="resource error" value="506" class="hard error">
+ 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.
+</constant>
+ <constant name="not allowed" value="530" class="hard error">
+ 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.
+</constant>
+ <constant name="not implemented" value="540" class="hard error">
+ The client tried to use functionality that is not implemented in the
+ server.
+</constant>
+ <constant name="internal error" value="541" class="hard error">
+ 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.
+</constant>
+ <!--
+======================================================
+== DOMAIN TYPES
+======================================================
+-->
+ <domain name="access ticket" type="short">
+ 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
+ channel where they were created, and expire when the channel closes.
+ </doc>
+ <assert check="ne" value="0"/>
+ </domain>
+ <domain name="class id" type="short"/>
+ <domain name="consumer tag" type="shortstr">
+ consumer tag
+ <doc>
+ Identifier for the consumer, valid within the current connection.
+ </doc>
+ <rule implement="MUST">
+ The consumer tag is valid only within the channel from which the
+ consumer was created. I.e. a client MUST NOT create a consumer in
+ one channel and then use it in another.
+ </rule>
+ </domain>
+ <domain name="delivery tag" type="longlong">
+ server-assigned delivery tag
+ <doc>
+ The server-assigned and channel-specific delivery tag
+ </doc>
+ <rule implement="MUST">
+ The delivery tag is valid only within the channel from which the
+ message was received. I.e. a client MUST NOT receive a message on
+ one channel and then acknowledge it on another.
+ </rule>
+ <rule implement="MUST">
+ The server MUST NOT use a zero value for delivery tags. Zero is
+ reserved for client use, meaning "all messages so far received".
+ </rule>
+ </domain>
+ <domain name="exchange name" type="shortstr">
+ 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="length" value="127"/>
+ </domain>
+ <domain name="known hosts" type="shortstr">
+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.
+</doc>
+ <rule implement="MAY">
+The server MAY leave this field empty if it knows of no other
+hosts than itself.
+</rule>
+ </domain>
+ <domain name="method id" type="short"/>
+ <domain name="no ack" type="bit">
+ no acknowledgement needed
+ <doc>
+ If this field is set the server does not expect acknowledgments
+ 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">
+ do not deliver own messages
+ <doc>
+ If the no-local field is set the server will not send messages to
+ the client 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>
+ <rule implement="SHOULD">
+The properties SHOULD contain these fields:
+"product", giving the name of the peer product, "version", giving
+the name of the peer version, "platform", giving the name of the
+operating system, "copyright", if appropriate, and "information",
+giving other general information.
+</rule>
+ </domain>
+ <domain name="queue name" type="shortstr">
+ queue name
+ <doc>
+ The queue name identifies the queue within the vhost. Queue
+ names may consist of any mixture of digits, letters, and
+ underscores.
+ </doc>
+ <assert check="length" value="127"/>
+ </domain>
+ <domain name="redelivered" type="bit">
+ message is being redelivered
+ <doc>
+ This indicates that the message has been previously delivered to
+ this or another client.
+ </doc>
+ <rule implement="SHOULD">
+ 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.
+ </rule>
+ <rule implement="MUST">
+ The client MUST NOT rely on the redelivered field but MUST 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 channels.
+ </rule>
+ </domain>
+ <domain name="reply code" type="short">
+reply code from server
+<doc>
+ The reply code. The AMQ reply codes are defined in AMQ RFC 011.
+</doc>
+ <assert check="notnull"/>
+ </domain>
+ <domain name="reply text" type="shortstr">
+localised reply text
+<doc>
+ The localised reply text. This text can be logged as an aid to
+ resolving issues.
+</doc>
+ <assert check="notnull"/>
+ </domain>
+ <class name="connection" handler="connection" index="10">
+ <!--
+======================================================
+== CONNECTION
+======================================================
+-->
+ 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 name="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 name="start" synchronous="1" index="10">
+ 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 implement="MUST">
+ If the client cannot handle the protocol version suggested by the
+ server it MUST close the socket connection.
+ </rule>
+ <rule implement="MUST">
+ The server MUST provide a protocol version that is lower than or
+ equal to that requested by the client in the protocol header. If
+ the server cannot support the specified protocol it MUST NOT send
+ this method, but MUST close the socket connection.
+ </rule>
+ <chassis name="client" implement="MUST"/>
+ <response name="start-ok"/>
+ <field name="version major" type="octet">
+ protocol major version
+ <doc>
+ The protocol major version that the server agrees to use, which
+ cannot be higher than the client's major version.
+ </doc>
+ </field>
+ <field name="version minor" type="octet">
+ protocol major version
+ <doc>
+ The protocol minor version that the server agrees to use, which
+ cannot be higher than the client's minor version.
+ </doc>
+ </field>
+ <field name="server properties" domain="peer properties">
+ server properties
+ </field>
+ <field name="mechanisms" type="longstr">
+ available security mechanisms
+ <doc>
+ A list of the security mechanisms that the server supports, delimited
+ by spaces. Currently ASL supports these mechanisms: PLAIN.
+ </doc>
+ <see name="security mechanisms"/>
+ <assert check="notnull"/>
+ </field>
+ <field name="locales" type="longstr">
+ 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 implement="MUST">
+ All servers MUST support at least the en_US locale.
+ </rule>
+ <assert check="notnull"/>
+ </field>
+ </method>
+ <method name="start-ok" synchronous="1" index="11">
+ select security mechanism and locale
+ <doc>
+ This method selects a SASL security mechanism. ASL uses SASL
+ (RFC2222) to negotiate authentication and encryption.
+ </doc>
+ <chassis name="server" implement="MUST"/>
+ <field name="client properties" domain="peer properties">
+ client properties
+ </field>
+ <field name="mechanism" type="shortstr">
+ selected security mechanism
+ <doc>
+ A single security mechanisms selected by the client, which must be
+ one of those specified by the server.
+ </doc>
+ <rule implement="SHOULD">
+ The client SHOULD authenticate using the highest-level security
+ profile it can handle from the list provided by the server.
+ </rule>
+ <rule implement="MUST">
+ The mechanism field MUST contain one of the security mechanisms
+ proposed by the server in the Start method. If it doesn't, the
+ server MUST close the socket.
+ </rule>
+ <assert check="notnull"/>
+ </field>
+ <field name="response" type="longstr">
+ 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. For the
+ PLAIN security mechanism this is defined as a field table holding
+ two fields, LOGIN and PASSWORD.
+ </doc>
+ <assert check="notnull"/>
+ </field>
+ <field name="locale" type="shortstr">
+ selected message locale
+ <doc>
+ A single message local selected by the client, which must be one
+ of those specified by the server.
+ </doc>
+ <assert check="notnull"/>
+ </field>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="secure" synchronous="1" index="20">
+ 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" type="longstr">
+ security challenge data
+ <doc>
+ Challenge information, a block of opaque binary data passed to
+ the security mechanism.
+ </doc>
+ <see name="security mechanisms"/>
+ </field>
+ </method>
+ <method name="secure-ok" synchronous="1" index="21">
+ 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" type="longstr">
+ 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 name="tune" synchronous="1" index="30">
+ 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" type="short">
+ 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" type="long">
+ 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 implement="MUST">
+ Until the frame-max has been negotiated, both peers MUST accept
+ frames of up to 4096 octets large. The minimum non-zero value for
+ the frame-max field is 4096.
+ </rule>
+ </field>
+ <field name="heartbeat" type="short">
+ desired heartbeat delay
+ <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 name="tune-ok" synchronous="1" index="31">
+ 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" type="short">
+ negotiated maximum channels
+ <doc>
+ The maximum total number of channels that the client will use
+ per connection. May not be higher than the value specified by
+ the server.
+ </doc>
+ <rule implement="MAY">
+ The server MAY ignore the channel-max value or MAY use it for
+ tuning its resource allocation.
+ </rule>
+ <assert check="notnull"/>
+ <assert check="le" method="tune" field="channel max"/>
+ </field>
+ <field name="frame max" type="long">
+ 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 implement="MUST">
+ Until the frame-max has been negotiated, both peers must accept
+ frames of up to 4096 octets large. The minimum non-zero value for
+ the frame-max field is 4096.
+ </rule>
+ </field>
+ <field name="heartbeat" type="short">
+ 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 name="open" synchronous="1" index="40">
+ 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.
+ </doc>
+ <rule implement="MUST">
+ The client MUST open the context before doing any work on the
+ connection.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="open-ok"/>
+ <response name="redirect"/>
+ <field name="virtual host" domain="path">
+ virtual host name
+ <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/>
+ <doc>
+ The name of the virtual host to work with.
+ </doc>
+ <rule implement="MUST">
+ 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.
+ </rule>
+ <rule implement="SHOULD">
+ The server SHOULD verify that the client has permission to access
+ the specified virtual host.
+ </rule>
+ <rule implement="MAY">
+ The server MAY configure arbitrary limits per virtual host, such
+ as the number of each type of entity that may be used, per
+ connection and/or in total.
+ </rule>
+ </field>
+ <field name="capabilities" type="shortstr">
+ required capabilities
+ <doc>
+ The client may specify a number of 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" type="bit">
+ insist on connecting to server
+ <doc>
+ In a configuration with multiple load-sharing 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 implement="SHOULD">
+ When the client uses the insist option, the server SHOULD accept
+ the client connection unless it is technically unable to do so.
+ </rule>
+ </field>
+ </method>
+ <method name="open-ok" synchronous="1" index="41">
+ signal that the 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 name="redirect" synchronous="1" index="50">
+ asks the client to use a different server
+ <doc>
+ This method redirects the client to another server, based on the
+ requested virtual host and/or capabilities.
+ </doc>
+ <rule implement="SHOULD">
+ 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.
+ </rule>
+ <chassis name="client" implement="MAY"/>
+ <field name="host" type="shortstr">
+ 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 name="close" synchronous="1" index="60">
+ 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>
+ <rule implement="MUST">
+ After sending this method any received method except the Close-OK
+ method MUST be discarded.
+ </rule>
+ <rule implement="MAY">
+ The peer sending this method MAY use a counter or timeout to
+ detect failure of the other peer to respond correctly with
+ the Close-OK method.
+ </rule>
+ <rule implement="MUST">
+ When a server receives the Close method from a client it MUST
+ delete all server-side resources associated with the client's
+ context. A client CANNOT reconnect to a context after sending
+ or receiving a Close method.
+ </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">
+ 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="class id">
+ failing method ID
+ <doc>
+ When the close is provoked by a method exception, this is the
+ ID of the method.
+ </doc>
+ </field>
+ </method>
+ <method name="close-ok" synchronous="1" index="61">
+ 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 implement="SHOULD">
+ A peer that detects a socket closure without having received a
+ Close-Ok handshake method SHOULD log the error.
+ </rule>
+ <chassis name="client" implement="MUST"/>
+ <chassis name="server" implement="MUST"/>
+ </method>
+ </class>
+ <class name="channel" handler="channel" index="20">
+ <!--
+======================================================
+== CHANNEL
+======================================================
+-->
+ work with channels
+<doc>
+ The channel class provides methods for a client to establish a virtual
+ connection - a channel - to a server and for both peers to operate the
+ virtual connection thereafter.
+</doc>
+ <doc name="grammar">
+ channel = open-channel *use-channel close-channel
+ open-channel = C:OPEN S:OPEN-OK
+ use-channel = C:FLOW S:FLOW-OK
+ / S:FLOW C:FLOW-OK
+ / S:ALERT
+ / functional-class
+ close-channel = C:CLOSE S:CLOSE-OK
+ / S:CLOSE C:CLOSE-OK
+</doc>
+ <chassis name="server" implement="MUST"/>
+ <chassis name="client" implement="MUST"/>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="open" synchronous="1" index="10">
+ open a channel for use
+ <doc>
+ This method opens a virtual connection (a channel).
+ </doc>
+ <rule implement="MUST">
+ This method MUST NOT be called when the channel is already open.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="open-ok"/>
+ <field name="out of band" type="shortstr">
+ out-of-band settings
+ <doc>
+ Configures out-of-band transfers on this channel. The syntax and
+ meaning of this field will be formally defined at a later date.
+ </doc>
+ <assert check="null"/>
+ </field>
+ </method>
+ <method name="open-ok" synchronous="1" index="11">
+ signal that the channel is ready
+ <doc>
+ This method signals to the client that the channel is ready for use.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="flow" synchronous="1" index="20">
+ 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 oveflowing 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 request to
+ stop sending content should finish sending the current content, if
+ any, and then wait until it receives a Flow restart method.
+ </doc>
+ <rule implement="MAY">
+ When a new channel is opened, it is active. Some applications
+ assume that channels are inactive until started. To emulate this
+ behaviour a client MAY open the channel, then pause it.
+ </rule>
+ <rule implement="SHOULD">
+ When sending content data in multiple frames, a peer SHOULD monitor
+ the channel for incoming methods and respond to a Channel.Flow as
+ rapidly as possible.
+ </rule>
+ <rule implement="MAY">
+ A peer MAY use the Channel.Flow method to throttle incoming content
+ data for internal reasons, for example, when exchangeing data over a
+ slower connection.
+ </rule>
+ <rule implement="MAY">
+ The peer that requests a Channel.Flow method MAY disconnect and/or
+ ban a peer that does not respect the request.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <chassis name="client" implement="MUST"/>
+ <response name="flow-ok"/>
+ <field name="active" type="bit">
+ start/stop content frames
+ <doc>
+ If 1, the peer starts sending content frames. If 0, the peer
+ stops sending content frames.
+ </doc>
+ </field>
+ </method>
+ <method name="flow-ok" index="21">
+ 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" type="bit">
+ current flow setting
+ <doc>
+ Confirms the setting of the processed flow method: 1 means the
+ peer will start sending or continue to send content frames; 0
+ means it will not.
+ </doc>
+ </field>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="alert" index="30">
+ send a non-fatal warning message
+ <doc>
+ This method allows the server to send a non-fatal warning to the
+ client. This is used for methods that are normally asynchronous
+ and thus do not have confirmations, and for which the server may
+ detect errors that need to be reported. Fatal errors are handled
+ as channel or connection exceptions; non-fatal errors are sent
+ through this method.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ <field name="reply code" domain="reply code"/>
+ <field name="reply text" domain="reply text"/>
+ <field name="details" type="table">
+ detailed information for warning
+ <doc>
+ A set of fields that provide more information about the
+ problem. The meaning of these fields are defined on a
+ per-reply-code basis (TO BE DEFINED).
+ </doc>
+ </field>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="close" synchronous="1" index="40">
+ request a channel close
+ <doc>
+ This method indicates that the sender wants to close the channel.
+ 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>
+ <rule implement="MUST">
+ After sending this method any received method except
+ Channel.Close-OK MUST be discarded.
+ </rule>
+ <rule implement="MAY">
+ The peer sending this method MAY use a counter or timeout to detect
+ failure of the other peer to respond correctly with Channel.Close-OK..
+ </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">
+ 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">
+ failing method ID
+ <doc>
+ When the close is provoked by a method exception, this is the
+ ID of the method.
+ </doc>
+ </field>
+ </method>
+ <method name="close-ok" synchronous="1" index="41">
+ confirm a channel close
+ <doc>
+ This method confirms a Channel.Close method and tells the recipient
+ that it is safe to release resources for the channel and close the
+ socket.
+ </doc>
+ <rule implement="SHOULD">
+ A peer that detects a socket closure without having received a
+ Channel.Close-Ok handshake method SHOULD log the error.
+ </rule>
+ <chassis name="client" implement="MUST"/>
+ <chassis name="server" implement="MUST"/>
+ </method>
+ </class>
+ <class name="access" handler="connection" index="30">
+ <!--
+======================================================
+== ACCESS CONTROL
+======================================================
+-->
+ 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 name="grammar">
+ access = C:REQUEST S:REQUEST-OK
+</doc>
+ <chassis name="server" implement="MUST"/>
+ <chassis name="client" implement="MUST"/>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="request" synchronous="1" index="10">
+ 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-channel resource.
+ </doc>
+ <rule implement="MUST">
+ The realm name MUST start with either "/data" (for application
+ resources) or "/admin" (for server administration resources).
+ If the realm starts with any other path, the server MUST raise
+ a connection exception with reply code 403 (access refused).
+ </rule>
+ <rule implement="MUST">
+ The server MUST implement the /data realm and MAY implement the
+ /admin realm. The mapping of resources to realms is not
+ defined in the protocol - this is a server-side configuration
+ issue.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="request-ok"/>
+ <field name="realm" domain="path">
+ name of requested realm
+ <rule implement="MUST">
+ If the specified realm is not known to the server, the server
+ must raise a channel exception with reply code 402 (invalid
+ path).
+ </rule>
+ </field>
+ <field name="exclusive" type="bit">
+ request exclusive access
+ <doc>
+ Request exclusive access to the realm. If the server cannot grant
+ this - because there are other active tickets for the realm - it
+ raises a channel exception.
+ </doc>
+ </field>
+ <field name="passive" type="bit">
+ 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" type="bit">
+ request active access
+ <doc>
+ Request message active access to the specified access realm.
+ Acvtive access lets a client get create and delete resources in
+ the realm.
+ </doc>
+ </field>
+ <field name="write" type="bit">
+ 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" type="bit">
+ 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 name="request-ok" synchronous="1" index="11">
+ grant access to server resources
+ <doc>
+ This method provides the client with an access ticket. The access
+ ticket is valid within the current channel and for the lifespan of
+ the channel.
+ </doc>
+ <rule implement="MUST">
+ The client MUST NOT use access tickets except within the same
+ channel as originally granted.
+ </rule>
+ <rule implement="MUST">
+ The server MUST isolate access tickets per channel and treat an
+ attempt by a client to mix these as a connection exception.
+ </rule>
+ <chassis name="client" implement="MUST"/>
+ <field name="ticket" domain="access ticket"/>
+ </method>
+ </class>
+ <class name="exchange" handler="channel" index="40">
+ <!--
+======================================================
+== EXCHANGES (or "routers", if you prefer)
+== (Or matchers, plugins, extensions, agents,... Routing is just one of
+== the many fun things an exchange can do.)
+======================================================
+-->
+ work with exchanges
+<doc>
+ Exchanges match and distribute messages across queues. Exchanges can be
+ configured in the server or created at runtime.
+</doc>
+ <doc name="grammar">
+ exchange = C:DECLARE S:DECLARE-OK
+ / C:DELETE S:DELETE-OK
+</doc>
+ <chassis name="server" implement="MUST"/>
+ <chassis name="client" implement="MUST"/>
+ <rule implement="MUST">
+ <test>amq_exchange_19</test>
+ The server MUST implement the direct and fanout exchange types, and
+ predeclare the corresponding exchanges named amq.direct and amq.fanout
+ in each virtual host. The server MUST also predeclare a direct
+ exchange to act as the default exchange for content Publish methods
+ and for default queue bindings.
+</rule>
+ <rule implement="SHOULD">
+ <test>amq_exchange_20</test>
+ The server SHOULD implement the topic exchange type, and predeclare
+ the corresponding exchange named amq.topic in each virtual host.
+</rule>
+ <rule implement="MAY">
+ <test>amq_exchange_21</test>
+ The server MAY implement the system exchange type, and predeclare the
+ corresponding exchanges named amq.system in each virtual host. If the
+ client attempts to bind a queue to the system exchange, the server
+ MUST raise a connection exception with reply code 507 (not allowed).
+</rule>
+ <rule implement="MUST">
+ <test>amq_exchange_22</test>
+ The default exchange MUST be defined as internal, and be inaccessible
+ to the client except by specifying an empty exchange name in a content
+ Publish method. That is, the server MUST NOT let clients make explicit
+ bindings to this exchange.
+</rule>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="declare" synchronous="1" index="10">
+ declare exchange, 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 implement="SHOULD">
+ <test>amq_exchange_23</test>
+ The server SHOULD support a minimum of 16 exchanges per virtual host
+ and ideally, impose no limit except as defined by available resources.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="declare-ok"/>
+ <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 implement="MUST">
+ 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.
+ </rule>
+ </field>
+ <field name="exchange" domain="exchange name">
+ <rule implement="MUST">
+ <test>amq_exchange_15</test>
+ Exchange names starting with "amq." are reserved for predeclared
+ and standardised exchanges. If the client attempts to create an
+ exchange starting with "amq.", the server MUST raise a channel
+ exception with reply code 403 (access refused).
+ </rule>
+ <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/>
+ </field>
+ <field name="type" type="shortstr">
+ exchange type
+ <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>
+ <rule implement="MUST">
+ <test>amq_exchange_16</test>
+ If the exchange already exists with a different type, the server
+ MUST raise a connection exception with a reply code 507 (not allowed).
+ </rule>
+ <rule implement="MUST">
+ <test>amq_exchange_18</test>
+ If the server does not support the requested exchange type it MUST
+ raise a connection exception with a reply code 503 (command invalid).
+ </rule>
+ <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/>
+ </field>
+ <field name="passive" type="bit">
+ 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>
+ <rule implement="MUST">
+ <test>amq_exchange_05</test>
+ If set, and the exchange does not already exist, the server MUST
+ raise a channel exception with reply code 404 (not found).
+ </rule>
+ </field>
+ <field name="durable" type="bit">
+ 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 implement="MUST">
+ <test>amq_exchange_24</test>
+ The server MUST support both durable and transient exchanges.
+ </rule>
+ <rule implement="MUST">
+ The server MUST ignore the durable field if the exchange already
+ exists.
+ </rule>
+ </field>
+ <field name="auto delete" type="bit">
+ auto-delete when unused
+ <doc>
+ If set, the exchange is deleted when all queues have finished
+ using it.
+ </doc>
+ <rule implement="SHOULD">
+ <test>amq_exchange_02</test>
+ The server SHOULD allow for a reasonable delay between the point
+ when it determines that an exchange is not being used (or no longer
+ used), and the point when it deletes the exchange. At the least it
+ must allow a client to create an exchange and then bind a queue to
+ it, with a small but non-zero delay between these two actions.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_exchange_25</test>
+ The server MUST ignore the auto-delete field if the exchange already
+ exists.
+ </rule>
+ </field>
+ <field name="internal" type="bit">
+ create internal exchange
+ <doc>
+ If set, the exchange may not be used directly by publishers, but
+ only when bound to other exchanges. Internal exchanges are used to
+ construct wiring that is not visible to applications.
+ </doc>
+ </field>
+
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+
+ <field name="arguments" type="table">
+ 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>
+ </field>
+ </method>
+ <method name="declare-ok" synchronous="1" index="11">
+ confirms an exchange declaration
+ <doc>
+ This method confirms a Declare method and confirms the name of the
+ exchange, essential for automatically-named exchanges.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="delete" synchronous="1" index="20">
+ delete an exchange
+ <doc>
+ This method deletes an exchange. When an exchange is deleted all queue
+ bindings on the exchange are cancelled.
+ </doc>
+ <chassis name="server" implement="MUST"/>
+ <response name="delete-ok"/>
+ <field name="ticket" domain="access ticket">
+ <rule implement="MUST">
+ The client MUST provide a valid access ticket giving "active"
+ access rights to the exchange's access realm.
+ </rule>
+ </field>
+ <field name="exchange" domain="exchange name">
+ <rule implement="MUST">
+ <test>amq_exchange_11</test>
+ The exchange MUST exist. Attempting to delete a non-existing exchange
+ causes a channel exception.
+ </rule>
+ <assert check="notnull"/>
+ </field>
+ <field name="if unused" type="bit">
+ 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 a channel exception instead.
+ </doc>
+ <rule implement="SHOULD">
+ <test>amq_exchange_12</test>
+ If set, the server SHOULD delete the exchange but only if it has
+ no queue bindings.
+ </rule>
+ <rule implement="SHOULD">
+ <test>amq_exchange_13</test>
+ If set, the server SHOULD raise a channel exception if the exchange is in
+ use.
+ </rule>
+ </field>
+
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+
+ </method>
+ <method name="delete-ok" synchronous="1" index="21">
+ confirm deletion of an exchange
+ <doc>
+ This method confirms the deletion of an exchange.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ </method>
+ </class>
+ <class name="queue" handler="channel" index="50">
+ <!--
+======================================================
+== QUEUES
+======================================================
+-->
+ 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 name="grammar">
+ queue = C:DECLARE S:DECLARE-OK
+ / C:BIND S:BIND-OK
+ / C:PURGE S:PURGE-OK
+ / C:DELETE S:DELETE-OK
+</doc>
+ <chassis name="server" implement="MUST"/>
+ <chassis name="client" implement="MUST"/>
+ <rule implement="MUST">
+ <test>amq_queue_33</test>
+ A server MUST allow any content class to be sent to any queue, in any
+ mix, and queue and delivery these content classes independently. Note
+ that all methods that fetch content off queues are specific to a given
+ content class.
+</rule>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="declare" synchronous="1" index="10">
+ declare queue, create if needed
+ <doc>
+ This method 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 implement="MUST">
+ <test>amq_queue_34</test>
+ The server MUST create a default binding for a newly-created queue
+ to the default exchange, which is an exchange of type 'direct'.
+ </rule>
+ <rule implement="SHOULD">
+ <test>amq_queue_35</test>
+ The server SHOULD support a minimum of 256 queues per virtual host
+ and ideally, impose no limit except as defined by available resources.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="declare-ok"/>
+ <field name="ticket" domain="access ticket">
+ <doc>
+ When a client defines a new queue, this belongs to the access realm
+ of the ticket used. All further work done with that queue must be
+ done with an access ticket for the same realm.
+ </doc>
+ <doc>
+ The client provides a valid access ticket giving "active" access
+ to the realm in which the queue exists or will be created, or
+ "passive" access if the if-exists flag is set.
+ </doc>
+ </field>
+ <field name="queue" domain="queue name">
+ <rule implement="MAY">
+ <test>amq_queue_10</test>
+ The queue name MAY be empty, in which case the server MUST create
+ a new queue with a unique generated name and return this to the
+ client in the Declare-Ok method.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_32</test>
+ Queue names starting with "amq." are reserved for predeclared and
+ standardised server queues. If the queue name starts with "amq."
+ and the passive option is zero, the server MUST raise a connection
+ exception with reply code 403 (access refused).
+ </rule>
+ <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/>
+ </field>
+ <field name="passive" type="bit">
+ do not create queue
+ <doc>
+ If set, the server will not create the queue. The client can use
+ this to check whether a queue exists without modifying the server
+ state.
+ </doc>
+ <rule implement="MUST">
+ <test>amq_queue_05</test>
+ If set, and the queue does not already exist, the server MUST
+ respond with a reply code 404 (not found) and raise a channel
+ exception.
+ </rule>
+ </field>
+ <field name="durable" type="bit">
+ 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 implement="MUST">
+ <test>amq_queue_03</test>
+ The server MUST recreate the durable queue after a restart.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_36</test>
+ The server MUST support both durable and transient queues.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_37</test>
+ The server MUST ignore the durable field if the queue already
+ exists.
+ </rule>
+ </field>
+ <field name="exclusive" type="bit">
+ request an exclusive queue
+ <doc>
+ Exclusive queues may only be consumed from by the current connection.
+ Setting the 'exclusive' flag always implies 'auto-delete'.
+ </doc>
+ <rule implement="MUST">
+ <test>amq_queue_38</test>
+ The server MUST support both exclusive (private) and non-exclusive
+ (shared) queues.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_04</test>
+ The server MUST raise a channel exception if 'exclusive' is specified
+ and the queue already exists and is owned by a different connection.
+ </rule>
+ </field>
+ <field name="auto delete" type="bit">
+ auto-delete queue when unused
+ <doc>
+ If set, the queue is deleted when all consumers have finished
+ using it. Last consumer can be cancelled either explicitly or because
+ its channel is closed. If there was no consumer ever on the queue, it
+ won't be deleted.
+ </doc>
+ <rule implement="SHOULD">
+ <test>amq_queue_02</test>
+ The server SHOULD allow for a reasonable delay between the point
+ when it determines that a queue is not being used (or no longer
+ used), and the point when it deletes the queue. At the least it
+ must allow a client to create a queue and then create a consumer
+ to read from it, with a small but non-zero delay between these
+ two actions. The server should equally allow for clients that may
+ be disconnected prematurely, and wish to re-consume from the same
+ queue without losing messages. We would recommend a configurable
+ timeout, with a suitable default value being one minute.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_31</test>
+ The server MUST ignore the auto-delete field if the queue already
+ exists.
+ </rule>
+ </field>
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+
+ <field name="arguments" type="table">
+ 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>
+ </field>
+ </method>
+ <method name="declare-ok" synchronous="1" index="11">
+ confirms a queue definition
+ <doc>
+ This method confirms a Declare method and confirms the name of the
+ queue, essential for automatically-named queues.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ <field name="queue" domain="queue name">
+ <doc>
+ Reports the name of the queue. If the server generated a queue
+ name, this field contains that name.
+ </doc>
+ <assert check="notnull"/>
+ </field>
+ <field name="message count" type="long">
+ number of messages in queue
+ <doc>
+ Reports the number of messages in the queue, which will be zero
+ for newly-created queues.
+ </doc>
+ </field>
+ <field name="consumer count" type="long">
+ number of consumers
+ <doc>
+ Reports the number of active consumers for the queue. Note that
+ consumers can suspend activity (Channel.Flow) in which case they
+ do not appear in this count.
+ </doc>
+ </field>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="bind" synchronous="1" index="20">
+ bind queue to an exchange
+ <doc>
+ This method 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 dest exchange
+ and subscription queues are bound to a dest_wild exchange.
+ </doc>
+ <rule implement="MUST">
+ <test>amq_queue_25</test>
+ A server MUST allow ignore duplicate bindings - that is, two or
+ more bind methods for a specific queue, with identical arguments
+ - without treating these as an error.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_39</test>
+ If a bind fails, the server MUST raise a connection exception.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_12</test>
+ The server MUST NOT allow a durable queue to bind to a transient
+ exchange. If the client attempts this the server MUST raise a
+ channel exception.
+ </rule>
+ <rule implement="SHOULD">
+ <test>amq_queue_13</test>
+ Bindings for durable queues are automatically durable and the
+ server SHOULD restore such bindings after a server restart.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_17</test>
+ If the client attempts to an exchange that was declared as internal,
+ the server MUST raise a connection exception with reply code 530
+ (not allowed).
+ </rule>
+ <rule implement="SHOULD">
+ <test>amq_queue_40</test>
+ The server SHOULD support at least 4 bindings per queue, and
+ ideally, impose no limit except as defined by available resources.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="bind-ok"/>
+ <field name="ticket" domain="access ticket">
+ <doc>
+ The client provides a valid access ticket giving "active"
+ access rights to the queue's access realm.
+ </doc>
+ </field>
+
+ <field name = "queue" domain = "queue name">
+ <doc>
+ Specifies the name of the queue to bind. If the queue name is
+ empty, refers to the current queue for the channel, which is
+ the last declared queue.
+ </doc>
+ <doc name = "rule">
+ If the client did not previously declare a queue, and the queue
+ name in this method is empty, the server MUST raise a connection
+ exception with reply code 530 (not allowed).
+ </doc>
+ <doc name = "rule" test = "amq_queue_26">
+ If the queue does not exist the server MUST raise a channel exception
+ with reply code 404 (not found).
+ </doc>
+ </field>
+
+ <field name="exchange" domain="exchange name">
+ The name of the exchange to bind to.
+ <rule implement="MUST">
+ <test>amq_queue_14</test>
+ If the exchange does not exist the server MUST raise a channel
+ exception with reply code 404 (not found).
+ </rule>
+ </field>
+ <field name="routing key" type="shortstr">
+ message routing key
+ <doc>
+ Specifies the routing key for the binding. The routing key is
+ used for routing messages depending on the exchange configuration.
+ Not all exchanges use a routing key - refer to the specific
+ exchange documentation. If the routing key is empty and the queue
+ name is empty, the routing key will be the current queue for the
+ channel, which is the last declared queue.
+ </doc>
+ </field>
+
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+
+ <field name="arguments" type="table">
+ arguments for binding
+ <doc>
+ A set of arguments for the binding. The syntax and semantics of
+ these arguments depends on the exchange class.
+ </doc>
+ </field>
+ </method>
+ <method name="bind-ok" synchronous="1" index="21">
+ confirm bind successful
+ <doc>
+ This method confirms that the bind was successful.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="purge" synchronous="1" index="30">
+ purge a queue
+ <doc>
+ This method removes all messages from a queue. It does not cancel
+ consumers. Purged messages are deleted without any formal "undo"
+ mechanism.
+ </doc>
+ <rule implement="MUST">
+ <test>amq_queue_15</test>
+ A call to purge MUST result in an empty queue.
+ </rule>
+ <rule implement="MUST">
+ <test>amq_queue_41</test>
+ On transacted channels the server MUST not purge messages that have
+ already been sent to a client but not yet acknowledged.
+ </rule>
+ <rule implement="MAY">
+ <test>amq_queue_42</test>
+ 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.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="purge-ok"/>
+ <field name="ticket" domain="access ticket">
+ <doc>
+ The access ticket must be for the access realm that holds the
+ queue.
+ </doc>
+ <rule implement="MUST">
+ The client MUST provide a valid access ticket giving "read" access
+ rights to the queue's access realm. Note that purging a queue is
+ equivalent to reading all messages and discarding them.
+ </rule>
+ </field>
+ <field name = "queue" domain = "queue name">
+ <doc>
+ Specifies the name of the queue to purge. If the queue name is
+ empty, refers to the current queue for the channel, which is
+ the last declared queue.
+ </doc>
+ <doc name = "rule">
+ If the client did not previously declare a queue, and the queue
+ name in this method is empty, the server MUST raise a connection
+ exception with reply code 530 (not allowed).
+ </doc>
+ <doc name = "rule" test = "amq_queue_16">
+ The queue must exist. Attempting to purge a non-existing queue
+ causes a channel exception.
+ </doc>
+ </field>
+
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+ </method>
+ <method name="purge-ok" synchronous="1" index="31">
+ confirms a queue purge
+ <doc>
+ This method confirms the purge of a queue.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ <field name="message count" type="long">
+ number of messages purged
+ <doc>
+ Reports the number of messages purged.
+ </doc>
+ </field>
+ </method>
+ <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+ <method name="delete" synchronous="1" index="40">
+ delete a queue
+ <doc>
+ This method deletes a queue. When a queue is deleted any pending
+ messages are sent to a dead-letter queue if this is defined in the
+ server configuration, and all consumers on the queue are cancelled.
+ </doc>
+ <rule implement="SHOULD">
+ <test>amq_queue_43</test>
+ The server SHOULD use a dead-letter queue to hold messages that
+ were pending on a deleted queue, and MAY provide facilities for
+ a system administrator to move these messages back to an active
+ queue.
+ </rule>
+ <chassis name="server" implement="MUST"/>
+ <response name="delete-ok"/>
+ <field name="ticket" domain="access ticket">
+ <doc>
+ The client provides a valid access ticket giving "active"
+ access rights to the queue's access realm.
+ </doc>
+ </field>
+
+ <field name = "queue" domain = "queue name">
+ <doc>
+ Specifies the name of the queue to delete. If the queue name is
+ empty, refers to the current queue for the channel, which is the
+ last declared queue.
+ </doc>
+ <doc name = "rule">
+ If the client did not previously declare a queue, and the queue
+ name in this method is empty, the server MUST raise a connection
+ exception with reply code 530 (not allowed).
+ </doc>
+ <doc name = "rule" test = "amq_queue_21">
+ The queue must exist. Attempting to delete a non-existing queue
+ causes a channel exception.
+ </doc>
+ </field>
+
+ <field name="if unused" type="bit">
+ 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 a channel exception instead.
+ </doc>
+ <rule implement="MUST">
+ <test>amq_queue_29</test>
+ <test>amq_queue_30</test>
+ The server MUST respect the if-unused flag when deleting a queue.
+ </rule>
+ </field>
+ <field name="if empty" type="bit">
+ delete only if empty
+ <test>amq_queue_27</test>
+ <doc>
+ If set, the server will only delete the queue if it has no
+ messages. If the queue is not empty the server raises a channel
+ exception.
+ </doc>
+ </field>
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+ </method>
+
+ <method name="delete-ok" synchronous="1" index="41">
+ confirm deletion of a queue
+ <doc>
+ This method confirms the deletion of a queue.
+ </doc>
+ <chassis name="client" implement="MUST"/>
+ <field name="message count" type="long">
+ number of messages purged
+ <doc>
+ Reports the number of messages purged.
+ </doc>
+ </field>
+ </method>
+ </class>
+ <class name="basic" handler="channel" index="60">
+ <!--
+======================================================
+== BASIC MIDDLEWARE
+======================================================
+-->
+ work with basic content
+<doc>
+ The Basic class provides methods that support an industry-standard
+ messaging model.
+</doc>
+
+<doc name = "grammar">
+ basic = C:QOS S:QOS-OK
+ / C:CONSUME S:CONSUME-OK
+ / C:CANCEL S:CANCEL-OK
+ / C:PUBLISH content
+ / S:RETURN content
+ / S:DELIVER content
+ / C:GET ( S:GET-OK content / S:GET-EMPTY )
+ / C:ACK
+ / C:REJECT
+</doc>
+
+<chassis name = "server" implement = "MUST" />
+<chassis name = "client" implement = "MAY" />
+
+<doc name = "rule" test = "amq_basic_08">
+ The server SHOULD respect the persistent property of basic messages
+ and SHOULD make a best-effort to hold persistent basic messages on a
+ reliable storage mechanism.
+</doc>
+<doc name = "rule" test = "amq_basic_09">
+ The server MUST NOT discard a persistent basic message in case of a
+ queue overflow. The server MAY use the Channel.Flow method to slow
+ or stop a basic message publisher when necessary.
+</doc>
+<doc name = "rule" test = "amq_basic_10">
+ The server MAY overflow non-persistent basic messages to persistent
+ storage and MAY discard or dead-letter non-persistent basic messages
+ on a priority basis if the queue size exceeds some configured limit.
+</doc>
+<doc name = "rule" test = "amq_basic_11">
+ The server MUST implement at least 2 priority levels for basic
+ messages, where priorities 0-4 and 5-9 are treated as two distinct
+ levels. The server MAY implement up to 10 priority levels.
+</doc>
+<doc name = "rule" test = "amq_basic_12">
+ The server MUST deliver messages of the same priority in order
+ irrespective of their individual persistence.
+</doc>
+<doc name = "rule" test = "amq_basic_13">
+ The server MUST support both automatic and explicit acknowledgements
+ on Basic content.
+</doc>
+
+<!-- These are the properties for a Basic content -->
+
+<field name = "content type" type = "shortstr">
+ MIME content type
+</field>
+<field name = "content encoding" type = "shortstr">
+ MIME content encoding
+</field>
+<field name = "headers" type = "table">
+ Message header field table
+</field>
+<field name = "delivery mode" type = "octet">
+ Non-persistent (1) or persistent (2)
+</field>
+<field name = "priority" type = "octet">
+ The message priority, 0 to 9
+</field>
+<field name = "correlation id" type = "shortstr">
+ The application correlation identifier
+</field>
+<field name = "reply to" type = "shortstr">
+ The destination to reply to
+</field>
+<field name = "expiration" type = "shortstr">
+ Message expiration specification
+</field>
+<field name = "message id" type = "shortstr">
+ The application message identifier
+</field>
+<field name = "timestamp" type = "timestamp">
+ The message timestamp
+</field>
+<field name = "type" type = "shortstr">
+ The message type name
+</field>
+<field name = "user id" type = "shortstr">
+ The creating user id
+</field>
+<field name = "app id" type = "shortstr">
+ The creating application id
+</field>
+<field name = "cluster id" type = "shortstr">
+ Intra-cluster routing identifier
+</field>
+
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<method name = "qos" synchronous = "1" index = "10">
+ specify quality of service
+ <doc>
+ This method requests a specific quality of service. The QoS can
+ be specified for the current channel or for all channels on the
+ connection. The particular properties and semantics of a qos method
+ always depend on the content class semantics. Though the qos method
+ could in principle apply to both peers, it is currently meaningful
+ only for the server.
+ </doc>
+ <chassis name = "server" implement = "MUST" />
+ <response name = "qos-ok" />
+
+ <field name = "prefetch size" type = "long">
+ prefetch window in octets
+ <doc>
+ The client can request that messages be sent in advance so that
+ when the client finishes processing a message, the following
+ message is already held locally, rather than needing to be sent
+ down the channel. Prefetching gives a performance improvement.
+ This field specifies the prefetch window size in octets. The
+ server will send a message in advance if it is equal to or
+ smaller in size than the available prefetch size (and also falls
+ into other prefetch limits). May be set to zero, meaning "no
+ specific limit", although other prefetch limits may still apply.
+ The prefetch-size is ignored if the no-ack option is set.
+ </doc>
+ <doc name = "rule" test = "amq_basic_17">
+ The server MUST ignore this setting when the client is not
+ processing any messages - i.e. the prefetch size does not limit
+ the transfer of single messages to a client, only the sending in
+ advance of more messages while the client still has one or more
+ unacknowledged messages.
+ </doc>
+ </field>
+
+ <field name = "prefetch count" type = "short">
+ prefetch window in messages
+ <doc>
+ Specifies a prefetch window in terms of whole messages. This
+ field may be used in combination with the prefetch-size field;
+ a message will only be sent in advance if both prefetch windows
+ (and those at the channel and connection level) allow it.
+ The prefetch-count is ignored if the no-ack option is set.
+ </doc>
+ <doc name = "rule" test = "amq_basic_18">
+ The server MAY send less data in advance than allowed by the
+ client's specified prefetch windows but it MUST NOT send more.
+ </doc>
+ </field>
+
+ <field name = "global" type = "bit">
+ apply to entire connection
+ <doc>
+ By default the QoS settings apply to the current channel only. If
+ this field is set, they are applied to the entire connection.
+ </doc>
+ </field>
+</method>
+
+<method name = "qos-ok" synchronous = "1" index = "11">
+ confirm the requested qos
+ <doc>
+ This method tells the client that the requested QoS levels could
+ be handled by the server. The requested QoS applies to all active
+ consumers until a new QoS is defined.
+ </doc>
+ <chassis name = "client" implement = "MUST" />
+</method>
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<method name = "consume" synchronous = "1" index = "20">
+ start a queue consumer
+ <doc>
+ This method asks the server to start a "consumer", which is a
+ transient request for messages from a specific queue. Consumers
+ last as long as the channel they were created on, or until the
+ client cancels them.
+ </doc>
+ <doc name = "rule" test = "amq_basic_01">
+ The server SHOULD support at least 16 consumers per queue, unless
+ the queue was declared as private, and ideally, impose no limit
+ except as defined by available resources.
+ </doc>
+ <chassis name = "server" implement = "MUST" />
+ <response name = "consume-ok" />
+
+ <field name = "ticket" domain = "access ticket">
+ <doc name = "rule">
+ The client MUST provide a valid access ticket giving "read" access
+ rights to the realm for the queue.
+ </doc>
+ </field>
+
+ <field name = "queue" domain = "queue name">
+ <doc>
+ Specifies the name of the queue to consume from. If the queue name
+ is null, refers to the current queue for the channel, which is the
+ last declared queue.
+ </doc>
+ <doc name = "rule">
+ If the client did not previously declare a queue, and the queue name
+ in this method is empty, the server MUST raise a connection exception
+ with reply code 530 (not allowed).
+ </doc>
+ </field>
+
+ <field name = "consumer tag" domain = "consumer tag">
+ <doc>
+ Specifies the identifier for the consumer. The consumer tag is
+ local to a connection, so two clients can use the same consumer
+ tags. If this field is empty the server will generate a unique
+ tag.
+ </doc>
+ <doc name = "rule" test = "todo">
+ The tag MUST NOT refer to an existing consumer. If the client
+ attempts to create two consumers with the same non-empty tag
+ the server MUST raise a connection exception with reply code
+ 530 (not allowed).
+ </doc>
+ </field>
+
+ <field name = "no local" domain = "no local" />
+
+ <field name = "no ack" domain = "no ack" />
+
+ <field name = "exclusive" type = "bit">
+ request exclusive access
+ <doc>
+ Request exclusive consumer access, meaning only this consumer can
+ access the queue.
+ </doc>
+ <doc name = "rule" test = "amq_basic_02">
+ If the server cannot grant exclusive access to the queue when asked,
+ - because there are other consumers active - it MUST raise a channel
+ exception with return code 403 (access refused).
+ </doc>
+ </field>
+
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+</method>
+
+<method name = "consume-ok" synchronous = "1" index = "21">
+ confirm a new consumer
+ <doc>
+ The server provides the client with a consumer tag, which is used
+ by the client for methods called on the consumer at a later stage.
+ </doc>
+ <chassis name = "client" implement = "MUST" />
+
+ <field name = "consumer tag" domain = "consumer tag">
+ <doc>
+ Holds the consumer tag specified by the client or provided by
+ the server.
+ </doc>
+ </field>
+</method>
+
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<method name = "cancel" synchronous = "1" index = "30">
+ end a queue consumer
+ <doc test = "amq_basic_04">
+ This method cancels a consumer. This does not affect already
+ delivered messages, but it does mean the server will not send any
+ more messages for that consumer. The client may receive an
+ abitrary number of messages in between sending the cancel method
+ and receiving the cancel-ok reply.
+ </doc>
+ <doc name = "rule" test = "todo">
+ If the queue no longer exists when the client sends a cancel command,
+ or the consumer has been cancelled for other reasons, this command
+ has no effect.
+ </doc>
+ <chassis name = "server" implement = "MUST" />
+ <response name = "cancel-ok" />
+
+ <field name = "consumer tag" domain = "consumer tag" />
+
+ <field name = "nowait" type = "bit">
+ do not send a reply method
+ <doc>
+ If set, the server will not respond to the method. The client should
+ not wait for a reply method. If the server could not complete the
+ method it will raise a channel or connection exception.
+ </doc>
+ </field>
+</method>
+
+<method name = "cancel-ok" synchronous = "1" index = "31">
+ confirm a cancelled consumer
+ <doc>
+ This method confirms that the cancellation was completed.
+ </doc>
+ <chassis name = "client" implement = "MUST" />
+
+ <field name = "consumer tag" domain = "consumer tag" />
+</method>
+
+
+<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+<method name = "publish" content = "1" index = "40">
+ publish a message
+ <doc>
+ This method publishes a message to a specific exchange. The message
+ will be routed to queues as defined by the exchange configuration
+ and distributed to any active consumers when the transaction, if any,
+ is committed.
+ </doc>
+ <chassis name = "server" implement = "MUST" />
+
+ <field name = "ticket" domain = "access ticket">
+ <doc name = "rule">
+ The client MUST provide a valid access ticket giving "write"
+ access rights to the access realm for the exchange.
+ </doc>
+ </field>
+
+ <field name = "exchange" domain = "exchange name">
+ <doc>
+ Specifies the name of the exchange to publish to. The exchange
+ name can be empty, meaning the default exchange. If the exchange
+ name is specified, and that exchange does not exist, the server
+ will raise a channel exception.
+ </doc>
+ <doc name = "rule" test = "amq_basic_06">
+ The server MUST accept a blank exchange name to mean the default
+ exchange.
+ </doc>
+ <doc name = "rule" test = "amq_basic_14">
+ If the exchange was declared as an internal exchange, the server
+ MUST raise a channel exception with a reply code 403 (access
+ refused).
+ </doc>
+ <doc name = "rule" test = "amq_basic_15">
+ The exchange MAY refuse basic content in which case it MUST raise
+ a channel exception with reply code 540 (not implemented).
+ </doc>
+ </field>
+
+ <field name = "routing key" type = "shortstr">
+ Message routing key
+ <doc>
+ Specifies the routing key for the message. The routing key is
+ used for routing messages depending on the exchange configuration.
+ </doc>
+ </field>
+
+ <field name = "mandatory" type = "bit">
+ indicate mandatory routing
+ <doc>
+ This flag tells the server how to react if the message cannot be
+ routed to a queue. If this flag is set, the server will return an
+ unroutable message with a Return method. If this flag is zero, the
+ server silently drops the message.
+ </doc>
+ <doc name = "rule" test = "amq_basic_07">
+ The server SHOULD implement the mandatory flag.
+ </doc>
+ </field>
+
+ <field name = "immediate" type = "bit">
+ request immediate delivery
+ <doc>
+ This flag tells the server how to react if the message cannot be
+ routed to a queue consumer immediately. If this flag is set, the
+ server will return an undeliverable message with a Return method.
+ If this flag is zero, the server will queue the message, but with
+ no guarantee that it will ever be consumed.
+ </doc>
+ <doc name = "rule" test = "amq_basic_16">
+ The server SHOULD implement the immediate flag.
+ </doc>
+ </field>
+</method>
+
+<method name = "return" content = "1" index = "50">
+ return a failed message
+ <doc>
[... 1732 lines stripped ...]