amqp 0.5.0

data/protocol/amqp-0.8.xml

@@ -0,0 +1,3908 @@
+<?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>