amqp-0.8.xml

<?xml version="1.0"?>

<!--
Copyright Notice
================
© Copyright JPMorgan Chase Bank, Cisco Systems, Inc., Envoy Technologies Inc.,
iMatix Corporation, IONA� Technologies, Red Hat, Inc.,
TWIST Process Innovations, and 29West Inc. 2006. All rights reserved.

License
=======
JPMorgan Chase Bank, 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, 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

-->

<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>
    This method returns an undeliverable message that was published
    with the "immediate" flag set, or an unroutable message published
    with the "mandatory" flag set. The reply code and text provide
    information about the reason that the message was undeliverable.
  </doc>
  <chassis name = "client" implement = "MUST" />

  <field name = "reply code" domain = "reply code" />
  <field name = "reply text" domain = "reply text" />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was
      originally published to.
    </doc>
  </field>

  <field name = "routing key" type = "shortstr">
     Message routing key
    <doc>
      Specifies the routing key name specified when the message was
      published.
    </doc>
  </field>
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "deliver" content = "1" index = "60">
  notify the client of a consumer message
  <doc>
    This method delivers a message to the client, via a consumer.  In
    the asynchronous message delivery model, the client starts a
    consumer using the Consume method, then the server responds with
    Deliver methods as and when messages arrive for that consumer.
  </doc>
  <doc name = "rule" test = "amq_basic_19">
    The server SHOULD track the number of times a message has been
    delivered to clients and when a message is redelivered a certain
    number of times - e.g. 5 times - without being acknowledged, the
    server SHOULD consider the message to be unprocessable (possibly
    causing client applications to abort), and move the message to a
    dead letter queue.
  </doc>
  <chassis name = "client" implement = "MUST" />

  <field name = "consumer tag" domain = "consumer tag" />

  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "redelivered" domain = "redelivered" />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was
      originally published to.
    </doc>
  </field>

  <field name = "routing key" type = "shortstr">
     Message routing key
    <doc>
      Specifies the routing key name specified when the message was
      published.
    </doc>
  </field>
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "get" synchronous = "1" index = "70">
  direct access to a queue
  <doc>
    This method provides a direct access to the messages in a queue
    using a synchronous dialogue that is designed for specific types of
    application where synchronous functionality is more important than
    performance.
  </doc>
  <response name = "get-ok" />
  <response name = "get-empty" />
  <chassis name = "server" implement = "MUST" />

  <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 = "no ack" domain = "no ack" />
</method>

<method name = "get-ok" synchronous = "1" content = "1" index = "71">
  provide client with a message
  <doc>
    This method delivers a message to the client following a get
    method.  A message delivered by 'get-ok' must be acknowledged
    unless the no-ack option was set in the get method.
  </doc>
  <chassis name = "client" implement = "MAY" />

  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "redelivered"  domain = "redelivered"  />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was originally
      published to.  If empty, the message was published to the default
      exchange.
    </doc>
  </field>

  <field name = "routing key" type = "shortstr">
     Message routing key
    <doc>
      Specifies the routing key name specified when the message was
      published.
    </doc>
  </field>

  <field name = "message count" type = "long" >
    number of messages pending
    <doc>
      This field reports the number of messages pending on the queue,
      excluding the message being delivered.  Note that this figure is
      indicative, not reliable, and can change arbitrarily as messages
      are added to the queue and removed by other clients.
    </doc>
  </field>
</method>


<method name = "get-empty" synchronous = "1" index = "72">
  indicate no messages available
  <doc>
    This method tells the client that the queue has no messages
    available for the client.
  </doc>
  <chassis name = "client" implement = "MAY" />

  <field name = "cluster id" type = "shortstr">
     Cluster id
    <doc>
      For use by cluster applications, should not be used by
      client applications.
    </doc>
  </field>
</method>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "ack" index = "80">
  acknowledge one or more messages
  <doc>
    This method acknowledges one or more messages delivered via the
    Deliver or Get-Ok methods.  The client can ask to confirm a
    single message or a set of messages up to and including a specific
    message.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "multiple" type = "bit">
    acknowledge multiple messages
    <doc>
      If set to 1, the delivery tag is treated as "up to and including",
      so that the client can acknowledge multiple messages with a single
      method.  If set to zero, the delivery tag refers to a single
      message.  If the multiple field is 1, and the delivery tag is zero,
      tells the server to acknowledge all outstanding mesages.
    </doc>
    <doc name = "rule" test = "amq_basic_20">
      The server MUST validate that a non-zero delivery-tag refers to an
      delivered message, and raise a channel exception if this is not the
      case.
    </doc>
  </field>
</method>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "reject" index = "90">
  reject an incoming message
  <doc>
    This method allows a client to reject a message.  It can be used to
    interrupt and cancel large incoming messages, or return untreatable
    messages to their original queue.
  </doc>
  <doc name = "rule" test = "amq_basic_21">
    The server SHOULD be capable of accepting and process the Reject
    method while sending message content with a Deliver or Get-Ok
    method.  I.e. the server should read and process incoming methods
    while sending output frames.  To cancel a partially-send content,
    the server sends a content body frame of size 1 (i.e. with no data
    except the frame-end octet).
  </doc>
  <doc name = "rule" test = "amq_basic_22">
    The server SHOULD interpret this method as meaning that the client
    is unable to process the message at this time.
  </doc>
  <doc name = "rule">
    A client MUST NOT use this method as a means of selecting messages
    to process.  A rejected message MAY be discarded or dead-lettered,
    not necessarily passed to another client.
  </doc>      
  <chassis name = "server" implement = "MUST" />
    
  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "requeue" type = "bit">
    requeue the message
    <doc>
      If this field is zero, the message will be discarded.  If this bit
      is 1, the server will attempt to requeue the message.
    </doc>
    <doc name = "rule" test = "amq_basic_23">
      The server MUST NOT deliver the message to the same client within
      the context of the current channel.  The recommended strategy is
      to attempt to deliver the message to an alternative consumer, and
      if that is not possible, to move the message to a dead-letter
      queue.  The server MAY use more sophisticated tracking to hold
      the message on the queue and redeliver it to the same client at
      a later stage.
    </doc>
  </field>
</method>

<method name = "recover" index = "100">
  redeliver unacknowledged messages. This method is only allowed on non-transacted channels.
  <doc>
    This method asks the broker to redeliver all unacknowledged messages on a
    specifieid channel. Zero or more messages may be redelivered.
  </doc>
  <chassis name = "server" implement = "MUST" />

  <field name = "requeue" type = "bit">
    requeue the message
    <doc>
      If this field is zero, the message will be redelivered to the original recipient.  If this bit
      is 1, the server will attempt to requeue the message, potentially then delivering it to an
      alternative subscriber.
    </doc>
  </field>

    <doc name="rule">
      The server MUST set the redelivered flag on all messages that are resent.
    </doc>
    <doc name="rule">
    The server MUST raise a channel exception if this is called on a transacted channel.
    </doc>
</method>


</class>


  <class name="file" handler="channel" index="70">
    <!--
======================================================
==      FILE TRANSFER
======================================================
-->
  work with file content
<doc>
  The file class provides methods that support reliable file transfer.
  File messages have a specific set of properties that are required for
  interoperability with file transfer applications. File messages and
  acknowledgements are subject to channel transactions.  Note that the
  file class does not provide message browsing methods; these are not
  compatible with the staging model.  Applications that need browsable
  file transfer should use Basic content and the Basic class.
</doc>

<doc name = "grammar">
    file                = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK
                        / C:CANCEL S:CANCEL-OK
                        / C:OPEN S:OPEN-OK C:STAGE content
                        / S:OPEN C:OPEN-OK S:STAGE content
                        / C:PUBLISH
                        / S:DELIVER
                        / S:RETURN
                        / C:ACK
                        / C:REJECT
</doc>

<chassis name = "server" implement = "MAY" />
<chassis name = "client" implement = "MAY" />

<doc name = "rule">
  The server MUST make a best-effort to hold file messages on a
  reliable storage mechanism.
</doc>
<doc name = "rule">
  The server MUST NOT discard a file message in case of a queue
  overflow. The server MUST use the Channel.Flow method to slow or stop
  a file message publisher when necessary.
</doc>
<doc name = "rule">
  The server MUST implement at least 2 priority levels for file
  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">
  The server MUST support both automatic and explicit acknowledgements
  on file content.
</doc>

<!--  These are the properties for a File 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 = "priority" type = "octet">
    The message priority, 0 to 9
</field>
<field name = "reply to" type = "shortstr">
    The destination to reply to
</field>
<field name = "message id" type = "shortstr">
    The application message identifier
</field>
<field name = "filename" type = "shortstr">
    The message filename
</field>
<field name = "timestamp" type = "timestamp">
    The message timestamp
</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. May be
      set to zero, meaning "no specific limit".  Note that other
      prefetch limits may still apply. The prefetch-size is ignored
      if the no-ack option is set.
    </doc>
  </field>

  <field name = "prefetch count" type = "short">
    prefetch window in messages
    <doc>
      Specifies a prefetch window in terms of whole messages.  This
      is compatible with some file API implementations.  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">
      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">
    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_file_00">
      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 405 (resource locked).
    </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>
    This method provides the client with a consumer tag which it MUST
    use in methods that work with the consumer.
  </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>
    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.
  </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 = "open" synchronous = "1" index = "40">
  request to start staging
  <doc>
    This method requests permission to start staging a message.  Staging
    means sending the message into a temporary area at the recipient end
    and then delivering the message by referring to this temporary area.
    Staging is how the protocol handles partial file transfers - if a
    message is partially staged and the connection breaks, the next time
    the sender starts to stage it, it can restart from where it left off.
  </doc>
  <response name = "open-ok" />
  <chassis name = "server" implement = "MUST" />
  <chassis name = "client" implement = "MUST" />
  
  <field name = "identifier" type = "shortstr">
    staging identifier
    <doc>
      This is the staging identifier. This is an arbitrary string chosen
      by the sender.  For staging to work correctly the sender must use
      the same staging identifier when staging the same message a second
      time after recovery from a failure.  A good choice for the staging
      identifier would be the SHA1 hash of the message properties data
      (including the original filename, revised time, etc.).
    </doc>
  </field>

  <field name = "content size" type = "longlong">
    message content size
    <doc>
      The size of the content in octets.  The recipient may use this
      information to allocate or check available space in advance, to
      avoid "disk full" errors during staging of very large messages.
    </doc>
    <doc name = "rule">
      The sender MUST accurately fill the content-size field.
      Zero-length content is permitted.
    </doc>
  </field>
</method>

<method name = "open-ok" synchronous = "1" index = "41">
  confirm staging ready
  <doc>
    This method confirms that the recipient is ready to accept staged
    data.  If the message was already partially-staged at a previous
    time the recipient will report the number of octets already staged.
  </doc>
  <response name = "stage" />
  <chassis name = "server" implement = "MUST" />
  <chassis name = "client" implement = "MUST" />
  
  <field name = "staged size" type = "longlong">
    already staged amount
    <doc>
      The amount of previously-staged content in octets.  For a new
      message this will be zero.
    </doc>
    <doc name = "rule">
      The sender MUST start sending data from this octet offset in the
      message, counting from zero.
    </doc>
    <doc name = "rule">
      The recipient MAY decide how long to hold partially-staged content
      and MAY implement staging by always discarding partially-staged
      content.  However if it uses the file content type it MUST support
      the staging methods.
    </doc>
  </field>
</method>

<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "stage" content = "1" index = "50">
  stage message content
  <doc>
    This method stages the message, sending the message content to the
    recipient from the octet offset specified in the Open-Ok method.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <chassis name = "client" implement = "MUST" />
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "publish" index = "60">
  publish a message
  <doc>
    This method publishes a staged file message to a specific exchange.
    The file 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">
      The server MUST accept a blank exchange name to mean the default
      exchange.
    </doc>
    <doc name = "rule">
      If the exchange was declared as an internal exchange, the server
      MUST respond with a reply code 403 (access refused) and raise a
      channel exception.
    </doc>
    <doc name = "rule">
      The exchange MAY refuse file content in which case it MUST respond
      with a reply code 540 (not implemented) and raise a channel
      exception.
    </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_file_00">
      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_file_00">
      The server SHOULD implement the immediate flag.
    </doc>
  </field>

  <field name = "identifier" type = "shortstr">
    staging identifier
    <doc>
      This is the staging identifier of the message to publish.  The
      message must have been staged.  Note that a client can send the
      Publish method asynchronously without waiting for staging to
      finish.
    </doc>
  </field>
</method>

<method name = "return" content = "1" index = "70">
  return a failed message
  <doc>
    This method returns an undeliverable message that was published
    with the "immediate" flag set, or an unroutable message published
    with the "mandatory" flag set. The reply code and text provide
    information about the reason that the message was undeliverable.
  </doc>
  <chassis name = "client" implement = "MUST" />

  <field name = "reply code" domain = "reply code" />
  <field name = "reply text" domain = "reply text" />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was
      originally published to.
    </doc>
  </field>

  <field name = "routing key" type = "shortstr">
     Message routing key
    <doc>
      Specifies the routing key name specified when the message was
      published.
    </doc>
  </field>
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "deliver" index = "80">
  notify the client of a consumer message
  <doc>
    This method delivers a staged file message to the client, via a
    consumer. In the asynchronous message delivery model, the client
    starts a consumer using the Consume method, then the server
    responds with Deliver methods as and when messages arrive for
    that consumer.
  </doc>
  <doc name = "rule">
    The server SHOULD track the number of times a message has been
    delivered to clients and when a message is redelivered a certain
    number of times - e.g. 5 times - without being acknowledged, the
    server SHOULD consider the message to be unprocessable (possibly
    causing client applications to abort), and move the message to a
    dead letter queue.
  </doc>
  <chassis name = "client" implement = "MUST" />

  <field name = "consumer tag" domain = "consumer tag" />

  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "redelivered" domain = "redelivered" />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was originally
      published to.
    </doc>
  </field>

  <field name = "routing key" type = "shortstr">
     Message routing key
    <doc>
      Specifies the routing key name specified when the message was
      published.
    </doc>
  </field>

  <field name = "identifier" type = "shortstr">
    staging identifier
    <doc>
      This is the staging identifier of the message to deliver.  The
      message must have been staged.  Note that a server can send the
      Deliver method asynchronously without waiting for staging to
      finish.
    </doc>
  </field>
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "ack" index = "90">
  acknowledge one or more messages
  <doc>
    This method acknowledges one or more messages delivered via the
    Deliver method.  The client can ask to confirm a single message or
    a set of messages up to and including a specific message.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <field name = "delivery tag" domain = "delivery tag" />
      
  <field name = "multiple" type = "bit">
    acknowledge multiple messages
    <doc>
      If set to 1, the delivery tag is treated as "up to and including",
      so that the client can acknowledge multiple messages with a single
      method.  If set to zero, the delivery tag refers to a single
      message.  If the multiple field is 1, and the delivery tag is zero,
      tells the server to acknowledge all outstanding mesages.
    </doc>
    <doc name = "rule">
      The server MUST validate that a non-zero delivery-tag refers to an
      delivered message, and raise a channel exception if this is not the
      case.
    </doc>
  </field>
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "reject" index = "100">
  reject an incoming message
  <doc>
    This method allows a client to reject a message.  It can be used to
    return untreatable messages to their original queue.  Note that file
    content is staged before delivery, so the client will not use this
    method to interrupt delivery of a large message.
  </doc>
  <doc name = "rule">
    The server SHOULD interpret this method as meaning that the client
    is unable to process the message at this time.
  </doc>
  <doc name = "rule">
    A client MUST NOT use this method as a means of selecting messages
    to process.  A rejected message MAY be discarded or dead-lettered,
    not necessarily passed to another client.
  </doc>
  <chassis name = "server" implement = "MUST" />
    
  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "requeue" type = "bit">
    requeue the message
    <doc>
      If this field is zero, the message will be discarded.  If this bit
      is 1, the server will attempt to requeue the message.
    </doc>
    <doc name = "rule">
      The server MUST NOT deliver the message to the same client within
      the context of the current channel.  The recommended strategy is
      to attempt to deliver the message to an alternative consumer, and
      if that is not possible, to move the message to a dead-letter
      queue.  The server MAY use more sophisticated tracking to hold
      the message on the queue and redeliver it to the same client at
      a later stage.
    </doc>
  </field>
</method>

</class>

  <class name="stream" handler="channel" index="80">
    <!--
======================================================
==       STREAMING
======================================================
-->
  work with streaming content

<doc>
  The stream class provides methods that support multimedia streaming.
  The stream class uses the following semantics: one message is one
  packet of data; delivery is unacknowleged and unreliable; the consumer
  can specify quality of service parameters that the server can try to
  adhere to; lower-priority messages may be discarded in favour of high
  priority messages.
</doc>

<doc name = "grammar">
    stream              = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK
                        / C:CANCEL S:CANCEL-OK
                        / C:PUBLISH content
                        / S:RETURN
                        / S:DELIVER content
</doc>

<chassis name = "server" implement = "MAY" />
<chassis name = "client" implement = "MAY" />

<doc name = "rule">
  The server SHOULD discard stream messages on a priority basis if
  the queue size exceeds some configured limit.
</doc>
<doc name = "rule">
  The server MUST implement at least 2 priority levels for stream
  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">
  The server MUST implement automatic acknowledgements on stream
  content.  That is, as soon as a message is delivered to a client
  via a Deliver method, the server must remove it from the queue.
</doc>


<!--  These are the properties for a Stream 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 = "priority" type = "octet">
    The message priority, 0 to 9
</field>
<field name = "timestamp" type = "timestamp">
    The message timestamp
</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. May be
      set to zero, meaning "no specific limit".  Note that other
      prefetch limits may still apply.
    </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.
    </doc>
  </field>

  <field name = "consume rate" type = "long">
    transfer rate in octets/second
    <doc>
      Specifies a desired transfer rate in octets per second. This is
      usually determined by the application that uses the streaming
      data.  A value of zero means "no limit", i.e. as rapidly as
      possible.
    </doc>
    <doc name = "rule">
      The server MAY ignore the prefetch values and consume rates,
      depending on the type of stream and the ability of the server
      to queue and/or reply it.  The server MAY drop low-priority
      messages in favour of high-priority messages.
    </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">
    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>
  <doc name = "rule">
    Streaming applications SHOULD use different channels to select
    different streaming resolutions. AMQP makes no provision for
    filtering and/or transforming streams except on the basis of
    priority-based selective delivery of individual messages.
  </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 = "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_file_00">
      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 405 (resource locked).
    </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>
    This method provides the client with a consumer tag which it may
    use in methods that work with the consumer.
  </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>
    This method cancels a consumer.  Since message delivery is
    asynchronous the client may continue to receive messages for
    a short while after canceling a consumer.  It may process or
    discard these as appropriate.
  </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 as appropriate.
  </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">
      The server MUST accept a blank exchange name to mean the default
      exchange.
    </doc>
    <doc name = "rule">
      If the exchange was declared as an internal exchange, the server
      MUST respond with a reply code 403 (access refused) and raise a
      channel exception.
    </doc>
    <doc name = "rule">
      The exchange MAY refuse stream content in which case it MUST
      respond with a reply code 540 (not implemented) and raise a
      channel exception.
    </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_stream_00">
      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_stream_00">
      The server SHOULD implement the immediate flag.
    </doc>
  </field>
</method>

<method name = "return" content = "1" index = "50">
  return a failed message
  <doc>
    This method returns an undeliverable message that was published
    with the "immediate" flag set, or an unroutable message published
    with the "mandatory" flag set. The reply code and text provide
    information about the reason that the message was undeliverable.
  </doc>
  <chassis name = "client" implement = "MUST" />

  <field name = "reply code" domain = "reply code" />
  <field name = "reply text" domain = "reply text" />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was
      originally published to.
    </doc>
  </field>

  <field name = "routing key" type = "shortstr">
     Message routing key
    <doc>
      Specifies the routing key name specified when the message was
      published.
    </doc>     
  </field>
</method>


<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->

<method name = "deliver" content = "1" index = "60">
  notify the client of a consumer message
  <doc>
    This method delivers a message to the client, via a consumer.  In
    the asynchronous message delivery model, the client starts a
    consumer using the Consume method, then the server responds with
    Deliver methods as and when messages arrive for that consumer.
  </doc>
  <chassis name = "client" implement = "MUST" />

  <field name = "consumer tag" domain = "consumer tag" />

  <field name = "delivery tag" domain = "delivery tag" />

  <field name = "exchange" domain = "exchange name">
    <doc>
      Specifies the name of the exchange that the message was originally
      published to.
    </doc>
  </field>

  <field name = "queue" domain = "queue name">
    <doc>
      Specifies the name of the queue that the message came from. Note
      that a single channel can start many consumers on different
      queues.
    </doc>
    <assert check = "notnull" />
  </field>
</method>
  </class>

  <class name="tx" handler="channel" index="90">
    <!--
======================================================
==       TRANSACTIONS
======================================================
-->
  work with standard transactions

<doc>
  Standard transactions provide so-called "1.5 phase commit".  We can
  ensure that work is never lost, but there is a chance of confirmations
  being lost, so that messages may be resent.  Applications that use
  standard transactions must be able to detect and ignore duplicate
  messages.
</doc>
    <rule implement="SHOULD">
  An client using standard transactions SHOULD be able to track all
  messages received within a reasonable period, and thus detect and
  reject duplicates of the same message. It SHOULD NOT pass these to
  the application layer.
</rule>
    <doc name="grammar">
    tx                  = C:SELECT S:SELECT-OK
                        / C:COMMIT S:COMMIT-OK
                        / C:ROLLBACK S:ROLLBACK-OK
</doc>
    <chassis name="server" implement="SHOULD"/>
    <chassis name="client" implement="MAY"/>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="select" synchronous="1" index="10">
select standard transaction mode
  <doc>
    This method sets the channel to use standard transactions.  The
    client must use this method at least once on a channel before
    using the Commit or Rollback methods.
  </doc>
      <chassis name="server" implement="MUST"/>
      <response name="select-ok"/>
    </method>
    <method name="select-ok" synchronous="1" index="11">
confirm transaction mode
  <doc>
    This method confirms to the client that the channel was successfully
    set to use standard transactions.
  </doc>
      <chassis name="client" implement="MUST"/>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="commit" synchronous="1" index="20">
commit the current transaction
  <doc>
    This method commits all messages published and acknowledged in
    the current transaction.  A new transaction starts immediately
    after a commit.
  </doc>
      <chassis name="server" implement="MUST"/>
      <response name="commit-ok"/>
    </method>
    <method name="commit-ok" synchronous="1" index="21">
confirm a successful commit
  <doc>
    This method confirms to the client that the commit succeeded.
    Note that if a commit fails, the server raises a channel exception.
  </doc>
      <chassis name="client" implement="MUST"/>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="rollback" synchronous="1" index="30">
abandon the current transaction
  <doc>
    This method abandons all messages published and acknowledged in
    the current transaction.  A new transaction starts immediately
    after a rollback.
  </doc>
      <chassis name="server" implement="MUST"/>
      <response name="rollback-ok"/>
    </method>
    <method name="rollback-ok" synchronous="1" index="31">
confirm a successful rollback
  <doc>
    This method confirms to the client that the rollback succeeded.
    Note that if an rollback fails, the server raises a channel exception.
  </doc>
      <chassis name="client" implement="MUST"/>
    </method>
  </class>
  <class name="dtx" handler="channel" index="100">
    <!--
======================================================
==       DISTRIBUTED TRANSACTIONS
======================================================
-->
  work with distributed transactions

<doc>
  Distributed transactions provide so-called "2-phase commit".    The
  AMQP distributed transaction model supports the X-Open XA
  architecture and other distributed transaction implementations.
  The Dtx class assumes that the server has a private communications
  channel (not AMQP) to a distributed transaction coordinator.
</doc>
    <doc name="grammar">
    dtx                 = C:SELECT S:SELECT-OK
                          C:START S:START-OK
</doc>
    <chassis name="server" implement="MAY"/>
    <chassis name="client" implement="MAY"/>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="select" synchronous="1" index="10">
select standard transaction mode
  <doc>
    This method sets the channel to use distributed transactions.  The
    client must use this method at least once on a channel before
    using the Start method.
  </doc>
      <chassis name="server" implement="MUST"/>
      <response name="select-ok"/>
    </method>
    <method name="select-ok" synchronous="1" index="11">
confirm transaction mode
  <doc>
    This method confirms to the client that the channel was successfully
    set to use distributed transactions.
  </doc>
      <chassis name="client" implement="MUST"/>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="start" synchronous="1" index="20">
  start a new distributed transaction
  <doc>
    This method starts a new distributed transaction.  This must be
    the first method on a new channel that uses the distributed
    transaction mode, before any methods that publish or consume
    messages.
  </doc>
      <chassis name="server" implement="MAY"/>
      <response name="start-ok"/>
      <field name="dtx identifier" type="shortstr">
    transaction identifier
    <doc>
      The distributed transaction key. This identifies the transaction
      so that the AMQP server can coordinate with the distributed
      transaction coordinator.
    </doc>
        <assert check="notnull"/>
      </field>
    </method>
    <method name="start-ok" synchronous="1" index="21">
  confirm the start of a new distributed transaction
  <doc>
    This method confirms to the client that the transaction started.
    Note that if a start fails, the server raises a channel exception.
  </doc>
      <chassis name="client" implement="MUST"/>
    </method>
  </class>
  <class name="tunnel" handler="tunnel" index="110">
    <!--
======================================================
==       TUNNEL
======================================================
-->
  methods for protocol tunneling.

<doc>
  The tunnel methods are used to send blocks of binary data - which
  can be serialised AMQP methods or other protocol frames - between
  AMQP peers.
</doc>
    <doc name="grammar">
    tunnel              = C:REQUEST
                        / S:REQUEST
</doc>
    <chassis name="server" implement="MAY"/>
    <chassis name="client" implement="MAY"/>
    <field name="headers" type="table">
    Message header field table
</field>
    <field name="proxy name" type="shortstr">
    The identity of the tunnelling proxy
</field>
    <field name="data name" type="shortstr">
    The name or type of the message being tunnelled
</field>
    <field name="durable" type="octet">
    The message durability indicator
</field>
    <field name="broadcast" type="octet">
    The message broadcast mode
</field>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="request" content="1" index="10">
  sends a tunnelled method
  <doc>
    This method tunnels a block of binary data, which can be an
    encoded AMQP method or other data.  The binary data is sent
    as the content for the Tunnel.Request method.
  </doc>
      <chassis name="server" implement="MUST"/>
      <field name="meta data" type="table">
    meta data for the tunnelled block
    <doc>
    This field table holds arbitrary meta-data that the sender needs
    to pass to the recipient.
    </doc>
      </field>
    </method>
  </class>
  <class name="test" handler="channel" index="120">
    <!--
======================================================
==       TEST - CHECK FUNCTIONAL CAPABILITIES OF AN IMPLEMENTATION
======================================================
-->
  test functional primitives of the implementation

<doc>
  The test class provides methods for a peer to test the basic
  operational correctness of another peer. The test methods are
  intended to ensure that all peers respect at least the basic
  elements of the protocol, such as frame and content organisation
  and field types. We assume that a specially-designed peer, a
  "monitor client" would perform such tests.
</doc>
    <doc name="grammar">
    test                = C:INTEGER S:INTEGER-OK
                        / S:INTEGER C:INTEGER-OK
                        / C:STRING S:STRING-OK
                        / S:STRING C:STRING-OK
                        / C:TABLE S:TABLE-OK
                        / S:TABLE C:TABLE-OK
                        / C:CONTENT S:CONTENT-OK
                        / S:CONTENT C:CONTENT-OK
</doc>
    <chassis name="server" implement="MUST"/>
    <chassis name="client" implement="SHOULD"/>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="integer" synchronous="1" index="10">
  test integer handling
  <doc>
    This method tests the peer's capability to correctly marshal integer
    data.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <response name="integer-ok"/>
      <field name="integer 1" type="octet">
    octet test value
    <doc>
      An octet integer test value.
    </doc>
      </field>
      <field name="integer 2" type="short">
    short test value
    <doc>
      A short integer test value.
    </doc>
      </field>
      <field name="integer 3" type="long">
    long test value
    <doc>
      A long integer test value.
    </doc>
      </field>
      <field name="integer 4" type="longlong">
    long-long test value
    <doc>
      A long long integer test value.
    </doc>
      </field>
      <field name="operation" type="octet">
    operation to test
    <doc>
      The client must execute this operation on the provided integer
      test fields and return the result.
    </doc>
        <assert check="enum">
          <value name="add">return sum of test values</value>
          <value name="min">return lowest of test values</value>
          <value name="max">return highest of test values</value>
        </assert>
      </field>
    </method>
    <method name="integer-ok" synchronous="1" index="11">
  report integer test result
  <doc>
    This method reports the result of an Integer method.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <field name="result" type="longlong">
    result value
    <doc>
      The result of the tested operation.
    </doc>
      </field>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="string" synchronous="1" index="20">
  test string handling
  <doc>
    This method tests the peer's capability to correctly marshal string
    data.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <response name="string-ok"/>
      <field name="string 1" type="shortstr">
    short string test value
    <doc>
      An short string test value.
    </doc>
      </field>
      <field name="string 2" type="longstr">
    long string test value
    <doc>
      A long string test value.
    </doc>
      </field>
      <field name="operation" type="octet">
    operation to test
    <doc>
      The client must execute this operation on the provided string
      test fields and return the result.
    </doc>
        <assert check="enum">
          <value name="add">return concatentation of test strings</value>
          <value name="min">return shortest of test strings</value>
          <value name="max">return longest of test strings</value>
        </assert>
      </field>
    </method>
    <method name="string-ok" synchronous="1" index="21">
  report string test result
  <doc>
    This method reports the result of a String method.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <field name="result" type="longstr">
    result value
    <doc>
      The result of the tested operation.
    </doc>
      </field>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="table" synchronous="1" index="30">
  test field table handling
  <doc>
    This method tests the peer's capability to correctly marshal field
    table data.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <response name="table-ok"/>
      <field name="table" type="table">
    field table of test values
    <doc>
      A field table of test values.
    </doc>
      </field>
      <field name="integer op" type="octet">
    operation to test on integers
    <doc>
      The client must execute this operation on the provided field
      table integer values and return the result.
    </doc>
        <assert check="enum">
          <value name="add">return sum of numeric field values</value>
          <value name="min">return min of numeric field values</value>
          <value name="max">return max of numeric field values</value>
        </assert>
      </field>
      <field name="string op" type="octet">
    operation to test on strings
    <doc>
      The client must execute this operation on the provided field
      table string values and return the result.
    </doc>
        <assert check="enum">
          <value name="add">return concatenation of string field values</value>
          <value name="min">return shortest of string field values</value>
          <value name="max">return longest of string field values</value>
        </assert>
      </field>
    </method>
    <method name="table-ok" synchronous="1" index="31">
  report table test result
  <doc>
    This method reports the result of a Table method.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <field name="integer result" type="longlong">
    integer result value
    <doc>
      The result of the tested integer operation.
    </doc>
      </field>
      <field name="string result" type="longstr">
    string result value
    <doc>
      The result of the tested string operation.
    </doc>
      </field>
    </method>
    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
    <method name="content" synchronous="1" content="1" index="40">
  test content handling
  <doc>
    This method tests the peer's capability to correctly marshal content.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <response name="content-ok"/>
    </method>
    <method name="content-ok" synchronous="1" content="1" index="41">
  report content test result
  <doc>
    This method reports the result of a Content method.  It contains the
    content checksum and echoes the original content as provided.
  </doc>
      <chassis name="client" implement="MUST"/>
      <chassis name="server" implement="MUST"/>
      <field name="content checksum" type="long">
    content hash
    <doc>
      The 32-bit checksum of the content, calculated by adding the
      content into a 32-bit accumulator.
    </doc>
      </field>
    </method>
  </class>
</amqp>