Moved c++ over to using the same preview file for 0-10 work as java.

Removed all channel class related code from broker as a result.
Did the same for some python tests I missed earlier.
Renamed ChannelAdapter to ChannelHandler.



git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/trunk@578167 13f79535-47bb-0310-9956-ffa450edef68

14 files changed, 43 insertions, 7485 deletions

diff --git a/qpid/cpp/configure.ac b/qpid/cpp/configure.ac
index 7d990b48ac..1a81b8831e 100644
--- a/qpid/cpp/configure.ac
+++ b/qpid/cpp/configure.ac
@@ -120,7 +120,7 @@ test -n "$RUBY" && generate=yes
 test -z "$RUBY" && AC_MSG_ERROR([Missing ruby installation (try "yum install ruby").])
 
 specdir=`pwd`/$srcdir/../specs  
-AMQP_XML=$specdir/amqp-transitional.0-10.xml
+AMQP_XML=$specdir/amqp.0-10-preview.xml
 AC_SUBST(AMQP_XML)
 ls $AMQP_XML >/dev/null 2>&1 || generate=no
 
diff --git a/qpid/cpp/src/Makefile.am b/qpid/cpp/src/Makefile.am
index 7f25c194d4..cf7029dabc 100644
--- a/qpid/cpp/src/Makefile.am
+++ b/qpid/cpp/src/Makefile.am
@@ -157,7 +157,7 @@ libqpidbroker_la_SOURCES = \
   qpid/broker/BrokerExchange.cpp \
   qpid/broker/BrokerQueue.cpp \
   qpid/broker/Connection.cpp \
-  qpid/broker/ConnectionAdapter.cpp \
+  qpid/broker/ConnectionHandler.cpp \
   qpid/broker/ConnectionFactory.cpp \
   qpid/broker/Daemon.cpp \
   qpid/broker/DeliverableMessage.cpp \
@@ -268,7 +268,7 @@ nobase_include_HEADERS = \
   qpid/broker/BrokerAdapter.h \
   qpid/broker/BrokerSingleton.h \
   qpid/broker/Connection.h \
-  qpid/broker/ConnectionAdapter.h \
+  qpid/broker/ConnectionHandler.h \
   qpid/broker/ConnectionFactory.h \
   qpid/broker/ConnectionToken.h \
   qpid/broker/Daemon.h \
diff --git a/qpid/cpp/src/qpid/broker/Connection.h b/qpid/cpp/src/qpid/broker/Connection.h
index 94651701dd..2723ac9acc 100644
--- a/qpid/cpp/src/qpid/broker/Connection.h
+++ b/qpid/cpp/src/qpid/broker/Connection.h
@@ -36,7 +36,7 @@
 #include "Broker.h"
 #include "qpid/Exception.h"
 #include "Session.h"
-#include "ConnectionAdapter.h"
+#include "ConnectionHandler.h"
 #include "SessionHandler.h"
 
 #include <boost/optional.hpp>
@@ -95,7 +95,7 @@ class Connection : public sys::ConnectionInputHandler,
     uint16_t heartbeat;
     framing::AMQP_ClientProxy::Connection* client;
     uint64_t stagingThreshold;
-    ConnectionAdapter adapter;
+    ConnectionHandler adapter;
 };
 
 }}
diff --git a/qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp b/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp
index e33aeda8c7..a769d05470 100644
--- a/qpid/cpp/src/qpid/broker/ConnectionAdapter.cpp
+++ b/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp
@@ -20,7 +20,7 @@
  *
  */
 
-#include "ConnectionAdapter.h"
+#include "ConnectionHandler.h"
 #include "Connection.h"
 #include "qpid/framing/ConnectionStartBody.h"
 
@@ -28,34 +28,24 @@ using namespace qpid;
 using namespace qpid::broker;
 using namespace qpid::framing;
 
-void ConnectionAdapter::init(const framing::ProtocolInitiation& header) {
+void ConnectionHandler::init(const framing::ProtocolInitiation& header) {
     FieldTable properties;
     string mechanisms("PLAIN");
     string locales("en_US");
     handler->client.start(header.getMajor(), header.getMinor(), properties, mechanisms, locales);
 }
 
-void ConnectionAdapter::close(ReplyCode code, const string& text, ClassId classId, MethodId methodId)
+void ConnectionHandler::close(ReplyCode code, const string& text, ClassId classId, MethodId methodId)
 {
     handler->client.close(code, text, classId, methodId);
 }
 
-
-framing::AMQP_ServerOperations::ConnectionHandler* ConnectionAdapter::getConnectionHandler() 
-{ 
-    return handler.get(); 
-}
-
-framing::ProtocolVersion ConnectionAdapter::getVersion() const 
-{ 
-    return handler->connection.getVersion(); 
-}
-
-void ConnectionAdapter::handle(framing::AMQFrame& frame)
+void ConnectionHandler::handle(framing::AMQFrame& frame)
 {
     AMQMethodBody* method=frame.getBody()->getMethod();
     try{
-        method->invoke(*this);
+        if (!method->invoke(handler.get()))
+            throw ConnectionException(503, "Class can't be accessed over channel 0");
     }catch(ConnectionException& e){
         handler->client.close(e.code, e.toString(), method->amqpClassId(), method->amqpMethodId());
     }catch(std::exception& e){
@@ -63,27 +53,27 @@ void ConnectionAdapter::handle(framing::AMQFrame& frame)
     }
 }
 
-ConnectionAdapter::ConnectionAdapter(Connection& connection)  : handler(new Handler(connection)) {}
+ConnectionHandler::ConnectionHandler(Connection& connection)  : handler(new Handler(connection)) {}
 
-ConnectionAdapter::Handler:: Handler(Connection& c) : client(c.getOutput()), connection(c) {}
+ConnectionHandler::Handler:: Handler(Connection& c) : client(c.getOutput()), connection(c) {}
 
-void ConnectionAdapter::Handler::startOk(const FieldTable& /*clientProperties*/,
+void ConnectionHandler::Handler::startOk(const FieldTable& /*clientProperties*/,
     const string& /*mechanism*/, 
     const string& /*response*/, const string& /*locale*/)
 {
     client.tune(framing::CHANNEL_MAX, connection.getFrameMax(), connection.getHeartbeat());
 }
         
-void ConnectionAdapter::Handler::secureOk(const string& /*response*/){}
+void ConnectionHandler::Handler::secureOk(const string& /*response*/){}
         
-void ConnectionAdapter::Handler::tuneOk(uint16_t /*channelmax*/,
+void ConnectionHandler::Handler::tuneOk(uint16_t /*channelmax*/,
     uint32_t framemax, uint16_t heartbeat)
 {
     connection.setFrameMax(framemax);
     connection.setHeartbeat(heartbeat);
 }
         
-void ConnectionAdapter::Handler::open(const string& /*virtualHost*/,
+void ConnectionHandler::Handler::open(const string& /*virtualHost*/,
     const string& /*capabilities*/, bool /*insist*/)
 {
     string knownhosts;
@@ -91,13 +81,13 @@ void ConnectionAdapter::Handler::open(const string& /*virtualHost*/,
 }
 
         
-void ConnectionAdapter::Handler::close(uint16_t /*replyCode*/, const string& /*replyText*/, 
+void ConnectionHandler::Handler::close(uint16_t /*replyCode*/, const string& /*replyText*/, 
     uint16_t /*classId*/, uint16_t /*methodId*/)
 {
     client.closeOk();
     connection.getOutput().close();
 } 
         
-void ConnectionAdapter::Handler::closeOk(){
+void ConnectionHandler::Handler::closeOk(){
     connection.getOutput().close();
 } 
diff --git a/qpid/cpp/src/qpid/broker/ConnectionAdapter.h b/qpid/cpp/src/qpid/broker/ConnectionHandler.h
index eb96575c9d..aa8c9366cd 100644
--- a/qpid/cpp/src/qpid/broker/ConnectionAdapter.h
+++ b/qpid/cpp/src/qpid/broker/ConnectionHandler.h
@@ -37,7 +37,7 @@ namespace broker {
 class Connection;
 
 // TODO aconway 2007-09-18: Rename to ConnectionHandler
-class ConnectionAdapter : public framing::FrameHandler, public framing::AMQP_ServerOperations
+class ConnectionHandler : public framing::FrameHandler
 {
     struct Handler : public framing::AMQP_ServerOperations::ConnectionHandler
     {
@@ -58,29 +58,10 @@ class ConnectionAdapter : public framing::FrameHandler, public framing::AMQP_Ser
     };
     std::auto_ptr<Handler> handler;
   public:
-    ConnectionAdapter(Connection& connection);
+    ConnectionHandler(Connection& connection);
     void init(const framing::ProtocolInitiation& header);
     void close(framing::ReplyCode code, const std::string& text, framing::ClassId classId, framing::MethodId methodId);
     void handle(framing::AMQFrame& frame);
-
-    //AMQP_ServerOperations:
-    ConnectionHandler* getConnectionHandler();
-    ChannelHandler* getChannelHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    BasicHandler* getBasicHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    ExchangeHandler* getExchangeHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    BindingHandler* getBindingHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    QueueHandler* getQueueHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    TxHandler* getTxHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    MessageHandler* getMessageHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    AccessHandler* getAccessHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    FileHandler* getFileHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    StreamHandler* getStreamHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    TunnelHandler* getTunnelHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    DtxCoordinationHandler* getDtxCoordinationHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    DtxDemarcationHandler* getDtxDemarcationHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    ExecutionHandler* getExecutionHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    SessionHandler* getSessionHandler() { throw ConnectionException(503, "Class can't be accessed over channel 0"); }
-    framing::ProtocolVersion getVersion() const;
 };
 
 
diff --git a/qpid/cpp/src/qpid/broker/SemanticHandler.cpp b/qpid/cpp/src/qpid/broker/SemanticHandler.cpp
index fc878ca346..f8d76c3b5f 100644
--- a/qpid/cpp/src/qpid/broker/SemanticHandler.cpp
+++ b/qpid/cpp/src/qpid/broker/SemanticHandler.cpp
@@ -28,7 +28,6 @@
 #include "Session.h"
 #include "qpid/framing/ExecutionCompleteBody.h"
 #include "qpid/framing/ExecutionResultBody.h"
-#include "qpid/framing/ChannelOpenBody.h"
 #include "qpid/framing/InvocationVisitor.h"
 
 #include <boost/format.hpp>
diff --git a/qpid/cpp/src/qpid/broker/SessionHandler.cpp b/qpid/cpp/src/qpid/broker/SessionHandler.cpp
index e7ef6fdb87..01ce88059a 100644
--- a/qpid/cpp/src/qpid/broker/SessionHandler.cpp
+++ b/qpid/cpp/src/qpid/broker/SessionHandler.cpp
@@ -33,8 +33,7 @@ using namespace std;
 SessionHandler::SessionHandler(Connection& c, ChannelId ch)
     : InOutHandler(0, &c.getOutput()),
       connection(c), channel(ch), proxy(out),
-      ignoring(false), channelHandler(*this),
-      useChannelClose(false) {}
+      ignoring(false) {}
 
 SessionHandler::~SessionHandler() {}
 
@@ -52,7 +51,7 @@ void SessionHandler::handleIn(AMQFrame& f) {
     // 
     AMQMethodBody* m=f.getMethod();
     try {
-        if (m && (m->invoke(this) || m->invoke(&channelHandler)))
+        if (m && m->invoke(this))
             return;
         else if (session)
             session->in(f);
@@ -62,12 +61,7 @@ void SessionHandler::handleIn(AMQFrame& f) {
     } catch(const ChannelException& e) {
         ignoring=true;          // Ignore trailing frames sent by client.
         session.reset();
-        // FIXME aconway 2007-09-19: Dual-mode hack.
-        if (useChannelClose)
-            getProxy().getChannel().close(
-                e.code, e.toString(), classId(m), methodId(m));
-        else
-            getProxy().getSession().closed(e.code, e.toString());
+        getProxy().getSession().closed(e.code, e.toString());
     }catch(const ConnectionException& e){
         connection.close(e.code, e.what(), classId(m), methodId(m));
     }catch(const std::exception& e){
@@ -98,51 +92,6 @@ void SessionHandler::assertClosed(const char* method) {
                      << getChannel()));
 }
 
-void SessionHandler::ChannelMethods::open(const string& /*outOfBand*/){
-    parent.useChannelClose=true;
-    parent.assertClosed("open");
-    parent.session.reset(new Session(parent, 0));
-    parent.getProxy().getChannel().openOk();
-} 
-
-// FIXME aconway 2007-08-31: flow is no longer in the spec.
-void SessionHandler::ChannelMethods::flow(bool active){
-    parent.session->flow(active);
-    parent.getProxy().getChannel().flowOk(active);
-}
-
-void SessionHandler::ChannelMethods::flowOk(bool /*active*/){}
-        
-void SessionHandler::ChannelMethods::close(uint16_t replyCode,
-                           const string& replyText,
-                           uint16_t classId, uint16_t methodId)
-{
-    // FIXME aconway 2007-08-31: Extend constants.h to map codes & ids
-    // to text names.
-    QPID_LOG(warning, "Received channel.close("<<replyCode<<","
-             <<replyText << ","
-             << "classid=" <<classId<< ","
-             << "methodid=" <<methodId);
-    parent.ignoring=false;
-    parent.getProxy().getChannel().closeOk();
-    // FIXME aconway 2007-08-31: sould reset session BEFORE
-    // sending closeOK to avoid races. SessionHandler
-    // needs its own private proxy, see getProxy() above.
-    parent.session.reset();
-    // No need to remove from connection map, will be re-used
-    // if channel is re-opened.
-} 
-        
-void SessionHandler::ChannelMethods::closeOk(){
-    parent.ignoring=false;
-}
-
-void SessionHandler::ChannelMethods::ok() 
-{
-    //no specific action required, generic response handling should be
-    //sufficient
-}
-
 void  SessionHandler::open(uint32_t detachedLifetime) {
     assertClosed("open");
     session.reset(new Session(*this, detachedLifetime));
diff --git a/qpid/cpp/src/qpid/broker/SessionHandler.h b/qpid/cpp/src/qpid/broker/SessionHandler.h
index 5962ab77a8..a9c0f69985 100644
--- a/qpid/cpp/src/qpid/broker/SessionHandler.h
+++ b/qpid/cpp/src/qpid/broker/SessionHandler.h
@@ -64,25 +64,6 @@ class SessionHandler : public framing::FrameHandler::InOutHandler,
     void handleOut(framing::AMQFrame&);
     
   private:
-    // FIXME aconway 2007-08-31: Drop channel.
-    struct ChannelMethods : public framing::AMQP_ServerOperations::ChannelHandler {
-        SessionHandler& parent;
-
-        ChannelMethods(SessionHandler& p) : parent(p) {}
-        void open(const std::string& outOfBand); 
-        void flow(bool active); 
-        void flowOk(bool active); 
-        void ok(  );
-        void ping(  );
-        void pong(  );
-        void resume( const std::string& channelId );
-        void close(uint16_t replyCode,
-                   const std::string& replyText,
-                   uint16_t classId, uint16_t methodId); 
-        void closeOk(); 
-    };
-  friend class ChannelMethods;
-
     /// Session methods
     void open(uint32_t detachedLifetime);
     void flow(bool active);
@@ -105,8 +86,6 @@ class SessionHandler : public framing::FrameHandler::InOutHandler,
     framing::AMQP_ClientProxy proxy;
     shared_ptr<Session> session;
     bool ignoring;
-    ChannelMethods channelHandler;
-    bool useChannelClose;       // FIXME aconway 2007-09-19: remove with channel.
 };
 
 }} // namespace qpid::broker
diff --git a/qpid/cpp/src/tests/python_tests b/qpid/cpp/src/tests/python_tests
index 33d60fcf09..d9754ed0fb 100755
--- a/qpid/cpp/src/tests/python_tests
+++ b/qpid/cpp/src/tests/python_tests
@@ -1,7 +1,7 @@
 #!/bin/sh
 # Run the python tests.
 if test -d ../../../python ;  then
-    cd ../../../python && ./run-tests -v -s ../specs/amqp-transitional.0-10.xml -I cpp_failing_0-10.txt -b localhost:$QPID_PORT $PYTHON_TESTS
+    cd ../../../python && ./run-tests -v -s ../specs/amqp.0-10-preview.xml -I cpp_failing_0-10.txt -b localhost:$QPID_PORT $PYTHON_TESTS
 else
     echo Warning: python tests not found.
 fi
diff --git a/qpid/python/tests_0-10/alternate-exchange.py b/qpid/python/tests_0-10/alternate-exchange.py
index a749d733b0..a857496a48 100644
--- a/qpid/python/tests_0-10/alternate-exchange.py
+++ b/qpid/python/tests_0-10/alternate-exchange.py
@@ -136,9 +136,9 @@ class AlternateExchangeTests(TestBase):
             #cleanup:
             other = self.connect()
             channel = other.channel(1)
-            channel.channel_open()
+            channel.session_open()
             channel.exchange_delete(exchange="alternate")
-            channel.channel_close(200, "ok")
+            channel.session_close()
             other.close()
             
             self.assertConnectionException(530, e.args[0])            
@@ -162,10 +162,10 @@ class AlternateExchangeTests(TestBase):
             #cleanup:
             other = self.connect()
             channel = other.channel(1)
-            channel.channel_open()
+            channel.session_open()
             channel.exchange_delete(exchange="e")
             channel.exchange_delete(exchange="alternate")
-            channel.channel_close(200, "ok")
+            channel.session_close()
             other.close()
 
             self.assertConnectionException(530, e.args[0])
diff --git a/qpid/python/tests_0-10/dtx.py b/qpid/python/tests_0-10/dtx.py
index 000eddff21..ce6e467e0a 100644
--- a/qpid/python/tests_0-10/dtx.py
+++ b/qpid/python/tests_0-10/dtx.py
@@ -461,8 +461,11 @@ class DtxTests(TestBase):
 
         channel2.dtx_demarcation_select()
         channel2.dtx_demarcation_start(xid=tx)
-        channel2.message_get(queue="dummy", destination="dummy")
+        channel2.message_subscribe(queue="dummy", destination="dummy", confirm_mode=1)
+        channel2.message_flow(destination="dummy", unit=0, value=1)
+        channel2.message_flow(destination="dummy", unit=1, value=0xFFFFFFFF)
         self.client.queue("dummy").get(timeout=1).complete()
+        channel2.message_cancel(destination="dummy")
         channel2.message_transfer(content=Content(properties={'routing_key':"dummy"}, body="whatever"))
         channel2.session_close()
 
@@ -589,8 +592,11 @@ class DtxTests(TestBase):
 
     def swap(self, channel, src, dest):
         #consume from src:
-        channel.message_get(destination="temp-swap", queue=src)
+        channel.message_subscribe(destination="temp-swap", queue=src, confirm_mode=1)
+        channel.message_flow(destination="temp-swap", unit=0, value=1)
+        channel.message_flow(destination="temp-swap", unit=1, value=0xFFFFFFFF)
         msg = self.client.queue("temp-swap").get(timeout=1)
+        channel.message_cancel(destination="temp-swap")
         msg.complete();        
 
         #re-publish to dest
diff --git a/qpid/python/tests_0-10/message.py b/qpid/python/tests_0-10/message.py
index ba26dda309..b5b058340f 100644
--- a/qpid/python/tests_0-10/message.py
+++ b/qpid/python/tests_0-10/message.py
@@ -70,7 +70,7 @@ class MessageTests(TestBase):
 
         #open new channel and cleanup last consumer:    
         channel = self.client.channel(2)
-        channel.channel_open()
+        channel.session_open()
 
         #check that an exclusive consumer cannot be created if a consumer already exists:
         self.subscribe(channel, destination="first", queue="test-queue-2")
@@ -93,7 +93,7 @@ class MessageTests(TestBase):
             self.assertChannelException(404, e.args[0])
 
         channel = self.client.channel(2)
-        channel.channel_open()
+        channel.session_open()
         try:
             #queue not specified and none previously declared for channel:
             self.subscribe(channel, queue="", destination="")
diff --git a/qpid/specs/amqp-transitional.0-10.xml b/qpid/specs/amqp-transitional.0-10.xml
deleted file mode 100644
index da3863f00b..0000000000
--- a/qpid/specs/amqp-transitional.0-10.xml
+++ /dev/null
@@ -1,7348 +0,0 @@
-<?xml version="1.0"?>
-
-<!--
-  EDITORS: (PH)   Pieter Hintjens <ph@imatix.com>
-  (KvdR) Kim van der Riet <kim.vdriet@redhat.com>
-
-  These editors have been assigned by the AMQP working group. Please do not edit/commit this file
-  without consulting with one of the above editors.
-  ========================================================
-
-  TODOs
-  - see TODO comments in the text
--->
-
-<!--
-  Copyright Notice
-  ================
-  (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix
-  Corporation, IONA\ufffd Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc.
-  2006. All rights reserved.
-
-  License
-  =======
-  JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA
-  Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. (collectively, the
-  "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable,
-  nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue
-  Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for
-  the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and
-  any rights under this Agreement will terminate immediately without notice from any Author if you
-  bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol
-  Specification against any Author. Upon termination, you shall destroy all copies of the Advanced
-  Messaging Queue Protocol Specification in your possession or control.
-
-  As used hereunder, "Licensed Claims" means those claims of a patent or patent application,
-  throughout the world, excluding design patents and design registrations, owned or controlled, or
-  that can be sublicensed without fee and in compliance with the requirements of this Agreement, by
-  an Author or its affiliates now or at any future time and which would necessarily be infringed by
-  implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily
-  infringed hereunder only when it is not possible to avoid infringing it because there is no
-  plausible non-infringing alternative for implementing the required portions of the Advanced
-  Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not
-  include any claims other than as set forth above even if contained in the same patent as Licensed
-  Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue
-  Protocol Specification that are not required by the Advanced Messaging Queue Protocol
-  Specification, or that, if licensed, would require a payment of royalties by the licensor to
-  unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling
-  technologies that may be necessary to make or use any Licensed Product but are not themselves
-  expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
-  manufacturing technology, compiler technology, object oriented technology, networking technology,
-  operating system technology, and the like); or (ii) the implementation of other published
-  standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue
-  Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or
-  function of which is not required for compliance with the Advanced Messaging Queue Protocol
-  Specification. For purposes of this definition, the Advanced Messaging Queue Protocol
-  Specification shall be deemed to include both architectural and interconnection requirements
-  essential for interoperability and may also include supporting source code artifacts where such
-  architectural, interconnection requirements and source code artifacts are expressly identified as
-  being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol
-  Specification.
-
-  As used hereunder, "Licensed Products" means only those specific portions of products (hardware,
-  software or combinations thereof) that implement and are compliant with all relevant portions of
-  the Advanced Messaging Queue Protocol Specification.
-
-  The following disclaimers, which you hereby also acknowledge as to any use you may make of the
-  Advanced Messaging Queue Protocol Specification:
-
-  THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO
-  REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF
-  MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS
-  OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE
-  IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD
-  PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.
-
-  THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
-  DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED
-  MESSAGING QUEUE PROTOCOL SPECIFICATION.
-
-  The name and trademarks of the Authors may NOT be used in any manner, including advertising or
-  publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents
-  without specific, written prior permission. Title to copyright in the Advanced Messaging Queue
-  Protocol Specification will at all times remain with the Authors.
-
-  No other rights are granted by implication, estoppel or otherwise.
-
-  Upon termination of your license or rights under this Agreement, you shall destroy all copies of
-  the Advanced Messaging Queue Protocol Specification in your possession or control.
-
-  Trademarks
-  ==========
-  "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are
-  trademarks of JPMorgan Chase & Co.
-
-  IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl.
-
-  IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its
-  subsidiaries.
-
-  LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat,
-  Inc. in the US and other countries.
-
-  Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the
-  United States, other countries, or both.
-
-  Other company, product, or service names may be trademarks or service marks of others.
-
-  Links to full AMQP specification:
-  =================================
-  http://www.envoytech.org/spec/amq/
-  http://www.iona.com/opensource/amqp/
-  http://www.redhat.com/solutions/specifications/amqp/
-  http://www.twiststandards.org/tiki-index.php?page=AMQ
-  http://www.imatix.com/amqp
--->
-
-<!--
-  XML Notes
-  =========
-
-  We use entities to indicate repetition; attributes to indicate properties.
-
-  We use the "name" attribute as an identifier, usually within the context of the surrounding
-  entities.
-
-  We use hyphens (minus char '-') to seperate words in names.
-
-  We do not enforce any particular validation mechanism but we support all mechanisms.  The protocol
-  definition conforms to a formal grammar that is published seperately in several technologies.
-
--->
-
-<!--
-
-<!DOCTYPE amqp SYSTEM "amqp.dtd">
-
--->
-
-<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
-    major="0" minor="10" port="5672" comment="AMQ Protocol (Working version)">
-
-  <!--
-    ======================================================
-    ==       CONSTANTS
-    ======================================================
-  -->
-  <!-- Frame types -->
-  <constant name="frame-method" value="1" />
-  <constant name="frame-header" value="2" />
-  <constant name="frame-body" value="3" />
-  <constant name="frame-trace" value="7" />
-  <constant name="frame-heartbeat" value="8" />
-
-  <!-- Protocol constants -->
-  <constant name="frame-min-size" value="4096" />
-  <constant name="frame-end" value="206" />
-
-  <!-- Reply codes -->
-  <constant name="reply-success" value="200">
-    <doc>
-      Indicates that the method completed successfully. This reply code is reserved for future use -
-      the current protocol design does not use positive confirmation and reply codes are sent only
-      in case of an error.
-    </doc>
-  </constant>
-
-  <constant name="not-delivered" value="310" class="soft-error">
-    <doc>
-      The client asked for a specific message that is no longer available. The message was delivered
-      to another client, or was purged from the queue for some other reason.
-    </doc>
-  </constant>
-
-  <constant name="content-too-large" value="311" class="soft-error">
-    <doc>
-      The client attempted to transfer content larger than the server could accept at the present
-      time. The client may retry at a later time.
-    </doc>
-  </constant>
-
-  <constant name="no-route" value="312" class="soft-error">
-    <doc>
-      When the exchange cannot route the result of a .Publish, most likely due to an invalid routing
-      key. Only when the mandatory flag is set.
-    </doc>
-  </constant>
-
-  <constant name="no-consumers" value="313" class="soft-error">
-    <doc>
-      When the exchange cannot deliver to a consumer when the immediate flag is set. As a result of
-      pending data on the queue or the absence of any consumers of the queue.
-    </doc>
-  </constant>
-
-  <constant name="connection-forced" value="320" class="hard-error">
-    <doc>
-      An operator intervened to close the connection for some reason. The client may retry at some
-      later date.
-    </doc>
-  </constant>
-
-  <constant name="invalid-path" value="402" class="hard-error">
-    <doc>
-      The client tried to work with an unknown virtual host.
-    </doc>
-  </constant>
-
-  <constant name="access-refused" value="403" class="soft-error">
-    <doc>
-      The client attempted to work with a server entity to which it has no access due to security
-      settings.
-    </doc>
-  </constant>
-
-  <constant name="not-found" value="404" class="soft-error">
-    <doc>
-      The client attempted to work with a server entity that does not exist.
-    </doc>
-  </constant>
-
-  <constant name="resource-locked" value="405" class="soft-error">
-    <doc>
-      The client attempted to work with a server entity to which it has no access because another
-      client is working with it.
-    </doc>
-  </constant>
-
-  <constant name="precondition-failed" value="406" class="soft-error">
-    <doc>
-      The client requested a method that was not allowed because some precondition failed.
-    </doc>
-  </constant>
-
-  <constant name="frame-error" value="501" class="hard-error">
-    <doc>
-      The client sent a malformed frame that the server could not decode. This strongly implies a
-      programming error in the client.
-    </doc>
-  </constant>
-
-  <constant name="syntax-error" value="502" class="hard-error">
-    <doc>
-      The client sent a frame that contained illegal values for one or more fields. This strongly
-      implies a programming error in the client.
-    </doc>
-  </constant>
-
-  <constant name="command-invalid" value="503" class="hard-error">
-    <doc>
-      The client sent an invalid sequence of frames, attempting to perform an operation that was
-      considered invalid by the server. This usually implies a programming error in the client.
-    </doc>
-  </constant>
-
-  <!-- TODO: Should this be renamed to "session-error" since class channel has been replaced by
-    class session? -->
-  <constant name="channel-error" value="504" class="hard-error">
-    <doc>
-      The client attempted to work with a channel that had not been correctly opened. This most
-      likely indicates a fault in the client layer.
-    </doc>
-  </constant>
-
-  <constant name="resource-error" value="506" class="hard-error">
-    <doc>
-      The server could not complete the method because it lacked sufficient resources. This may be
-      due to the client creating too many of some type of entity.
-    </doc>
-  </constant>
-
-  <constant name="not-allowed" value="530" class="hard-error">
-    <doc>
-      The client tried to work with some entity in a manner that is prohibited by the server, due to
-      security settings or by some other criteria.
-    </doc>
-  </constant>
-
-  <constant name="not-implemented" value="540" class="hard-error">
-    <doc>
-      The client tried to use functionality that is not implemented in the server.
-    </doc>
-  </constant>
-
-  <constant name="internal-error" value="541" class="hard-error">
-    <doc>
-      The server could not complete the method because of an internal error. The server may require
-      intervention by an operator in order to resume normal operations.
-    </doc>
-  </constant>
-
-  <constant name="invalid-argument" value="542" class="hard-error">
-    <doc>
-      An invalid or illegal argument was passed to a method, and the operation could not proceed.
-    </doc>
-  </constant>
-
-  <!-- XA constants -->
-
-  <constant name="xa-ok" value="0">
-    <doc>
-      XA return code: Normal execution completion (no error).
-    </doc>
-  </constant>
-
-  <constant name="xa-rbrollback" value="1">
-    <doc>
-      XA return code: The rollback was caused for an unspecified reason.
-    </doc>
-  </constant>
-
-  <constant name="xa-rbtimeout" value="2">
-    <doc>
-      XA return code: A transaction branch took too long.
-    </doc>
-  </constant>
-
-  <constant name="xa-heurhaz" value="3">
-    <doc>
-      XA return code: The transaction branch may have been heuristically completed.
-    </doc>
-  </constant>
-
-  <constant name="xa-heurcom" value="4">
-    <doc>
-      XA return code: The transaction branch has been heuristically committed.
-    </doc>
-  </constant>
-
-  <constant name="xa-heurrb" value="5">
-    <doc>
-      XA return code: The transaction branch has been heuristically rolled back.
-    </doc>
-  </constant>
-
-  <constant name="xa-heurmix" value="6">
-    <doc>
-      XA return code: The transaction branch has been heuristically committed and rolled back.
-    </doc>
-  </constant>
-
-  <constant name="xa-rdonly" value="7">
-    <doc>
-      XA return code: The transaction branch was read-only and has been committed.
-    </doc>
-  </constant>
-
-  <!--
-    ================================
-    == Field Table type constants ==
-    ================================
-  -->
-
-  <!--
-    0x00 - 0x0f: Fixed width, 1 octet
-  -->
-
-  <constant name="field-table-octet" value="0x00" width="1" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Octet of unspecified encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-signed-byte" value="0x01" width="1" datatype="signed-integer"
-    class="field-table-type">
-    <doc>
-      8-bit signed integral value (-128 - 127)
-    </doc>
-  </constant>
-
-  <constant name="field-table-unsigned-byte" value="0x02" width="1" datatype="unsigned-integer"
-    class="field-table-type">
-    <doc>
-      8-bit unsigned integral value (0 - 255)
-    </doc>
-  </constant>
-
-  <constant name="field-table-char" value="0x04" width="1" datatype="char"
-    class="field-table-type">
-    <doc>
-      8-bit representation of single character in the iso-8859-15 character set
-    </doc>
-  </constant>
-
-  <constant name="field-table-boolean" value="0x08" width="1" datatype="boolean"
-    class="field-table-type">
-    <doc>
-      Boolean value (0 represents false, 1 represents true)
-    </doc>
-  </constant>
-
-  <!--
-    0x10 - 0x1f: Fixed width, 2 octets
-  -->
-
-  <constant name="field-table-two-octets" value="0x10" width="2" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Two octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-signed-short" value="0x11" width="2" datatype="signed-integer"
-    class="field-table-type">
-    <doc>
-      16-bit signed integral value
-    </doc>
-  </constant>
-
-  <constant name="field-table-unsigned-short" value="0x12" width="2" datatype="unsigned-integer"
-    class="field-table-type">
-    <doc>
-      16-bit unsigned integral value
-    </doc>
-  </constant>
-
-  <!--
-    0x20 - 0x2f: Fixed width, 4 octets
-  -->
-
-  <constant name="field-table-four-octets" value="0x20" width="4" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Four octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-signed-int" value="0x21" width="4" datatype="signed-integer"
-    class="field-table-type">
-    <doc>
-      32-bit signed integral value
-    </doc>
-  </constant>
-
-  <constant name="field-table-unsigned-int" value="0x22" width="4" datatype="unsigned-integer"
-    class="field-table-type">
-    <doc>
-      32-bit unsigned integral value
-    </doc>
-  </constant>
-
-  <constant name="field-table-float" value="0x23" width="4" datatype="ieee-float"
-    class="field-table-type">
-    <doc>
-      Single precision IEEE 754 32-bit floating point
-    </doc>
-  </constant>
-
-  <constant name="field-table-utf32-char" value="0x27" width="4" datatype="char"
-    class="field-table-type">
-    <doc>
-      Single unicode character in UTF-32 encoding
-    </doc>
-  </constant>
-
-  <!--
-    0x30 - 0x3f: Fixed width types - 8 octets
-  -->
-
-  <constant name="field-table-eight-octets" value="0x30" width="8" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Eight octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-signed-long" value="0x31" width="8" datatype="signed-integer"
-    class="field-table-type">
-    <doc>
-      64-bit signed integral value
-    </doc>
-  </constant>
-
-  <constant name="field-table-unsigned-long" value="0x32" width="8" datatype="unsigned-integer"
-    class="field-table-type">
-    <doc>
-      64-bit unsigned integral value
-    </doc>
-  </constant>
-
-  <constant name="field-table-double" value="0x33" width="8" datatype="ieee-float"
-    class="field-table-type">
-    <doc>
-      Double precision IEEE 754 floating point
-    </doc>
-  </constant>
-
-  <constant name="field-table-datetime" value="0x38" width="8" datatype="special"
-    class="field-table-type">
-    <doc>
-      Datetime in POSIX time_t format
-    </doc>
-  </constant>
-
-  <!--
-    0x40 - 0x4f: Fixed width types - 16 octets
-  -->
-
-  <constant name="field-table-sixteen-octets" value="0x40" width="16" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Sixteen octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-uuid" value="0x48" width="16" datatype="special"
-    class="field-table-type">
-    <doc>
-      UUID as defined by RFC4122
-    </doc>
-  </constant>
-
-  <!--
-    0x50 - 0x5f: Fixed width types - 32 octets
-  -->
-
-  <constant name="field-table-thirty-two-octets" value="0x50" width="32" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Thirty two octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <!--
-    0x60 - 0x6f: Fixed width types - 64 octets
-  -->
-
-  <constant name="field-table-sixty-four-octets" value="0x60" width="64" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Sixty four octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <!--
-    0x70 - 0x7f: Fixed width types - 128 octets
-  -->
-
-  <constant name="field-table-128-octets" value="0x70" width="128" datatype="binary"
-    class="field-table-type">
-    <doc>
-      One hundred and twenty eight octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <!--
-    0x80 - 0x8f: Variable length - one byte length field (up to 255 octets)
-  -->
-
-  <constant name="field-table-short-binary" value="0x80" lfwidth="1" datatype="binary"
-    class="field-table-type">
-    <doc>
-      A sequence of up to 255 octets representing opaque binary data
-    </doc>
-  </constant>
-
-  <constant name="field-table-short-string" value="0x84" lfwidth="1" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of up to 255 characters in the iso-8859-15 character set
-    </doc>
-  </constant>
-
-  <constant name="field-table-short-utf8-string" value="0x85" lfwidth="1" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most
-      255 bytes
-    </doc>
-  </constant>
-
-  <constant name="field-table-short-utf16-string" value="0x86" lfwidth="1" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most
-      255 bytes
-    </doc>
-  </constant>
-
-  <constant name="field-table-short-utf32-string" value="0x87" lfwidth="1" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most
-      255 bytes (i.e. of 0-63 utf32 characters)
-    </doc>
-  </constant>
-
-  <!--
-    0x90 - 0x9f: Variable length types - two byte length field (up to 65535 octets)
-  -->
-
-  <constant name="field-table-binary" value="0x90" lfwidth="2" datatype="binary"
-    class="field-table-type">
-    <doc>
-      A sequence of up to 65535 octets representing opaque binary data
-    </doc>
-  </constant>
-
-  <constant name="field-table-string" value="0x94" lfwidth="2" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of up to 65535 characters in the iso-8859-15 character set
-    </doc>
-  </constant>
-
-  <constant name="field-table-utf8-string" value="0x95" lfwidth="2" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most
-      65535 bytes
-    </doc>
-  </constant>
-
-  <constant name="field-table-utf16-string" value="0x96" lfwidth="2" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most
-      65535 bytes
-    </doc>
-  </constant>
-
-  <constant name="field-table-utf32-string" value="0x97" lfwidth="2" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most
-      65535 bytes (i.e. of 0-16383 utf32 characters)
-    </doc>
-  </constant>
-
-  <!--
-    0xa0 - 0xaf: Variable length types - four byte length field (up to 4294967295 octets)
-  -->
-
-  <constant name="field-table-long-binary" value="0xa0" lfwidth="4" datatype="binary"
-    class="field-table-type">
-    <doc>
-      A sequence of up to 4294967295 octets representing opaque binary data
-    </doc>
-  </constant>
-
-  <constant name="field-table-long-string" value="0xa4" lfwidth="4" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of up to 4294967295 characters in the iso-8859-15 character set
-    </doc>
-  </constant>
-
-  <constant name="field-table-long-utf8-string" value="0xa5" lfwidth="4" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most
-      4294967295 bytes
-    </doc>
-  </constant>
-
-  <constant name="field-table-long-utf16-string" value="0xa6" lfwidth="4" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most
-      4294967295 bytes
-    </doc>
-  </constant>
-
-  <constant name="field-table-long-utf32-string" value="0xa7" lfwidth="4" datatype="string"
-    class="field-table-type">
-    <doc>
-      A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most
-      4294967295 bytes (i.e. of 0-1073741823 utf32 characters)
-    </doc>
-  </constant>
-
-  <constant name="field-table-table" value="0xa8" lfwidth="4" datatype="field-table"
-    class="field-table-type">
-    <doc>
-      A field table following the encoding specification given here
-    </doc>
-  </constant>
-
-  <constant name="field-table-sequence" value="0xa9" lfwidth="4" datatype="sequence"
-    class="field-table-type">
-    <doc>
-      A sequence is a series of consecutive type-value pairs; using the same type designators as the
-      field table
-    </doc>
-  </constant>
-
-  <constant name="field-table-array" value="0xaa" lfwidth="4" datatype="array"
-    class="field-table-type">
-    <doc>
-      An array represents a collection of values of the same type. The array is encoded as a single
-      octet type designator (using the same system as given here for the field table), followed by a
-      four-octet unsigned integer which represents the number of elements in the collection,
-      followed by the encoding of that number of values of the given type
-    </doc>
-  </constant>
-
-  <!--
-    0xb0 - 0xbf: Reserved
-  -->
-
-  <!--
-    0xc0 - 0xcf:Fixed width types - 5 octets
-  -->
-
-  <constant name="field-table-five-octets" value="0xc0" width="5" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Five octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-decimal" value="0xc8" width="5" datatype="decimal"
-    class="field-table-type">
-    <doc>
-      Encoded as an octet representing the number of decimal places followed by a signed 4 octet
-      integer. The 'decimals' octet is not signed
-    </doc>
-  </constant>
-
-  <!--
-    0xd0 - 0xdf: Fixed width types - 9 octets
-  -->
-
-  <constant name="field-table-nine-octets" value="0xd0" width="9" datatype="binary"
-    class="field-table-type">
-    <doc>
-      Eight octets of unspecified binary encoding
-    </doc>
-  </constant>
-
-  <constant name="field-table-long-decimal" value="0xd8" width="9" datatype="decimal"
-    class="field-table-type">
-    <doc>
-      Encoded as an octet representing the number of decimal places followed by a signed 8 octet
-      integer. The 'decimals' octet is not signed
-    </doc>
-  </constant>
-
-  <!--
-    0xe0 - 0xef: Reserved
-  -->
-
-  <!--
-    0xf0 - 0xff: Zero-length types
-  -->
-
-  <constant name="field-table-void" value="0xf0" width="0" datatype="void"
-    class="field-table-type">
-    <doc>
-      The void type
-    </doc>
-  </constant>
-
-  <!--
-    ======================================================
-    ==       DOMAIN TYPES
-    ======================================================
-  -->
-
-  <domain name="access-ticket" type="short" label="access ticket granted by server">
-    <doc>
-      An access ticket granted by the server for a certain set of access rights within a specific
-      realm. Access tickets are valid within the session where they were created, and expire when
-      the session closes.
-    </doc>
-    <assert check="ne" value="0" />
-  </domain>
-
-  <domain name="class-id" type="short">
-    <doc>
-      <!-- TODO: Description required for docs -->
-    </doc>
-  </domain>
-
-  <domain name="method-id" type="short">
-    <doc>
-      <!-- TODO: Description required for docs -->
-    </doc>
-  </domain>
-
-  <domain name="consumer-tag" type="shortstr" label="consumer tag">
-    <doc>
-      Identifier for the consumer, valid within the current connection.
-    </doc>
-  </domain>
-
-  <domain name="delivery-tag" type="longlong" label="server-assigned delivery tag">
-    <doc>
-      The server-assigned and session-specific delivery tag
-    </doc>
-    <rule name="session-local">
-      <doc>
-        The delivery tag is valid only within the session from which the message was received. i.e.
-        A client MUST NOT receive a message on one session and then acknowledge it on another.
-      </doc>
-    </rule>
-    <rule name="non-zero">
-      <doc>
-        The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use,
-        meaning "all messages so far received".
-      </doc>
-    </rule>
-    <assert check="ne" value="0" />
-  </domain>
-
-  <domain name="exchange-name" type="shortstr" label="exchange name">
-    <doc>
-      The exchange name is a client-selected string that identifies the exchange for publish
-      methods. Exchange names may consist of any mixture of digits, letters, and underscores.
-      Exchange names are scoped by the virtual host.
-    </doc>
-    <assert check="regexp" value="[a-zA-Z0-9_]{1,127}">
-      <doc>
-        This regular expression checks that all characters are one of a-z (lower case), A-Z (upper
-        case), 0-9 (any digit) and the underscore character. There may be between 1 and 127 of these
-        characters.
-      </doc>
-    </assert>
-  </domain>
-
-  <domain name="known-hosts" type="shortstr" label="list of known hosts">
-    <doc>
-      Specifies the list of equivalent or alternative hosts that the server knows about, which will
-      normally include the current server itself. Clients can cache this information and use it when
-      reconnecting to a server after a failure. This field may be empty.
-    </doc>
-  </domain>
-
-  <domain name="message-id" type="uuid">
-    <doc>
-      Message-id is an optional property of UUID type which uniquly identifies a message within the
-      message system. The message producer is usually responsible for setting the message-id. Note
-      that the server may discard a message as a duplicate if the value of the message-id matches
-      that of a previously received message.
-    </doc>
-    <rule name="unique">
-      <doc>
-        A message MUST be unique within a given server instance. A message SHOULD be globally unique
-        (i.e. across different systems).
-      </doc>
-    </rule>
-    <rule name="immutable">
-      <doc>
-        A message ID is immutable. Once set, a message-id MUST NOT be changed or reassigned, even if
-        the message is replicated, resent or sent to multiple queues.
-      </doc>
-    </rule>
-  </domain>
-
-  <domain name="no-ack" type="bit" label="no acknowledgement needed">
-    <doc>
-      If this field is set the server does not expect acknowledgements for messages. That is, when a
-      message is delivered to the client the server automatically and silently acknowledges it on
-      behalf of the client. This functionality increases performance but at the cost of reliability.
-      Messages can get lost if a client dies before it can deliver them to the application.
-    </doc>
-  </domain>
-
-  <domain name="no-local" type="bit" label="do not deliver own messages">
-    <doc>
-      If the no-local field is set the server will not send messages to the connection that
-      published them.
-    </doc>
-  </domain>
-
-  <domain name="path" type="shortstr">
-    <doc>
-      Must start with a slash "/" and continue with path names separated by slashes. A path name
-      consists of any combination of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:].
-    </doc>
-    <assert check="notnull" />
-    <assert check="syntax" rule="path" />
-    <assert check="length" value="127" />
-  </domain>
-
-  <domain name="peer-properties" type="table">
-    <doc>
-      This string provides a set of peer properties, used for identification, debugging, and general
-      information.
-    </doc>
-  </domain>
-
-  <domain name="queue-name" type="shortstr" label="queue name">
-    <doc>
-      The queue name identifies the queue within the vhost. Queue names must have a length of
-      between 1 and 255 chatacters inclusive, must start with a digit, letter or underscores ('_')
-      character, and must be otherwise encoded in UTF-8.
-    </doc>
-    <assert check="regexp" value="[a-zA-Z0-9_].{0,254}">
-      <doc>
-        This regular expression checks that the first character is one of a-z (lower case), A-Z
-        (upper case), 0-9 (any digit) and the underscore character. Following may be between 0 and
-        254 characters of any value.
-      </doc>
-    </assert>
-  </domain>
-
-  <domain name="redelivered" type="bit" label="message is being redelivered">
-    <doc>
-      This indicates that the message has been previously delivered to this or another client.
-    </doc>
-    <rule name="implementation">
-      <doc>
-        The server SHOULD try to signal redelivered messages when it can. When redelivering a
-        message that was not successfully acknowledged, the server SHOULD deliver it to the original
-        client if possible.
-      </doc>
-      <doc type="scenario">
-        Create a shared queue and publish a message to the queue. Consume the message using explicit
-        acknowledgements, but do not acknowledge the message. Close the connection, reconnect, and
-        consume from the queue again. The message should arrive with the redelivered flag set.
-      </doc>
-    </rule>
-    <rule name="hinting">
-      <doc>
-        The client MUST NOT rely on the redelivered field but should take it as a hint that the
-        message may already have been processed. A fully robust client must be able to track
-        duplicate received messages on non-transacted, and locally-transacted sessions.
-      </doc>
-    </rule>
-  </domain>
-
-  <domain name="rfc1982-long" type="long" label="serial number with arithmetic per RFC1982">
-    <doc>
-      Serial number defined in RFC1982 which defines the arithmatic, operators and ranges of such
-      numbers.
-    </doc>
-  </domain>
-
-  <domain name="reply-code" type="short" label="reply code from server">
-    <doc>
-      The reply code. The AMQ reply codes are defined as constants at the start of this formal
-      specification.
-    </doc>
-    <assert check="notnull" />
-  </domain>
-
-  <domain name="reply-text" type="shortstr" label="localised reply text">
-    <doc>
-      The localised reply text. This text can be logged as an aid to resolving issues.
-    </doc>
-    <assert check="notnull" />
-  </domain>
-
-  <!-- Domains for the message class -->
-
-  <domain name="duration" type="longlong" label="duration in milliseconds">
-    <doc>
-        Duration of an event or process measured in milliseconds.
-    </doc>
-  </domain>
-
-  <domain name="offset" type="longlong" label="offset into a message body">
-    <doc>
-        Offset in bytes into a message body.
-    </doc>
-  </domain>
-
-  <domain name="reference" type="longstr" label="pointer to a message body">
-    <doc>
-        Identifier to be used as a reference to a message body.
-    </doc>
-  </domain>
-
-  <domain name="destination" type="shortstr" label="destination for a message">
-    <doc>
-      Specifies the destination to which the message is to be transferred. The destination can be
-      empty, meaning the default exchange or consumer.
-    </doc>
-  </domain>
-
-  <domain name="reject-code" type="short" label="reject code for transfer">
-    <doc>
-      Code specifying the reason for a message reject.
-    </doc>
-    <rule name="allowed-values">
-      <doc>
-        The reject code must be one of 0 (generic) or 1 (immediate delivery was attempted but
-        failed).
-      </doc>
-    </rule>
-  </domain>
-
-  <domain name="reject-text" type="shortstr" label="informational text for message reject">
-    <doc>
-      String describing the reason for a message transfer rejection.
-    </doc>
-  </domain>
-
-  <domain name="security-token" type="longstr" label="security token">
-    <doc>
-      A security token used for authentication, replay prevention, and encrypted message bodies.
-    </doc>
-  </domain>
-
-  <domain name="reply-to">
-    <struct size="short" pack="short">
-      <field name="exchange-name" domain="exchange-name" />
-      <field name="routing-key" domain="shortstr" />
-    </struct>
-  </domain>
-
-  <domain name="confirm-mode" type="octet" label="indicates a confirmation mode">
-    <doc>
-      Controls whether message transfer needs to be confirmed.
-
-      One of:
-        - off (0): confirmation is not required, once a message has been transferred in pre-acquire
-                   mode (or once acquire has been sent in no-acquire mode) the message is considered
-                   transferred
-
-        - on  (1): an acquired message (whether acquisition was implicit as in pre-acquire mode or
-                   explicit as in no-acquire mode) is not considered transferred until the original
-                   transfer is complete (signaled via execution.complete)
-    </doc>
-  </domain>
-
-  <domain name="acquire-mode" type="octet" label="indicates the transfer mode">
-    <doc>
-      Indicates whether a transferred message can be considered as automatically acquired or whether
-      an explicit request is necessary in order to acquire it.
-
-      One of:
-        - no-acquire  (0): the message must be explicitly acquired
-
-        - pre-acquire (1): the message is acquired when the transfer starts
-    </doc>
-  </domain>
-
-  <!-- message header domains -->
-
-  <domain name="delivery-properties">
-    <struct size="long" pack="short" type="0">
-      <field name="discard-unroutable" domain="bit" label="controls discard of unroutable messages">
-        <doc>
-          If set on a message that is not routable the broker can discard it. If not set unroutable
-          should be handled by reject when confirmation is on or by routing to the
-          alternate-exchange if defined when confirmation is off.
-        </doc>
-      </field>
-
-      <field name="redelivered" domain="redelivered" label="redelivery flag">
-        <doc>
-          This boolean flag indicates that the message has been previously delivered to this or
-          another client.
-        </doc>
-      </field>
-
-      <field name="priority" domain="octet" label="message priority, 0 to 9">
-        <doc>
-          Message priority, which can be between 0 and 9. Messages with higher priorities may be
-          delivered before those with lower priorities.
-        </doc>
-      </field>
-
-      <field name="delivery-mode" domain="octet" label="message persistence">
-        <doc>
-          The delivery mode may be non-persistent (1) or persistent (2). A persistent message is one
-          which must be stored on a persistent medium (usually hard drive) at every stage of
-          delivery so that it will not be lost in event of failure (other than the medium itself).
-          This is normally accomplished with some additional overhead. A persistent message may be
-          delivered more than once if there is uncertainty about the state of its delivery after a
-          failure and recovery.
-
-          Conversely, a non-persistent message may be lost in event of a failure, but the nature of
-          the communication is such that an occasional message loss is tolerable. This is the lowest
-          overhead mode. Non-persistent messages are delivered at most once only.
-        </doc>
-      </field>
-
-      <field name="ttl" domain="duration" label="time to live">
-        <doc>
-          If this is set to a non zero value then a message expiration time will be computed based
-          on the current time plus this value. Messages that live longer than their expiration time
-          will be discarded (or dead lettered).
-        </doc>
-        <rule name="ttl-decrement">
-          <doc>
-            If a message is transferred between brokers before delivery to a final consumer the ttl
-            should be decremented before peer to peer transfer and both timestamp and expiration
-            should be cleared.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="timestamp" domain="timestamp" label="message timestamp">
-        <doc>
-          The timestamp is set by the broker on arrival of the message.
-        </doc>
-      </field>
-
-      <field name="expiration" domain="timestamp" label="message expiration time">
-        <doc>
-          The expiration header assigned by the broker. After receiving the message the broker sets
-          expiration to the sum of the ttl specified in the publish method and the current time.
-          (ttl=expiration - timestamp)
-        </doc>
-      </field>
-
-      <field name="exchange" domain="exchange-name" label="originating exchange">
-        <doc>
-          The exchange name is a client-selected string that identifies the exchange for transfer
-          methods. Exchange names may consist of any mixture of digits, letters, and underscores.
-          Exchange names are scoped by the virtual host.
-        </doc>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="message routing key">
-        <doc>
-          The value of the key determines to which queue the exchange will send the message. The way
-          in which keys are used to make this routing decision depends on the type of exchange to
-          which the message is sent. For example, a direct exchange will route a message to a queue
-          if that queue is bound to the exchange with an identical key to that of the message.
-        </doc>
-      </field>
-    </struct>
-  </domain>
-
-  <domain name="message-properties">
-    <struct size="long" pack="short" type="1">
-      <field name="content-length" domain="longlong" label="length of content in bytes">
-        <doc>
-          The length of the message content in bytes.
-        </doc>
-      </field>
-
-      <field name="message-id" domain="shortstr" label="application message identifier">
-        <doc>
-          This is a unique identifier for the message that is guaranteed to be unique across
-          multiple instances, sessions and in time. This allows duplicate messages to be detected.
-          This may be a UUID. Note that this is usually set by the server when it first receives a
-          message.
-
-          If a client wishes to identify a message, it should use the correlation-id instead.
-        </doc>
-      </field>
-
-      <field name="correlation-id" domain="shortstr" label="application correlation identifier">
-        <doc>
-          This is a client-specific id that may be used to mark or identify messages between
-          clients. The server ignores this field.
-        </doc>
-      </field>
-
-      <field name="reply-to" domain="reply-to" label="destination to reply to">
-        <doc>
-          The destination of any message that is sent in reply to this message.
-        </doc>
-      </field>
-
-      <field name="content-type" domain="shortstr" label="MIME content type">
-        <doc>
-          The RFC-2046 MIME type for the message content (such as "text/plain"). This is set by the
-          originating client.
-        </doc>
-      </field>
-
-      <field name="content-encoding" domain="shortstr" label="MIME content encoding">
-        <doc>
-          The encoding for character-based message content. This is set by the originating client.
-          Examples include UTF-8 and ISO-8859-16.
-        </doc>
-      </field>
-
-      <field name="type" domain="shortstr" label="message type name">
-        <doc>
-          The JMS message type.
-        </doc>
-      </field>
-
-      <field name="user-id" domain="shortstr" label="creating user id">
-        <doc>
-          The identity of the user responsible for producing the message.
-        </doc>
-      </field>
-
-      <field name="app-id" domain="shortstr" label="creating application id">
-        <doc>
-          The identity of the client application responsible for producing the message.
-        </doc>
-      </field>
-
-      <field name="transaction-id" domain="shortstr" label="distributed transaction id">
-        <doc>
-          An identifier that links this message to a distributed transaction.
-        </doc>
-      </field>
-
-      <field name="security-token" domain="security-token" label="security token">
-        <doc>
-          A security token used for authentication, replay prevention, and encrypted message bodies.
-        </doc>
-      </field>
-
-      <field name="application-headers" domain="table" label="application specific headers table">
-        <doc>
-          This is a collection of user-defined headers or properties which may be set by the
-          producing client and retrieved by the consuming client. Similar to JMS Properties.
-        </doc>
-      </field>
-    </struct>
-  </domain>
-
-  <!-- Domians for DTX -->
-
-  <domain name="xid" type="longstr" label="Dtx branch identifier">
-    <doc>
-      An xid uniquely identifies a transaction branch.
-    </doc>
-
-    <rule name="implementation">
-      <doc>
-        xid contains a format identifier, two length fields and a data field:
-
-        format_id long
-
-        gtrid_length octet
-
-        bqual_length octet
-
-        data gtrid_length + bqual_length
-      </doc>
-      <doc type="picture">
-                4         1   1        g            b
-        +---+---+---+---+---+---+---+-  -+---+---+-  -+---+
-        |   format_id   | g | b |   txn-id   |   br-id    |
-        +---+---+---+---+---+---+---+-  -+---+---+-  -+---+
-        0               4   5   6           6+g         6+g+b
-      </doc>
-      <doc>
-        format_id: an implementation specific format identifier
-
-        gtrid_length: how many bytes of this form the transaction id
-
-        bqual_length: how many bytes of this form the branch id
-
-        data: a sequence of octets of at most 128 bytes containing the txn id and the
-              branch id
-
-        Note - The sum of the two lengths must equal the length of the data field.
-      </doc>
-    </rule>
-  </domain>
-
-  <!-- Domains for session class -->
-
-  <domain name="detached-lifetime" type="long" label="possibly unbounded duration in seconds">
-    <doc>
-      Detached-lifetime is an integer encoded as follows:
-
-        * the maximum representable value means unbounded - the maximum length permitted by the peer
-
-        * otherwise, any other value (including zero) is the number of seconds the session's state
-          is retained during periods when no channel (or equivalent) is attached to the session
-          (DetachedLifetimeFinite above).
-    </doc>
-  </domain>
-
-  <domain name="session-id" type="uuid" label="session identifier" />
-
-  <!-- Domains for the execution class -->
-
-  <domain name="correlation" type="rfc1982-long-set">
-    <doc>
-      Identifies a set of commands inside the window of open conversations.
-    </doc>
-  </domain>
-  <domain name="command-id" type="long"/>
-  <domain name="long-struct" type="long-struct">
-    <doc>
-      Any typed struct whose size width is long.
-    </doc>
-  </domain>
-
-  <domain name="execution-header">
-    <doc>
-      The execution header appears on commands after the class and method id, but prior to method
-      arguments.
-    </doc>
-    <struct size="octet" pack="octet">
-      <field name="sync" domain="bit" label="request notification of completion for a specific command">
-        <doc>
-          Indicates that the peer sending the request wants to be notified when this command is
-          completed.
-        </doc>
-      </field>
-    </struct>
-  </domain>
-
-  <!-- Elementary domains -->
-  <domain name="bit" type="bit" label="single bit" />
-  <domain name="octet" type="octet" label="single octet" />
-  <domain name="short" type="short" label="16-bit integer" />
-  <domain name="long" type="long" label="32-bit integer" />
-  <domain name="longlong" type="longlong" label="64-bit integer" />
-  <domain name="shortstr" type="shortstr" label="short string" />
-  <domain name="longstr" type="longstr" label="long string" />
-  <domain name="timestamp" type="timestamp" label="64-bit POSIX timestamp" />
-  <domain name="table" type="table" label="field table" />
-  <domain name="uuid" type="uuid" label="UUID (RFC4122 section 4.1.2) - 16 octets" />
-
-  <domain name="content" type="content" label="message content">
-    <doc>
-      Content of a message. It should be considered opaque binary data. The length of the message is
-      determined from the context of this type (the message length field of the message.transfer
-      method).
-    </doc>
-  </domain>
-
-  <domain name="rfc1982-long-set" type="rfc1982-long-set" label="ranged set representation">
-    <doc>
-      Set of pairs of RFC-1982 numbers representing a discontinuous range. Each pair represents a
-      closed interval within the list.
-
-      For example, the set (1,3), (6,6), (8,9) represents the sequence 1,2,3,6,8,9.
-    </doc>
-  </domain>
-
-  <!-- == Class: connection ==================================================================== -->
-
-  <class name="connection" index="10" label="work with socket connections">
-    <doc>
-      The connection class provides methods for a client to establish a network connection to a
-      server, and for both peers to operate the connection thereafter.
-    </doc>
-
-    <doc type="grammar">
-      connection        = open-connection
-                          *use-connection
-                          close-connection
-      open-connection   = C:protocol-header
-                          S:START C:START-OK
-                          *challenge
-                          S:TUNE C:TUNE-OK
-                          C:OPEN S:OPEN-OK | S:REDIRECT
-      challenge         = S:SECURE C:SECURE-OK
-      use-connection    = *channel
-      close-connection  = C:CLOSE S:CLOSE-OK
-                        / S:CLOSE C:CLOSE-OK
-    </doc>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MUST" />
-
-    <!-- - Method: connection.start  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="start" synchronous="1" index="10" label="start connection negotiation">
-      <doc>
-        This method starts the connection negotiation process by telling the client the protocol
-        version that the server proposes, along with a list of security mechanisms which the client
-        can use for authentication.
-      </doc>
-
-      <rule name="protocol-name">
-        <doc>
-          If the server cannot support the protocol specified in the protocol header, it MUST close
-          the socket connection without sending any response method.
-        </doc>
-        <doc type="scenario">
-          The client sends a protocol header containing an invalid protocol name. The server must
-          respond by closing the connection.
-        </doc>
-      </rule>
-
-      <rule name="server-support">
-        <doc>
-          The server MUST provide a protocol version that is lower than or equal to that requested
-          by the client in the protocol header.
-        </doc>
-        <doc type="scenario">
-          The client requests a protocol version that is higher than any valid implementation, e.g.
-          9.0. The server must respond with a current protocol version, e.g. 1.0.
-        </doc>
-      </rule>
-
-      <rule name="client-support">
-        <doc>
-          If the client cannot handle the protocol version suggested by the server it MUST close the
-          socket connection.
-        </doc>
-        <doc type="scenario">
-          The server sends a protocol version that is lower than any valid implementation, e.g. 0.1.
-          The client must respond by closing the connection.
-        </doc>
-      </rule>
-
-      <chassis name="client" implement="MUST" />
-
-      <response name="start-ok" />
-
-      <field name="version-major" domain="octet" label="protocol major version">
-        <doc>
-          The protocol version, major component, as transmitted in the AMQP protocol header. This,
-          combined with the protocol minor component fully describe the protocol version, which is
-          written in the format major-minor. Hence, with major=1, minor=3, the protocol version
-          would be "1-3".
-        </doc>
-      </field>
-
-      <field name="version-minor" domain="octet" label="protocol minor version">
-        <doc>
-          The protocol version, minor component, as transmitted in the AMQP protocol header. This,
-          combined with the protocol major component fully describe the protocol version, which is
-          written in the format major-minor. Hence, with major=1, minor=3, the protocol version
-          would be "1-3".
-        </doc>
-      </field>
-
-      <field name="server-properties" domain="peer-properties" label="server properties">
-        <rule name="required-fields">
-          <doc>
-            The properties SHOULD contain at least these fields: "host", specifying the server host
-            name or address, "product", giving the name of the server product, "version", giving the
-            name of the server version, "platform", giving the name of the operating system,
-            "copyright", if appropriate, and "information", giving other general information.
-          </doc>
-          <doc type="scenario">
-            Client connects to server and inspects the server properties. It checks for the presence
-            of the required fields.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="mechanisms" domain="longstr" label="available security mechanisms">
-        <doc>
-          A list of the security mechanisms that the server supports, delimited by spaces.
-        </doc>
-        <assert check="notnull" />
-      </field>
-
-      <field name="locales" domain="longstr" label="available message locales">
-        <doc>
-          A list of the message locales that the server supports, delimited by spaces. The locale
-          defines the language in which the server will send reply texts.
-        </doc>
-
-        <rule name="required-support">
-          <doc>
-            The server MUST support at least the en_US locale.
-          </doc>
-          <doc type="scenario">
-            Client connects to server and inspects the locales field. It checks for the presence of
-            the required locale(s).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-    </method>
-
-    <!-- - Method: connection.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="start-ok" synchronous="1" index="11"
-      label="select security mechanism and locale">
-      <doc>
-        This method selects a SASL security mechanism.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="client-properties" domain="peer-properties" label="client properties">
-        <rule name="required-fields">
-          <!-- This rule is not testable from the client side -->
-          <doc>
-            The properties SHOULD contain at least these fields: "product", giving the name of the
-            client product, "version", giving the name of the client version, "platform", giving the
-            name of the operating system, "copyright", if appropriate, and "information", giving
-            other general information.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="mechanism" domain="shortstr" label="selected security mechanism">
-        <doc>
-          A single security mechanisms selected by the client, which must be one of those specified
-          by the server.
-        </doc>
-
-        <rule name="security">
-          <doc>
-            The client SHOULD authenticate using the highest-level security profile it can handle
-            from the list provided by the server.
-          </doc>
-        </rule>
-
-        <rule name="validity">
-          <doc>
-            If the mechanism field does not contain one of the security mechanisms proposed by the
-            server in the Start method, the server MUST close the connection without sending any
-            further data.
-          </doc>
-          <doc type="scenario">
-            Client connects to server and sends an invalid security mechanism. The server must
-            respond by closing the connection (a socket close, with no connection close
-            negotiation).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="response" domain="longstr" label="security response data">
-        <doc>
-          A block of opaque data passed to the security mechanism. The contents of this data are
-          defined by the SASL security mechanism.
-        </doc>
-        <assert check="notnull" />
-      </field>
-
-      <field name="locale" domain="shortstr" label="selected message locale">
-        <doc>
-          A single message locale selected by the client, which must be one of those specified by
-          the server.
-        </doc>
-        <assert check="notnull" />
-      </field>
-    </method>
-
-    <!-- - Method: connection.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="secure" synchronous="1" index="20" label="security mechanism challenge">
-      <doc>
-        The SASL protocol works by exchanging challenges and responses until both peers have
-        received sufficient information to authenticate each other. This method challenges the
-        client to provide more information.
-      </doc>
-
-      <chassis name="client" implement="MUST" />
-
-      <response name="secure-ok" />
-
-      <field name="challenge" domain="longstr" label="security challenge data">
-        <doc>
-          Challenge information, a block of opaque binary data passed to the security mechanism.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: connection.secure-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="secure-ok" synchronous="1" index="21" label="security mechanism response">
-      <doc>
-        This method attempts to authenticate, passing a block of SASL data for the security
-        mechanism at the server side.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="response" domain="longstr" label="security response data">
-        <doc>
-          A block of opaque data passed to the security mechanism. The contents of this data are
-          defined by the SASL security mechanism.
-        </doc>
-        <assert check="notnull" />
-      </field>
-    </method>
-
-    <!-- - Method: connection.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="tune" synchronous="1" index="30" label="propose connection tuning parameters">
-      <doc>
-        This method proposes a set of connection configuration values to the client. The client can
-        accept and/or adjust these.
-      </doc>
-
-      <chassis name="client" implement="MUST" />
-
-      <response name="tune-ok" />
-
-      <field name="channel-max" domain="short" label="proposed maximum channels">
-        <doc>
-          The maximum total number of channels that the server allows per connection. Zero means
-          that the server does not impose a fixed limit, but the number of allowed channels may be
-          limited by available server resources.
-        </doc>
-      </field>
-
-      <field name="frame-max" domain="long" label="proposed maximum frame size">
-        <doc>
-          The largest frame size that the server proposes for the connection. The client can
-          negotiate a lower value. Zero means that the server does not impose any specific limit but
-          may reject very large frames if it cannot allocate resources for them.
-        </doc>
-
-        <rule name="minimum">
-          <doc>
-            Until the frame-max has been negotiated, both peers MUST accept frames of up to
-            frame-min-size octets large, and the minimum negotiated value for frame-max is also
-            frame-min-size.
-          </doc>
-          <doc type="scenario">
-            Client connects to server and sends a large properties field, creating a frame of
-            frame-min-size octets. The server must accept this frame.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="heartbeat" domain="short" label="desired heartbeat delay">
-        <!-- TODO 0.82 - the heartbeat negotiation mechanism was changed during implementation
-          because the model documented here does not actually work properly.  The best model we
-          found is that the server proposes a heartbeat value to the client; the client can reply
-          with zero, meaning 'do not use heartbeats (as documented here), or can propose its own
-          heartbeat value, which the server should then accept.  This is different from the model
-          here which is disconnected - e.g. each side requests a heartbeat independently.  Basically
-          a connection is heartbeated in both ways, or not at all, depending on whether both peers
-          support heartbeating or not, and the heartbeat value should itself be chosen by the client
-          so that remote links can get a higher value.  Also, the actual heartbeat mechanism needs
-          documentation, and is as follows: so long as there is activity on a connection - in or out
-          - both peers assume the connection is active.  When there is no activity, each peer must
-          send heartbeat frames.  When no heartbeat frame is received after N cycles (where N is at
-          least 2), the connection can be considered to have died. /PH 2006/07/19
-        -->
-        <doc>
-          The delay, in seconds, of the connection heartbeat that the server wants. Zero means the
-          server does not want a heartbeat.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: connection.tune-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="tune-ok" synchronous="1" index="31"
-      label="negotiate connection tuning parameters">
-      <doc>
-        This method sends the client's connection tuning parameters to the server. Certain fields
-        are negotiated, others provide capability information.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="channel-max" domain="short" label="negotiated maximum channels">
-        <doc>
-          The maximum total number of channels that the client will use per connection.
-        </doc>
-
-        <rule name="upper-limit">
-          <doc>
-            If the client specifies a channel max that is higher than the value provided by the
-            server, the server MUST close the connection without attempting a negotiated close. The
-            server may report the error in some fashion to assist implementors.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-        <assert check="le" value="channel-max" />
-      </field>
-
-      <field name="frame-max" domain="long" label="negotiated maximum frame size">
-        <doc>
-          The largest frame size that the client and server will use for the connection. Zero means
-          that the client does not impose any specific limit but may reject very large frames if it
-          cannot allocate resources for them. Note that the frame-max limit applies principally to
-          content frames, where large contents can be broken into frames of arbitrary size.
-        </doc>
-
-        <rule name="minimum">
-          <doc>
-            Until the frame-max has been negotiated, both peers MUST accept frames of up to
-            frame-min-size octets large, and the minimum negotiated value for frame-max is also
-            frame-min-size.
-          </doc>
-        </rule>
-
-        <rule name="upper-limit">
-          <doc>
-            If the client specifies a frame max that is higher than the value provided by the
-            server, the server MUST close the connection without attempting a negotiated close. The
-            server may report the error in some fashion to assist implementors.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="heartbeat" domain="short" label="desired heartbeat delay">
-        <doc>
-          The delay, in seconds, of the connection heartbeat that the client wants. Zero means the
-          client does not want a heartbeat.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: connection.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="open" synchronous="1" index="40" label="open connection to virtual host">
-      <doc>
-        This method opens a connection to a virtual host, which is a collection of resources, and
-        acts to separate multiple application domains within a server. The server may apply
-        arbitrary limits per virtual host, such as the number of each type of entity that may be
-        used, per connection and/or in total.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="open-ok" />
-      <response name="redirect" />
-
-      <field name="virtual-host" domain="path" label="virtual host name">
-        <!-- TODO 0.82 - the entire vhost model needs review. This concept was prompted by the HTTP
-          vhost concept but does not fit very well into AMQP.  Currently we use the vhost as a 
-          "cluster identifier" which is inaccurate usage. /PH 2006/07/19
-        -->
-        <doc>
-          The name of the virtual host to work with.
-        </doc>
-
-        <rule name="separation">
-          <doc>
-            If the server supports multiple virtual hosts, it MUST enforce a full separation of
-            exchanges, queues, and all associated entities per virtual host. An application,
-            connected to a specific virtual host, MUST NOT be able to access resources of another
-            virtual host.
-          </doc>
-        </rule>
-
-        <rule name="security">
-          <doc>
-            The server SHOULD verify that the client has permission to access the specified virtual
-            host.
-          </doc>
-        </rule>
-        <assert check="regexp" value="^[a-zA-Z0-9/-_]+$" />
-      </field>
-
-      <field name="capabilities" domain="shortstr" label="required capabilities">
-        <doc>
-          The client can specify zero or more capability names, delimited by spaces. The server can
-          use this string to how to process the client's connection request.
-        </doc>
-      </field>
-
-      <field name="insist" domain="bit" label="insist on connecting to server">
-        <doc>
-          In a configuration with multiple collaborating servers, the server may respond to a
-          Connection.Open method with a Connection.Redirect. The insist option tells the server that
-          the client is insisting on a connection to the specified server.
-        </doc>
-        <rule name="behaviour">
-          <doc>
-            When the client uses the insist option, the server MUST NOT respond with a
-            Connection.Redirect method. If it cannot accept the client's connection request it
-            should respond by closing the connection with a suitable reply code.
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: connection.open-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="open-ok" synchronous="1" index="41" label="signal that connection is ready">
-      <doc>
-        This method signals to the client that the connection is ready for use.
-      </doc>
-
-      <chassis name="client" implement="MUST" />
-
-      <field name="known-hosts" domain="known-hosts" />
-    </method>
-
-    <!-- - Method: connection.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="redirect" synchronous="1" index="42" label="redirects client to other server">
-      <doc>
-        This method redirects the client to another server, based on the requested virtual host
-        and/or capabilities.
-      </doc>
-
-      <rule name="usage">
-        <doc>
-          When getting the Connection.Redirect method, the client SHOULD reconnect to the host
-          specified, and if that host is not present, to any of the hosts specified in the
-          known-hosts list.
-        </doc>
-      </rule>
-
-      <chassis name="client" implement="MUST" />
-
-      <field name="host" domain="shortstr" label="server to connect to">
-        <doc>
-          Specifies the server to connect to. This is an IP address or a DNS name, optionally
-          followed by a colon and a port number. If no port number is specified, the client should
-          use the default port number for the protocol.
-        </doc>
-        <assert check="notnull" />
-      </field>
-
-      <field name="known-hosts" domain="known-hosts" />
-    </method>
-
-    <!-- - Method: connection.close  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="close" synchronous="1" index="50" label="request a connection close">
-      <doc>
-        This method indicates that the sender wants to close the connection. This may be due to
-        internal conditions (e.g. a forced shut-down) or due to an error handling a specific method,
-        i.e. an exception. When a close is due to an exception, the sender provides the class and
-        method id of the method which caused the exception.
-      </doc>
-      <!-- TODO: The connection close mechanism needs to be reviewed from the ODF documentation and
-        better expressed as rules here. /PH 2006/07/20
-      -->
-
-      <rule name="stability">
-        <doc>
-          After sending this method any received method except the Close-OK method MUST be
-          discarded.
-        </doc>
-      </rule>
-
-      <chassis name="client" implement="MUST" />
-      <chassis name="server" implement="MUST" />
-
-      <response name="close-ok" />
-
-      <field name="reply-code" domain="reply-code" />
-      <field name="reply-text" domain="reply-text" />
-
-      <field name="class-id" domain="class-id" label="failing method class">
-        <doc>
-          When the close is provoked by a method exception, this is the class of the method.
-        </doc>
-      </field>
-
-      <field name="method-id" domain="method-id" label="failing method ID">
-        <doc>
-          When the close is provoked by a method exception, this is the ID of the method.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: connection.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="close-ok" synchronous="1" index="51" label="confirm a connection close">
-      <doc>
-        This method confirms a Connection.Close method and tells the recipient that it is safe to
-        release resources for the connection and close the socket.
-      </doc>
-
-      <rule name="reporting">
-        <doc>
-          A peer that detects a socket closure without having received a Close-Ok handshake method
-          SHOULD log the error.
-        </doc>
-      </rule>
-
-      <chassis name="client" implement="MUST" />
-      <chassis name="server" implement="MUST" />
-    </method>
-
-  </class>
-
-  <!-- == Class: session ======================================================================= -->
-
-  <class name="session" index="20" label="session control methods">
-    <doc>
-      The session class provides methods for a client to establish a session with a server and for
-      both peers to operate the session thereafter.
-    </doc>
-
-    <doc type="grammar">
-      session       = open-session
-                      *use-session
-                      close-session
-      open-session  = C:OPEN S:ATTACHED
-                    / C:RESUME S:ATTACHED
-      use-session   = C:FLOW S:FLOW-OK
-                    / S:FLOW C:FLOW-OK
-      close-session = C:SUSPEND S:DETACHED
-                    / C:CLOSE S:CLOSED
-                    / S:CLOSED
-                    / S:CLOSE C:CLOSED
-                    / C:CLOSED
-    </doc>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MUST" />
-
-    <!-- - Method: session.open  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="open" synchronous="1" index="10" label="open a session for use">
-      <doc>
-        This method opens a session with the server.
-
-        When the responding peer creates the session, it MUST create a new, appropriately-unique
-        name for the session and return this to the creator with the rest of the session details.
-
-        Note that the timer controlling a session's automatic expiry, if any, counts down
-        immediately from the moment of its creation, unless simultaneously with that moment a
-        channel (or equivalent) is attached to the session. For this reason, it is recommended that
-        network protocol mappings create sessions simultaneously with the creation and attachment of
-        their channel-equivalents, since a zero lease time is perfectly valid and indicates that the
-        session should be destroyed as soon as it first finds itself inactive.
-
-        During the period that a channel (or equivalent) is attached to a session, the session has
-        no deletion timer. Every time a channel is detached from a session such that the session is
-        left without any attached network-level entities, the timer is created, set to its declared
-        value and started.
-
-        Note that if the peer decides that the requested detached-lifetime timeout is too long,
-        either because the replying peer does not support sessions with non-zero requested timeouts,
-        or because the requested timeout exceeds some peer-specific limitation, it may substitute an
-        acceptable value for the detached-lifetime parameter in its reply to the creation request.
-        An exception is not required.
-      </doc>
-
-      <rule name="expiration">
-        <doc>
-          Whether the detachment is explicit or implicit, as a result of application action or of
-          application error, the channel (or equivalent) is detached from its session and the
-          session timer MUST start counting down as defined in session.open.
-        </doc>
-      </rule>
-
-      <rule name="channel-busy">
-        <!-- TODO: Figure out how to make this error conditional to stateful network mappings with
-          channels.
-        -->
-        <doc>
-          The client MUST NOT send session.open on a channel that is already associated with a
-          session. A "channel busy" connection exception will occur if the channel down which the
-          open request was sent was already attached to a session.
-        </doc>
-        <doc type="scenario">
-          Client sends session.open twice down the same channel.
-        </doc>
-      </rule>
-
-      <!--
-      <throws name="out-of-resources"/>
-      -->
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="attached" />
-
-      <field name="detached-lifetime" domain="detached-lifetime">
-        <doc>
-          The number of seconds the session's state is retained during periods when no channel (or
-          equivalent) is attached to the session.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.attached  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="attached" synchronous="1" index="11" label="signal that the session is ready">
-      <doc>
-        This method signals to the client that the session is ready for use.
-
-        Once a session.attached is received by the client, everything is in place for normal
-        transmission of frames. However, depending on the network protocol mapping in use, the
-        frame-id be undefined until certain control frames have been sent. Please see the specific
-        details for each protocol mapping.
-
-        If the attached session was freshly created, the session-id here will be a freshly-generated
-        UUID.
-
-        Note that the actual session detached-lifetime value, as decided by the peer, is returned
-        using this method. The value returned may not be the same as that requested in the
-        corresponding session creation request. In particular, a request for an unbounded
-        detached-lifetime of may be fulfilled by creation of a session with a bounded actual
-        lifetime parameter. The requesting peer SHOULD take the lifetime value returned as
-        authoritative for its own session-related record-keeping.
-      </doc>
-
-      <chassis name="client" implement="MUST" />
-
-      <field name="session-id" domain="session-id">
-        <doc>
-          The session identifier (a UUID) used to identify this session.
-        </doc>
-      </field>
-
-      <field name="detached-lifetime" domain="detached-lifetime">
-        <doc>
-          The number of seconds the session's state is retained during periods when no channel (or
-          equivalent) is attached to the session.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.flow  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="flow" synchronous="1" index="20" label="enable/disable flow from peer">
-      <doc>
-        This method asks the peer to pause or restart the flow of content data. This is a simple
-        flow-control mechanism that a peer can use to avoid overflowing its queues or otherwise
-        finding itself receiving more messages than it can process. Note that this method is not
-        intended for window control. The peer that receives a disable flow method should finish
-        sending the current content frame, if any, then pause.
-      </doc>
-
-      <rule name="initial-state">
-        <doc>
-          When a new session is opened, it is active (flow is active). Some applications assume that
-          sessions are inactive until started. To emulate this behaviour a client MAY open the
-          session, then pause it.
-        </doc>
-      </rule>
-
-      <rule name="bidirectional">
-        <doc>
-          When sending content frames, a peer SHOULD monitor the session for incoming methods and
-          respond to a Session.Flow as rapidly as possible.
-        </doc>
-      </rule>
-
-      <rule name="throttling">
-        <doc>
-          A peer MAY use the Session.Flow method to throttle incoming content data for internal
-          reasons, for example, when exchanging data over a slower connection.
-        </doc>
-      </rule>
-
-      <rule name="expected-behaviour">
-        <doc>
-          The peer that requests a Session.Flow method MAY disconnect and/or ban a peer that does
-          not respect the request. This is to prevent badly-behaved clients from overwhelming a
-          broker.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <response name="flow-ok" />
-
-      <field name="active" domain="bit" label="start/stop content frames">
-        <doc>
-          If true (1), the peer starts sending content frames. If false (0), the peer stops sending
-          content frames.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.flow-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="flow-ok" index="21" label="confirm a flow method">
-      <doc>
-        Confirms to the peer that a flow command was received and processed.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="active" domain="bit" label="current flow setting">
-        <doc>
-          Confirms the setting of the processed flow method: true (1) means the peer will start
-          sending or continue to send content frames; false (0) means it will not.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="close" index="40" label="request a session close">
-      <doc>
-        Requests that the receiving peer destroy a session, implicitly detaching any attached
-        channels or channel-equivalents.
-
-        Note that the reply, session.closed, is also used for asynchronous exception notifications.
-        For normal closure, such as in response to a session.close request, reason code 200 ("ok")
-        is to be used.
-      </doc>
-
-      <chassis name="client" implement="MUST" />
-      <chassis name="server" implement="MUST" />
-
-      <!-- 
-      <response name="closed" />
-      -->
-    </method>
-
-    <!-- - Method: session.closed  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="closed" index="41" label="notify of a session close">
-      <doc>
-        Notifies the receiver that not only has the current channel been detached from its
-        underlying session, but that the session itself has been destroyed.
-
-        This method confirms a session.close method and tells the recipient that it is safe to
-        release resources for the channel.
-
-        Note also that for normal closure, reason code 200 ("ok") is to be used.
-      </doc>
-
-      <chassis name="client" implement="MUST" />
-      <chassis name="server" implement="MUST" />
-
-      <field name="reply-code" domain="reply-code">
-        <doc>
-          The numeric reply code.
-        </doc>
-      </field>
-
-      <field name="reply-text" domain="reply-text">
-        <doc>
-          The localised reply text.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.resume  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="resume" index="50" label="resume an interrupted session">
-      <doc>
-        Attaches to an already-existing session.
-      </doc>
-
-      <rule name="session-busy">
-        <doc>
-          A "session busy" exception is returned if the session exists, but is not in a condition
-          where it can accept the requested attachment. Peers receiving this exception may wish to
-          retain their session state and retry the session.resume operation after a delay.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <response name="attached" />
-
-      <field name="session-id" domain="session-id">
-        <doc>
-          The session identifier (a UUID) used to identify this session.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.suspend - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="suspend" index="90" label="suspend the session">
-      <doc>
-        Indicates the sending peer wishes to detach from this session, but not necessarily to
-        destroy it.
-      </doc>
-
-      <!-- TODO: Ratify the inclusion of the chassis element in the XML. -->
-      <chassis name="server" implement="MAY" />
-
-      <response name="detached"/>
-    </method>
-
-    <!-- - Method: session.detached  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="detached" index="100" label="signal detachment of the session">
-      <doc>
-        Signal detachment from the session.
-      </doc>
-      <!-- TODO: Ratify the inclusion of the chassis element in the XML. -->
-      <chassis name="client" implement="MAY" />
-    </method>
-
-    <!-- - Method: session.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <!-- TODO: This method does not appear in any grammar as yet... -->
-    <method name="ack" index="110" label="acknowledge receipt of frames">
-      <doc>
-        Signals receipt of all frames such that frame-id &lt;= cumulative-seen-mark, or frame-id is
-        in the set defined by seen-frame-set. This can be sent spontaneously, or in response to
-        either session.solicit-ack or session.high-water-mark.
-
-        Note that an encoded acknowledgement frame carried over the TCP network mapping (in the
-        absence of cross-protocol use of a session) will never have any entries in its
-        seen-frame-set.
-
-        <!-- TODO: See chapter (TBD here) for how frame ids are computed. -->
-      </doc>
-
-      <rule name="unique-encoding">
-        <doc>
-          In order to ensure a canonical wire representation, the value cumulative-seen-mark +
-          1 must not be covered by the seen-frame-set.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="cumulative-seen-mark" domain="rfc1982-long" label="Low-water mark for seen ids">
-        <doc>
-          The low-water mark for seen frame-ids. All ids below this mark have been seen; above this
-          mark, there are gaps containing unseen ids (i.e. discontinuous). By definition, the first
-          frame-id above this mark (if it exists) is an unseen id.
-        </doc>
-      </field>
-
-      <field name="seen-frame-set" domain="rfc1982-long-set"
-        label="Set of discontinuous seen ids above cumulative-seen-mark">
-        <doc>
-          This set contains a sequence of discontinuous seen-frame-ids above the low-water mark
-          (i.e. above the first gap of unseen ids). In some transports where out-of-order delivery
-          is not possible (such as TCP), this set will always be empty.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.high-water-mark - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="high-water-mark" index="120" label="Inform the peer of most recent sent frame-id">
-      <doc>
-        Carries information about the highest (most recent) frame-id number that the sending peer
-        has sent through this session so far.
-
-        The receiver should issue a session.ack at the earliest possible opportunity.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="last-sent-mark" domain="rfc1982-long" label="Frame-id of last sent frame">
-        <doc>
-          Highest frame-id sent by the sending peer through this session so far.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: session.solicit-ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="solicit-ack" index="130" label="request an ack">
-      <doc>
-        Requests a session.ack from the peer. The peer should issue one at the earliest possible
-        opportunity.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-    </method>
-  </class>
-
-  <!-- == Class: access ======================================================================== -->
-
-  <!-- TODO 0.82 - this class must be implemented by two teams before we can consider it matured.
-  -->
-
-  <class name="access" index="30" label="work with access tickets">
-    <doc>
-      The protocol control access to server resources using access tickets. A client must explicitly
-      request access tickets before doing work. An access ticket grants a client the right to use a
-      specific set of resources - called a "realm" - in specific ways.
-    </doc>
-
-    <doc type="grammar">
-      access = C:REQUEST S:REQUEST-OK
-    </doc>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MUST" />
-
-    <!-- - Method: access.request  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="request" synchronous="1" index="10" label="request an access ticket">
-      <doc>
-        This method requests an access ticket for an access realm. The server responds by granting
-        the access ticket. If the client does not have access rights to the requested realm this
-        causes a connection exception. Access tickets are a per-session resource.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="request-ok" />
-
-      <field name="realm" domain="shortstr" label="name of requested realm">
-        <doc>
-          Specifies the name of the realm to which the client is requesting access. The realm is a
-          configured server-side object that collects a set of resources (exchanges, queues, etc.).
-          If the session has already requested an access ticket onto this realm, the previous ticket
-          is destroyed and a new ticket is created with the requested access rights, if allowed.
-        </doc>
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST specify a realm that is known to the server. The server makes an
-            identical response for undefined realms as it does for realms that are defined but
-            inaccessible to this client.
-          </doc>
-          <doc type="scenario">
-            Client specifies an undefined realm.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="exclusive" domain="bit" label="request exclusive access">
-        <doc>
-          Request exclusive access to the realm, meaning that this will be the only session that
-          uses the realm's resources.
-        </doc>
-        <rule name="in-use" on-failure="access-refused">
-          <doc>
-            The client MUST NOT request exclusive access to a realm that has active access tickets,
-            unless the same session already had the only access ticket onto that realm.
-          </doc>
-          <doc type="scenario">
-            Client opens two sessions and requests exclusive access to the same realm.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="passive" domain="bit" label="request passive access">
-        <doc>
-          Request message passive access to the specified access realm. Passive access lets a client
-          get information about resources in the realm but not to make any changes to them.
-        </doc>
-      </field>
-
-      <field name="active" domain="bit" label="request active access">
-        <doc>
-          Request message active access to the specified access realm. Active access lets a client
-          get create and delete resources in the realm.
-        </doc>
-      </field>
-
-      <field name="write" domain="bit" label="request write access">
-        <doc>
-          Request write access to the specified access realm. Write access lets a client publish
-          messages to all exchanges in the realm.
-        </doc>
-      </field>
-
-      <field name="read" domain="bit" label="request read access">
-        <doc>
-          Request read access to the specified access realm. Read access lets a client consume
-          messages from queues in the realm.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: access.request-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="request-ok" synchronous="1" index="11" label="grant access to server resources">
-      <doc>
-        This method provides the client with an access ticket. The access ticket is valid within the
-        current session and for the lifespan of the session.
-      </doc>
-
-      <rule name="per-session" on-failure="not-allowed">
-        <doc>
-          The client MUST NOT use access tickets except within the same session as originally
-          granted.
-        </doc>
-        <doc type="scenario">
-          Client opens two sessions, requests a ticket on one session and then tries to use that
-          ticket in a second session.
-        </doc>
-      </rule>
-
-      <chassis name="client" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <doc>
-          A valid access ticket to be used for gaining access to the server.
-        </doc>
-      </field>
-    </method>
-
-  </class>
-
-  <!-- == Class: exchange ====================================================================== -->
-
-  <class name="exchange" index="40" label="work with exchanges">
-    <doc>
-      Exchanges match and distribute messages across queues. Exchanges can be configured in the
-      server or created at runtime.
-    </doc>
-
-    <doc type="grammar">
-      exchange  = C:DECLARE
-                / C:DELETE
-    </doc>
-
-    <rule name="required-types">
-      <doc>
-        The server MUST implement these standard exchange types: fanout, direct.
-      </doc>
-      <doc type="scenario">
-        Client attempts to declare an exchange with each of these standard types.
-      </doc>
-    </rule>
-
-    <rule name="recommended-types">
-      <doc>
-        The server SHOULD implement these standard exchange types: topic, headers.
-      </doc>
-      <doc type="scenario">
-        Client attempts to declare an exchange with each of these standard types.
-      </doc>
-    </rule>
-
-    <rule name="required-instances">
-      <doc>
-        The server MUST, in each virtual host, pre-declare an exchange instance for each standard
-        exchange type that it implements, where the name of the exchange instance, if defined, is
-        "amq." followed by the exchange type name.
-
-        The server MUST, in each virtual host, pre-declare at least two direct exchange instances:
-        one named "amq.direct", the other with no public name that serves as a default exchange for
-        publish methods (such as message.transfer).
-      </doc>
-      <doc type="scenario">
-        Client creates a temporary queue and attempts to bind to each required exchange instance
-        ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" if those types are defined).
-      </doc>
-    </rule>
-
-    <rule name="default-exchange">
-      <doc>
-        The server MUST pre-declare a direct exchange with no public name to act as the default
-        exchange for content publish methods (such as message.transfer) and for default queue
-        bindings.
-      </doc>
-      <doc type="scenario">
-        Client checks that the default exchange is active by publishing a message with a suitable
-        routing key but without specifying the exchange name, then ensuring that the message arrives
-        in the queue correctly.
-      </doc>
-    </rule>
-
-    <rule name="default-access">
-      <doc>
-        The default exchange MUST NOT be accessible to the client except by specifying an empty
-        exchange name in a content publish method (such as message.transfer). That is, the server
-        must not let clients explicitly bind, unbind, delete, or make any other reference to this
-        exchange.
-      </doc>
-    </rule>
-
-    <rule name="extensions">
-      <doc>
-        The server MAY implement other exchange types as wanted.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MUST" />
-
-    <!-- - Method: exchange.declare  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="declare" synchronous="1" index="10"
-      label="verify exchange exists, create if needed">
-      <doc>
-        This method creates an exchange if it does not already exist, and if the exchange exists,
-        verifies that it is of the correct and expected class.
-      </doc>
-
-      <rule name="minimum">
-        <doc>
-          The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose
-          no limit except as defined by available resources.
-        </doc>
-        <doc type="scenario">
-          The client creates as many exchanges as it can until the server reports an error; the
-          number of exchanges successfully created must be at least sixteen.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <doc>
-          When a client defines a new exchange, this belongs to the access realm of the ticket used.
-          All further work done with that exchange must be done with an access ticket for the same
-          realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access to the realm in
-            which the exchange exists or will be created, or "passive" access if the if-exists flag
-            is set.
-          </doc>
-          <doc type="scenario">
-            Client creates access ticket with wrong access rights and attempts to use in this
-            method.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="exchange" domain="exchange-name">
-        <rule name="reserved-names" on-failure="access-refused">
-          <doc>
-            Exchange names starting with "amq." are reserved for pre-declared and standardised
-            exchanges. The client MUST NOT attempt to create an exchange starting with "amq.".
-          </doc>
-        </rule>
-
-        <rule name="exchange-name-required" on-failure="not-allowed">
-          <doc>
-            The name of the exchange MUST NOT be a blank or empty string.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="type" domain="shortstr" label="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 name="typed" on-failure="not-allowed">
-          <doc>
-            Exchanges cannot be redeclared with different types. The client MUST not attempt to
-            redeclare an existing exchange with a different type than used in the original
-            Exchange.Declare method.
-          </doc>
-        </rule>
-
-        <rule name="support" on-failure="command-invalid">
-          <doc>
-            The client MUST NOT attempt to create an exchange with a type that the server does not
-            support.
-          </doc>
-        </rule>
-
-        <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$" />
-      </field>
-
-      <field name="alternate-exchange" domain="exchange-name"
-        label= "exchange-name for unroutable messages">
-        <doc>
-          In the event that a message cannot be routed, this is the name of the exchange to which
-          the message will be sent.
-        </doc>
-
-        <rule name="empty-name">
-          <doc>
-            If alternate-exchange is not set (its name is an empty string), unroutable messages MUST
-            be dropped silently.
-          </doc>
-        </rule>
-
-        <rule name="pre-existing-exchange" on-failure="channel-error">
-          <doc>
-            If the alternate-exchange is not empty and if the exchange already exists with a
-            different alternate-exchange, then the declaration MUST result in a channel error.
-          </doc>
-        </rule>
-
-        <rule name="double-failure">
-          <doc>
-            A message which is being routed to a alternate exchange, MUST NOT be re-routed to a
-            secondary alternate exchange if it fails to route in the primary alternate exchange.
-            After such a failure, the message MUST be dropped. This prevents looping.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="passive" domain="bit" label="do not create exchange">
-        <doc>
-          If set, the server will not create the exchange. The client can use this to check whether
-          an exchange exists without modifying the server state.
-        </doc>
-        <rule name="not-found" on-failure="not-found">
-          <doc>
-            If set, and the exchange does not already exist, the server MUST raise a channel
-            exception with reply code 404 (not found).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="durable" domain="bit" label="request a durable exchange">
-        <doc>
-          If set when creating a new exchange, the exchange will be marked as durable. Durable
-          exchanges remain active when a server restarts. Non-durable exchanges (transient
-          exchanges) are purged if/when a server restarts.
-        </doc>
-
-        <rule name="support">
-          <doc>
-            The server MUST support both durable and transient exchanges.
-          </doc>
-        </rule>
-
-        <rule name="sticky">
-          <doc>
-            The server MUST ignore the durable field if the exchange already exists.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="auto-delete" domain="bit" label="auto-delete when unused">
-        <doc>
-          If set, the exchange is deleted when all queues have finished using it.
-        </doc>
-        <rule name="sticky">
-          <doc>
-            The server MUST ignore the auto-delete field if the exchange already exists.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="arguments" domain="table" label="arguments for declaration">
-        <doc>
-          A set of arguments for the declaration. The syntax and semantics of these arguments
-          depends on the server implementation. This field is ignored if passive is 1.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: exchange.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="delete" synchronous="1" index="20" label="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" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to the
-            exchange's access realm.
-          </doc>
-          <doc type="scenario">
-            Client creates access ticket with wrong access rights and attempts to use in this
-            method.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="exchange" domain="exchange-name">
-        <rule name="exists" on-failure="not-found">
-          <doc>
-            The client MUST NOT attempt to delete an exchange that does not exist.
-          </doc>
-        </rule>
-
-        <rule name="exchange-name-required" on-failure="not-allowed">
-          <doc>
-            The name of the exchange MUST NOT be a blank or empty string.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <!-- TODO 0.82 - discuss whether this option is useful or not.  I don't have any real use case
-        for it. /PH 2006-07-23.
-      -->
-      <field name="if-unused" domain="bit" label="delete only if unused">
-        <doc>
-          If set, the server will only delete the exchange if it has no queue bindings. If the
-          exchange has queue bindings the server does not delete it but raises a channel exception
-          instead.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: exchange.query  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="query" synchronous="1" index="30" label="request information about an exchange">
-      <doc>
-        This method is used to request information on a particular exchange.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "passive" access rights to the
-            exchange's access realm.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="name" domain="shortstr" label="the exchange name">
-        <doc>
-           The name of the exchange for which information is requested. If not specified explicitly
-           the default exchange is implied.
-        </doc>
-      </field>
-
-      <result>
-        <struct size="long" type="31">
-          <doc>
-            This is sent in response to a query request and conveys information on a particular
-            exchange.
-          </doc>
-
-          <field name="type" domain="shortstr" label="indicate the exchange type">
-            <doc>
-               The type of the exchange. Will be empty if the exchange is not found.
-            </doc>
-          </field>
-
-          <field name="durable" domain="bit" label="indicate the durability">
-            <doc>
-               The durability of the exchange, i.e. if set the exchange is durable. Will not be set if
-               the exchange is not found.
-            </doc>
-          </field>
-
-          <field name="not-found" domain="bit" label="indicate an unknown exchange">
-            <doc>
-               If set, the exchange for which information was requested is not known.
-            </doc>
-          </field>
-
-          <field name="arguments" domain="table" label="other unspecified exchange properties">
-            <doc>
-              A set of properties of the exchange whose syntax and semantics depends on the server
-              implementation. Will be empty if the exchange is not found.
-            </doc>
-          </field>
-        </struct>
-      </result>
-    </method>
-
-  </class>
-
-  <!-- == Class: queue ========================================================================= -->
-
-  <class name="queue" index="50" label="work with queues">
-    <doc>
-      Queues store and forward messages. Queues can be configured in the server or created at
-      runtime. Queues must be attached to at least one exchange in order to receive messages from
-      publishers.
-    </doc>
-
-    <doc type="grammar">
-      queue = C:DECLARE
-            / C:BIND
-            / C:PURGE
-            / C:DELETE
-            / C:QUERY
-            / C:UNBIND
-    </doc>
-
-    <rule name="any-content">
-      <doc>
-        A server MUST allow any content class to be sent to any queue, in any mix, and queue and
-        deliver these content classes independently. Note that all methods that fetch content off
-        queues are specific to a given content class.
-      </doc>
-      <doc type="scenario">
-        Client creates an exchange of each standard type and several queues that it binds to each
-        exchange. It must then successfully send each of the standard content types to each of the
-        available queues.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MUST" />
-
-    <!-- - Method: queue.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="declare" synchronous="1" index="10" label="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 name="default-binding">
-        <doc>
-          The server MUST create a default binding for a newly-created queue to the default
-          exchange, which is an exchange of type 'direct' and use the queue name as the routing key.
-        </doc>
-        <doc type="scenario">
-          Client creates a new queue, and then without explicitly binding it to an exchange,
-          attempts to send a message through the default exchange binding, i.e. publish a message to
-          the empty exchange, with the queue name as routing key.
-        </doc>
-      </rule>
-
-      <rule name="minimum-queues">
-        <doc>
-          The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no
-          limit except as defined by available resources.
-        </doc>
-        <doc type="scenario">
-          Client attempts to create as many queues as it can until the server reports an error. The
-          resulting count must at least be 256.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <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>
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access to the realm in
-            which the queue exists or will be created.
-          </doc>
-          <doc type="scenario">
-            Client creates access ticket with wrong access rights and attempts to use in this
-            method.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="queue" domain="queue-name">
-        <rule name="reserved-prefix" on-failure="not-allowed">
-          <doc>
-            Queue names starting with "amq." are reserved for pre-declared and standardised server
-            queues. A client MUST NOT attempt to declare a queue with a name that starts with "amq."
-            and the passive option set to zero.
-          </doc>
-          <doc type="scenario">
-            A client attempts to create a queue with a name starting with "amq." and with the
-            passive option set to zero.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="alternate-exchange" domain="exchange-name"
-        label= "exchange-name for messages with exceptions">
-        <doc>
-          If a message is rejected by a queue, then it is sent to the alternate-exchange. A message
-          may be rejected by a queue for the following reasons:
-          1. The queue is deleted when it is not empty;
-          2. Immediate delivery of a message is requested, but there are no consumers connected to
-             the queue.
-        </doc>
-
-        <rule name="empty">
-          <doc>
-            If alternate-exchange is not set (its name is an empty string), rejected messages MUST
-            be dropped silently.
-          </doc>
-        </rule>
-
-        <rule name="pre-existing-exchange" on-failure="channel-error">
-          <doc>
-            If the alternate-exchange is not empty and if the queue already exists with a different
-            alternate-exchange, then the declaration MUST result in a channel error.
-          </doc>
-        </rule>
-
-        <rule name="delete-exchange" on-failure="channel-error">
-          <doc>
-            The alternate-exchange MUST NOT be deleted while a queue bound to it still exists. Such
-            an attempt MUST result in a channel exception.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="passive" domain="bit" label="do not create queue">
-        <doc>
-          If set, the server will not create the queue. This field allows the client to assert the
-          presence of a queue without modifying the server state.
-        </doc>
-
-        <rule name="passive" on-failure="not-found">
-          <doc>
-            The client MAY ask the server to assert that a queue exists without creating the queue
-            if not. If the queue does not exist, the server treats this as a failure.
-          </doc>
-          <doc type="scenario">
-            Client declares an existing queue with the passive option and expects the command to
-            succeed. Client then attempts to declare a non-existent queue with the passive option,
-            and the server must close the channel with the correct reply-code.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="durable" domain="bit" label="request a durable queue">
-        <doc>
-          If set when creating a new queue, the queue will be marked as durable. Durable queues
-          remain active when a server restarts. Non-durable queues (transient queues) are purged
-          if/when a server restarts. Note that durable queues do not necessarily hold persistent
-          messages, although it does not make sense to send persistent messages to a transient
-          queue.
-        </doc>
-
-        <rule name="persistence">
-          <doc>
-            The server MUST recreate the durable queue after a restart.
-          </doc>
-          <doc type="scenario">
-            Client creates a durable queue; server is then restarted. Client then attempts to send
-            message to the queue. The message should be successfully delivered.
-          </doc>
-        </rule>
-
-        <rule name="types">
-          <doc>
-            The server MUST support both durable and transient queues.
-          </doc>
-          <doc type="scenario">
-            A client creates two named queues, one durable and one transient.
-          </doc>
-        </rule>
-
-        <rule name="pre-existence">
-          <doc>
-            The server MUST ignore the durable field if the queue already exists.
-          </doc>
-          <doc type="scenario">
-            A client creates two named queues, one durable and one transient. The client then
-            attempts to declare the two queues using the same names again, but reversing the value
-            of the durable flag in each case. Verify that the queues still exist with the original
-            durable flag values.
-            <!-- TODO: but how? -->
-          </doc>
-        </rule>
-      </field>
-
-      <field name="exclusive" domain="bit" label="request an exclusive queue">
-        <doc>
-          Exclusive queues can only be used from one connection at a time. Once a connection
-          declares an exclusive queue, that queue cannot be used by any other connections until the
-          declaring connection closes.
-        </doc>
-
-        <rule name="types">
-          <doc>
-            The server MUST support both exclusive (private) and non-exclusive (shared) queues.
-          </doc>
-          <doc type="scenario">
-            A client creates two named queues, one exclusive and one non-exclusive.
-          </doc>
-        </rule>
-
-        <rule name="in-use" on-failure="resource-locked">
-          <doc>
-            If the server receives a declare, bind, consume or get request for a queue that has been
-            declared as exclusive by an existing client connection, it MUST raise a channel
-            exception.
-          </doc>
-          <doc type="scenario">
-            A client declares an exclusive named queue. A second client on a different connection
-            attempts to declare a queue of the same name.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="auto-delete" domain="bit" label="auto-delete queue when unused">
-        <doc>
-            If this field is set and the exclusive field is also set, then the queue MUST be deleted
-            when the connection closes.
-
-            If this field is set and the exclusive field is not set the queue is deleted when all
-            the consumers have finished using it. Last consumer can be cancelled either explicitly
-            or because its channel is closed. If there was no consumer ever on the queue, it won't
-            be deleted.
-        </doc>
-
-        <rule name="pre-existence">
-          <doc>
-            The server MUST ignore the auto-delete field if the queue already exists.
-          </doc>
-          <doc type="scenario">
-            A client creates two named queues, one as auto-delete and one explicit-delete. The
-            client then attempts to declare the two queues using the same names again, but reversing
-            the value of the auto-delete field in each case. Verify that the queues still exist with
-            the original auto-delete flag values.
-            <!-- TODO: but how? -->
-          </doc>
-        </rule>
-      </field>
-
-      <field name="arguments" domain="table" label="arguments for declaration">
-        <doc>
-          A set of arguments for the declaration. The syntax and semantics of these arguments
-          depends on the server implementation. This field is ignored if passive is 1.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: queue.bind  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="bind" synchronous="1" index="20" label="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 direct
-        exchange and subscription queues are bound to a topic exchange.
-      </doc>
-
-      <rule name="duplicates">
-        <doc>
-          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.
-        </doc>
-        <doc type="scenario">
-          A client binds a named queue to an exchange. The client then repeats the bind (with
-          identical arguments).
-        </doc>
-      </rule>
-
-      <rule name="failure">
-        <!--
-          TODO: Find correct on-failure code. The on-failure code returned should depend on why the
-          bind failed. Assuming that failures owing to bad parameters are covered in the rules
-          relating to those parameters, the only remaining reason for a failure would be the lack of
-          server resorces or some internal error - such as too many queues open. Would these cases
-          qualify as "resource error" 506 or "internal error" 541?
-        -->
-        <doc>
-          If a bind fails, the server MUST raise a connection exception.
-        </doc>
-      </rule>
-
-      <rule name="transient-exchange" on-failure="not-allowed">
-        <doc>
-          The server MUST NOT allow a durable queue to bind to a transient exchange.
-        </doc>
-        <doc type="scenario">
-          A client creates a transient exchange. The client then declares a named durable queue and
-          then attempts to bind the transient exchange to the durable queue.
-        </doc>
-      </rule>
-
-      <rule name="durable-exchange">
-        <doc>
-          Bindings for durable queues are automatically durable and the server SHOULD restore such
-          bindings after a server restart.
-        </doc>
-        <doc type="scenario">
-          A server creates a named durable queue and binds it to a durable exchange. The server is
-          restarted. The client then attempts to use the queue/exchange combination.
-        </doc>
-      </rule>
-
-      <rule name="internal-exchange" on-failure="not-allowed">
-        <doc>
-          If the client attempts to bind to an exchange that was declared as internal, the server
-          MUST raise a connection exception with reply code 530 (not allowed).
-        </doc>
-        <doc type="scenario">
-          A client attempts to bind a named queue to an internal exchange.
-        </doc>
-      </rule>
-
-      <rule name="binding-count">
-        <doc>
-          The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit
-          except as defined by available resources.
-        </doc>
-        <doc type="scenario">
-          A client creates a named queue and attempts to bind it to 4 different non-internal
-          exchanges.
-        </doc>
-      </rule>
-
-      <rule name="multiple-bindings">
-        <doc>
-          Where more than one binding exists between a particular exchange instance and a particular
-          queue instance any given message published to that exchange should be delivered to that
-          queue at most once, regardless of how many distinct bindings match.
-        </doc>
-        <doc type="scenario">
-          A client creates a named queue and binds it to the same topic exchange at least three
-          times using intersecting routing keys (for example, "animals.*", "animals.dogs.*",
-          "animal.dogs.chihuahua"). Verify that a message matching all the bindings (using previous
-          example, routing key = "animal.dogs.chihuahua") is delivered once only.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client provides a valid access ticket giving "active" access rights to the queue's
-            access realm.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-
-        <rule name="empty-queue" on-failure="not-allowed">
-          <doc>
-            A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. empty queue
-            name) to an exchange.
-          </doc>
-          <doc type="scenario">
-            A client attempts to bind with an unnamed (empty) queue name to an exchange.
-          </doc>
-        </rule>
-
-        <rule name="queue-existence" on-failure="not-found">
-          <doc>
-            A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously declared)
-            to an exchange.
-          </doc>
-          <doc type="scenario">
-            A client attempts to bind an undeclared queue name to an exchange.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="exchange" domain="exchange-name" label="name of the exchange to bind to">
-        <rule name="exchange-existence" on-failure="not-found">
-          <doc>
-            A client MUST NOT be allowed to bind a queue to a non-existent exchange.
-          </doc>
-          <doc type="scenario">
-            A client attempts to bind a named queue to a undeclared exchange.
-          </doc>
-        </rule>
-
-        <rule name="exchange-name-required" on-failure="not-allowed">
-          <doc>
-            The name of the exchange MUST NOT be a blank or empty string.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="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 queue name is empty, the server uses the last
-          queue declared on the session. If the routing key is also empty, the server uses this
-          queue name for the routing key as well. If the queue name is provided but the routing key
-          is empty, the server does the binding with that empty routing key. The meaning of empty
-          routing keys depends on the exchange implementation.
-        </doc>
-        <rule name="direct-exchange-key-matching">
-          <doc>
-            If a message queue binds to a direct exchange using routing key K and a publisher sends
-            the exchange a message with routing key R, then the message MUST be passed to the
-            message queue if K = R.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="arguments" domain="table" label="arguments for binding">
-        <doc>
-          A set of arguments for the binding. The syntax and semantics of these arguments depends on
-          the exchange class.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: queue.unbind  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="unbind" synchronous="1" index="50" label="unbind a queue from an exchange">
-      <doc>
-        This method unbinds a queue from an exchange.
-      </doc>
-      
-      <rule name="failure">
-        <doc>
-          If a unbind fails, the server MUST raise a connection exception.
-          <!-- TODO: define failure code -->
-        </doc>
-      </rule>
-      
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client provides a valid access ticket giving "active" access rights to the queue's
-            access realm.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="queue" domain="queue-name">
-        <doc>
-          Specifies the name of the queue to unbind.
-        </doc>
-        <rule name="non-existent-queue" on-failure="not-found">
-          <doc>
-            If the queue does not exist the server MUST raise a channel exception with reply code
-            404 (not found).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="exchange" domain="exchange-name">
-        <doc>
-          The name of the exchange to unbind from.
-        </doc>
-
-        <rule name="non-existent-exchange" on-failure="not-found">
-          <doc>
-            If the exchange does not exist the server MUST raise a channel exception with reply code
-            404 (not found).
-          </doc>
-        </rule>
-
-        <rule name="exchange-name-required" on-failure="not-allowed">
-          <doc>
-            The name of the exchange MUST NOT be a blank or empty string.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="routing key of binding">
-        <doc>
-          Specifies the routing key of the binding to unbind.
-        </doc>
-      </field>
-
-      <field name="arguments" domain="table" label="arguments of binding">
-        <doc>
-          Specifies the arguments of the binding to unbind.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: queue.purge - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="purge" synchronous="1" index="30" label="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 name="empty">
-        <doc>
-          A call to purge MUST result in an empty queue.
-        </doc>
-      </rule>
-
-      <rule name="tx-exception">
-        <doc>
-          On transacted sessions the server MUST not purge messages that have already been sent to a
-          client but not yet acknowledged.
-        </doc>
-      </rule>
-
-      <rule name="purge-recovery">
-        <doc>
-          The server MAY implement a purge queue or log that allows system administrators to recover
-          accidentally-purged messages. The server SHOULD NOT keep purged messages in the same
-          storage spaces as the live messages since the volumes of purged messages may get very
-          large.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            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.
-          </doc>
-        </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 session, which is the last declared queue.
-        </doc>
-
-        <rule name="empty-name" on-failure="not-allowed">
-          <doc>
-            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>
-        </rule>
-
-        <rule name="queue-exists" on-failure="not-found">
-          <doc>
-            The queue MUST exist. Attempting to purge a non-existing queue MUST cause a channel
-            exception with reply code 404 (not found).
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: queue.delete  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="delete" synchronous="1" index="40" label="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 name="dead-letter-queue">
-        <doc>
-          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.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client provides a valid access ticket giving "active" access rights to the queue's
-            access realm.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-
-        <rule name="empty-name" on-failure="not-allowed">
-          <doc>
-            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>
-        </rule>
-
-        <rule name="queue-exists" on-failure="not-found">
-          <doc>
-            The queue must exist. If the client attempts to delete a non-existing queue the server
-            MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="if-unused" domain="bit" label="delete only if unused">
-        <doc>
-          If set, the server will only delete the queue if it has no consumers. If the queue has
-          consumers the server does does not delete it but raises a channel exception instead.
-        </doc>
-
-        <rule name="if-unused-flag">
-          <doc>
-            The server MUST respect the if-unused flag when deleting a queue.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="if-empty" domain="bit" label="delete only if empty">
-        <doc>
-          If set, the server will only delete the queue if it has no messages.
-        </doc>
-        <rule name="not-empty" on-failure="precondition-failed">
-          <doc>
-            If the queue is not empty the server MUST raise a channel exception with reply code 406
-            (precondition failed).
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: queue.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="query" synchronous="1" index="60" label="request information about a queue">
-      <doc>
-        This method requests information about a queue.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-
-      <field name="queue" domain="queue-name" label="the queried queue">
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="61">
-          <doc>
-            This is sent in response to queue.query, and conveys the requested information about a
-            queue.
-          </doc>
-
-          <field name="queue" domain="queue-name">
-            <doc>
-              Reports the name of the queue.
-            </doc>
-            <assert check="notnull" />
-          </field>
-
-          <field name="alternate-exchange" domain="exchange-name" />
-
-          <field name="durable" domain="bit" />
-
-          <field name="exclusive" domain="bit" />
-
-          <field name="auto-delete" domain="bit" />
-
-          <field name="arguments" domain="table" />
-
-          <field name="message-count" domain="long" label="number of messages in queue">
-            <doc>
-              Reports the number of messages in the queue.
-            </doc>
-          </field>
-
-          <field name="consumer-count" domain="long" label="number of consumers">
-            <doc>
-              Reports the number of active consumers for the queue. Note that consumers can suspend
-              activity (Session.Flow) in which case they do not appear in this count.
-            </doc>
-          </field>
-        </struct>
-      </result>
-    </method>
-
-  </class>
-
-  <!-- == Class: basic ========================================================================= -->
-
-  <class name="basic" index="60" label="[DEPRECATED] work with basic content">
-    <doc>
-      [DEPRECATED: replaced by message class.] The Basic class provides methods that support an
-      industry-standard messaging model.
-    </doc>
-
-    <doc type="grammar">
-      basic = C:QOS
-            / C:CONSUME S:CONSUME-OK
-            / C:CANCEL 
-            / C:PUBLISH content
-            / S:RETURN content
-            / S:DELIVER content
-            / C:GET ( S:GET-OK content / S:GET-EMPTY )
-            / C:ACK
-            / C:REJECT
-    </doc>
-
-    <rule name="persistence">
-      <doc>
-        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 type="scenario">
-        Send a persistent message to queue, stop server, restart server and then verify whether
-        message is still present. Assumes that queues are durable. Persistence without durable
-        queues makes no sense.
-      </doc>
-    </rule>
-
-    <rule name="persistent-overflow">
-      <doc>
-        The server MUST NOT discard a persistent basic message in case of a queue overflow.
-      </doc>
-      <doc type="scenario">
-        Create a queue overflow situation with persistent messages and verify that messages do not
-        get lost (presumably the server will write them to disk).
-      </doc>
-    </rule>
-
-    <rule name="throttling">
-      <doc>
-        The server MAY use the Session.Flow method to slow or stop a basic message publisher when
-        necessary.
-      </doc>
-      <doc type="scenario">
-        Create a queue overflow situation with non-persistent messages and verify whether the server
-        responds with Session.Flow or not. Repeat with persistent messages.
-      </doc>
-    </rule>
-
-    <rule name="non-persistent-overflow">
-      <doc>
-        The server MAY overflow non-persistent basic messages to persistent storage.
-      </doc>
-      <!-- Test scenario: untestable -->
-    </rule>
-
-    <rule name="dead-letter-overflow">
-      <doc>
-        The server MAY discard or dead-letter non-persistent basic messages on a priority basis if
-        the queue size exceeds some configured limit.
-      </doc>
-      <!-- Test scenario: untestable -->
-    </rule>
-
-    <rule name="min-priority-levels">
-      <doc>
-        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.
-      </doc>
-      <doc type="scenario">
-        Send a number of priority 0 messages to a queue. Send one priority 9 message. Consume
-        messages from the queue and verify that the first message received was priority 9.
-      </doc>
-    </rule>
-
-    <rule name="max-priority-levels">
-      <doc>
-        The server MAY implement up to 10 priority levels.
-      </doc>
-      <doc type="scenario">
-        Send a number of messages with mixed priorities to a queue, so that all priority values from
-        0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume
-        from queue and verify how many priority levels emerge.
-      </doc>
-    </rule>
-
-    <rule name="priority">
-      <doc>
-        The server MUST deliver messages of the same priority in order irrespective of their
-        individual persistence.
-      </doc>
-      <doc type="scenario">
-        Send a set of messages with the same priority but different persistence settings to a queue.
-        Consume and verify that messages arrive in same order as originally published.
-      </doc>
-    </rule>
-
-    <rule name="automatic-acknowledgement">
-      <doc>
-        The server MUST support automatic acknowledgements on Basic content, i.e. consumers with the
-        no-ack field set to FALSE.
-      </doc>
-      <doc type="scenario">
-        Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to
-        the queue. Consume the messages and verify that all messages are received.
-      </doc>
-    </rule>
-
-    <rule name="explicit-acknowledgement">
-      <doc>
-        The server MUST support explicit acknowledgements on Basic content, i.e. consumers with the
-        no-ack field set to TRUE.
-      </doc>
-      <doc type="scenario">
-        Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to
-        the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect,
-        and consume from the queue. Verify that the remaining messages are received.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MAY" />
-
-    <!--  These are the properties for a Basic content  -->
-
-    <field name="content-type" domain="shortstr" label="MIME content type" />
-    <field name="content-encoding" domain="shortstr" label="MIME content encoding" />
-    <field name="headers" domain="table" label="message header field table" />
-    <field name="delivery-mode" domain="octet" label="non-persistent (1) or persistent (2)" />
-    <field name="priority" domain="octet" label="message priority, 0 to 9" />
-    <field name="correlation-id" domain="shortstr" label="application correlation identifier" />
-    <field name="reply-to" domain="shortstr" label="destination to reply to" />
-    <field name="expiration" domain="shortstr" label="message expiration specification" />
-    <field name="message-id" domain="shortstr" label="application message identifier" />
-    <field name="timestamp" domain="timestamp" label="message timestamp" />
-    <field name="type" domain="shortstr" label="message type name" />
-    <field name="user-id" domain="shortstr" label="creating user id" />
-    <field name="app-id" domain="shortstr" label="creating application id" />
-
-    <!-- - Method: basic.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="qos" synchronous="1" index="10" label="[DEPRECATED] specify quality of service">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] This method requests a specific quality of
-        service. The QoS can be specified for the current session or for all sessions 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" />
-
-      <field name="prefetch-size" domain="long" label="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 within the session. 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>
-
-        <rule name="ignore">
-          <doc>
-            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>
-          <doc type="scenario">
-            Define a QoS prefetch-size limit and send a single message that exceeds that limit.
-            Verify that the message arrives correctly.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="prefetch-count" domain="short" label="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 session and connection level) allow it. The
-          prefetch-count is ignored if the no-ack option is set.
-        </doc>
-
-        <rule name="prefetch">
-          <doc>
-            The server may send less data in advance than allowed by the client's specified prefetch
-            windows but it MUST NOT send more.
-          </doc>
-          <doc type="scenario">
-            Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send
-            multiple messages that exceed the prefetch size. Verify that no more than one message
-            arrives at once.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="global" domain="bit" label="apply to entire connection">
-        <doc>
-          By default the QoS settings apply to the current session only. If this field is set, they
-          are applied to the entire connection.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: basic.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="consume" synchronous="1" index="20" label="[DEPRECATED] start a queue consumer">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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 session they were created on, or until the client cancels them.
-      </doc>
-
-      <rule name="min-consumers">
-        <doc>
-          The server SHOULD support at least 16 consumers per queue, and ideally, impose no limit
-          except as defined by available resources.
-        </doc>
-        <doc type="scenario">
-          Create a queue and create consumers on that queue until the server closes the connection.
-          Verify that the number of consumers created was at least sixteen and report the total
-          number.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="consume-ok" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "read" access rights to the realm
-            for the queue from which the message will be consumed.
-          </doc>
-          <doc type="scenario">
-            Attempt to create a consumer with an invalid (non-zero) access ticket.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-        <rule name="queue-exists-if-empty" on-failure="not-allowed">
-          <doc>
-            If the queue name is empty the client MUST have previously declared a queue using this
-            session.
-          </doc>
-          <doc type="scenario">
-            Attempt to create a consumer with an empty queue name and no previously declared queue
-            on the session.
-          </doc>
-        </rule>
-      </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>
-
-        <rule name="not-existing-consumer" on-failure="not-allowed">
-          <doc>
-            The client MUST NOT specify a tag that refers to an existing consumer.
-          </doc>
-          <doc type="scenario">
-            Attempt to create two consumers with the same non-empty tag.
-          </doc>
-        </rule>
-
-        <rule name="session-bound" on-failure="not-allowed">
-          <doc>
-            The consumer tag is valid only within the session from which the consumer was created.
-            i.e. A client MUST NOT create a consumer in one session and then use it in another.
-          </doc>
-          <doc type="scenario">
-            Attempt to create a consumer in one session, then use in another session, in which
-            consumers have also been created (to test that the server uses unique consumer tags).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="no-local" domain="no-local" />
-
-      <field name="no-ack" domain="no-ack" />
-
-      <field name="exclusive" domain="bit" label="request exclusive access">
-        <doc>
-          Request exclusive consumer access, meaning only this consumer can access the queue.
-        </doc>
-
-        <rule name="in-use" on-failure="access-refused">
-          <doc>
-            The client MUST NOT gain exclusive access to a queue that already has active consumers.
-          </doc>
-          <doc type="scenario">
-            Open two connections to a server, and in one connection create a shared (non-exclusive)
-            queue and then consume from the queue. In the second connection attempt to consume from
-            the same queue using the exclusive option.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="nowait" domain="bit" label="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" domain="table" label="arguments for consuming">
-        <doc>
-          A set of arguments for the consume. The syntax and semantics of these arguments depends on
-          the providers implementation.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: basic.consume-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="consume-ok" synchronous="1" index="21"
-      label="[DEPRECATED] confirm a new consumer">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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: basic.cancel  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="cancel" synchronous="1" index="30" label="[DEPRECATED] end a queue consumer">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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 arbitrary number of messages in
-        between sending the cancel method and receiving notification of the completion of the cancel command.
-      </doc>
-
-      <rule name="non-existent">
-        <doc>
-          If the queue does not exist the server MUST ignore the cancel method, so long as the
-          consumer tag is valid for that session.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="consumer-tag" domain="consumer-tag" />
-    </method>
-
-    <!-- - Method: basic.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="publish" content="1" index="40" label="[DEPRECATED] publish a message">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "passive" access rights to the
-            realm for the exchange and "write" access rights to the realm for the queue to which the
-            message will be published.
-          </doc>
-        </rule>
-      </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>
-
-        <rule name="default">
-          <doc>
-            The server MUST accept a blank exchange name to mean the default exchange.
-          </doc>
-        </rule>
-
-        <rule name="internal" on-failure="access-refused">
-          <doc>
-            If the exchange was declared as an internal exchange, the server MUST raise a channel
-            exception with a reply code 403 (access refused).
-          </doc>
-        </rule>
-
-        <rule name="refusal" on-failure="not-implemented">
-          <doc>
-            The exchange MAY refuse basic content in which case it MUST raise a channel exception
-            with reply code 540 (not implemented).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="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="reject-unroutable" domain="bit" label="reject message if unroutable flag">
-        <doc>
-          If the reject-unroutable flag is set, then at the time of publishing the broker
-          determines if the message will be routed to any queues. If it will not be routed to any
-          queue then the broker responds with a basic.reject.
-        </doc>
-      </field>
-
-      <field name="immediate" domain="bit" label="Request immediate delivery">
-        <doc>
-            If this flag is set, and the resulting message is delivered to a queue with no
-            consumers, the message will not be queued but will instead be routed to the
-            alternate-exchange for that queue. If no such exchange is defined the message will be
-            silently dropped.
-        </doc>
-        <rule name="implementation">
-          <doc>
-            The server SHOULD implement the immediate flag.
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: basic.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="deliver" content="1" index="60"
-      label="[DEPRECATED] notify the client of a consumer message">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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>
-
-      <rule name="redelivery-tracking">
-        <doc>
-          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>
-      </rule>
-
-      <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" domain="shortstr" label="Message routing key">
-        <doc>
-          Specifies the routing key name specified when the message was published.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: basic.get - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="get" synchronous="1" index="70" label="[DEPRECATED] direct access to a queue">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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>
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="get-ok" />
-      <response name="get-empty" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "read" access rights to the realm
-            for the queue from which the message will be obtained.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-        <rule name="queue-exists-if-empty">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="no-ack" domain="no-ack" />
-    </method>
-
-    <!-- - Method: basic.get-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="get-ok" synchronous="1" content="1" index="71"
-      label="[DEPRECATED] provide client with a message">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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" domain="shortstr" label="Message routing key">
-        <doc>
-          Specifies the routing key name specified when the message was published.
-        </doc>
-      </field>
-
-      <field name="message-count" domain="long" label="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: basic.get-empty - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="get-empty" synchronous="1" index="72"
-      label="[DEPRECATED] indicate no messages available">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] This method tells the client that the queue
-        has no messages available for the client.
-      </doc>
-
-      <chassis name="client" implement="MAY" />
-
-      <!-- This field is deprecated pending review -->
-      <field name="cluster-id" domain="shortstr" label="Cluster id">
-        <doc>
-          For use by cluster applications, should not be used by client applications.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: basic.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="ack" index="80" label="[DEPRECATED] acknowledge one or more messages">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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" domain="bit" label="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 messages.
-        </doc>
-
-        <rule name="validation">
-          <doc>
-            The server MUST validate that a non-zero delivery-tag refers to a delivered message, and
-            raise a channel exception if this is not the case.
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: basic.reject  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="reject" index="90" label="[DEPRECATED] reject an incoming message">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] 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>
-
-      <rule name="concurrent-processing">
-        <doc>
-          The server SHOULD be capable of accepting and processing 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>
-      </rule>
-
-      <rule name="server-interpretation">
-        <doc>
-          The server SHOULD interpret this method as meaning that the client is unable to process
-          the message at this time.
-        </doc>
-      </rule>
-
-      <rule name="not-selection">
-        <doc>
-          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>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="delivery-tag" domain="delivery-tag" />
-
-      <field name="requeue" domain="bit" label="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>
-
-        <rule name="requeue-strategy">
-          <doc>
-            The server MUST NOT deliver the message to the same client within the context of the
-            current session. 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>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: basic.recover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="recover" index="100" label="[DEPRECATED] redeliver unacknowledged messages">
-      <doc>
-        [DEPRECATED: Basic replaced by message class.] This method asks the broker to redeliver all
-        unacknowledged messages on a specified session. Zero or more messages may be redelivered.
-        This method is only allowed on non-transacted sessions.
-      </doc>
-
-      <rule name="redelivered-flag">
-        <doc>
-          The server MUST set the redelivered flag on all messages that are resent.
-        </doc>
-      </rule>
-
-      <rule name="non-transacted-session">
-        <doc>
-          The server MUST raise a channel exception if this is called on a transacted session.
-          <!-- TODO: define failure code -->
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="requeue" domain="bit" label="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>
-    </method>
-
-  </class>
-
-  <!-- == Class: file ========================================================================== -->
-
-  <class name="file" index="70" label="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 session 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 type="grammar">
-      file  = C:QOS S:QOS-OK
-            / C:CONSUME S:CONSUME-OK
-            / C:CANCEL
-            / 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>
-
-    <rule name="reliable-storage">
-      <doc>
-        The server MUST make a best-effort to hold file messages on a reliable storage mechanism.
-      </doc>
-    </rule>
-
-    <!-- TODO Rule implement attr inverse? -->
-
-    <rule name="no-discard">
-      <doc>
-        The server MUST NOT discard a file message in case of a queue overflow. The server MUST use
-        the Session.Flow method to slow or stop a file message publisher when necessary.
-      </doc>
-    </rule>
-
-    <rule name="priority-levels">
-      <doc>
-        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>
-    </rule>
-
-    <rule name="acknowledgement-support">
-      <doc>
-        The server MUST support both automatic and explicit acknowledgements on file content.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MAY" />
-    <chassis name="client" implement="MAY" />
-
-    <!--  These are the properties for a File content  -->
-
-    <field name="content-type" domain="shortstr" label="MIME content type" />
-    <field name="content-encoding" domain="shortstr" label="MIME content encoding" />
-    <field name="headers" domain="table" label="message header field table" />
-    <field name="priority" domain="octet" label="message priority, 0 to 9" />
-    <field name="reply-to" domain="shortstr" label="destination to reply to" />
-    <field name="message-id" domain="shortstr" label="application message identifier" />
-    <field name="filename" domain="shortstr" label="message filename" />
-    <field name="timestamp" domain="timestamp" label="message timestamp" />
-    <!-- This field is deprecated pending review -->
-    <field name="cluster-id" domain="shortstr" label="intra-cluster routing identifier" />
-
-    <!-- - Method: file.qos  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="qos" synchronous="1" index="10" label="specify quality of service">
-      <doc>
-        This method requests a specific quality of service. The QoS can be specified for the current
-        session or for all sessions 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" domain="long" label="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 within the session. 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" domain="short" label="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 session
-          and connection level) allow it. The prefetch-count is ignored if the no-ack option is set.
-        </doc>
-
-        <rule name="prefetch-discretion">
-          <doc>
-            The server MAY send less data in advance than allowed by the client's specified prefetch
-            windows but it MUST NOT send more.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="global" domain="bit" label="apply to entire connection">
-        <doc>
-          By default the QoS settings apply to the current session only. If this field is set, they
-          are applied to the entire connection.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: file.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="qos-ok" synchronous="1" index="11" label="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: file.consume  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="consume" synchronous="1" index="20" label="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 session they were created on, or until
-        the client cancels them.
-      </doc>
-
-      <rule name="min-consumers">
-        <doc>
-          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>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="consume-ok" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "read" access rights to the realm
-            for the queue from which the message will be consumed.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-
-        <rule name="queue-exists-if-empty" on-failure="not-allowed">
-          <doc>
-            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>
-        </rule>
-      </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>
-
-        <rule name="not-existing-consumer" on-failure="not-allowed">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="no-local" domain="no-local" />
-
-      <field name="no-ack" domain="no-ack" />
-
-      <field name="exclusive" domain="bit" label="request exclusive access">
-        <doc>
-          Request exclusive consumer access, meaning only this consumer can access the queue.
-        </doc>
-
-        <rule name="in-use" on-failure="resource-locked">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="nowait" domain="bit" label="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="filter" domain="table" label="arguments for consuming">
-        <doc>
-          A set of filters for the consume. The syntax and semantics of these filters depends on the
-          providers implementation.
-        </doc>
-      </field>
-    </method>
-
-    <method name="consume-ok" synchronous="1" index="21" label="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: file.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="cancel" synchronous="1" index="30" label="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" />
-
-      <field name="consumer-tag" domain="consumer-tag" />
-    </method>
-
-    <!-- - Method: file.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="open" synchronous="1" index="40" label="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>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <response name="open-ok" />
-
-      <field name="identifier" domain="shortstr" label="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" domain="longlong" label="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>
-
-        <rule name="content-size">
-          <doc>
-            The sender MUST accurately fill the content-size field. Zero-length content is
-            permitted.
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: file.open-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="open-ok" synchronous="1" index="41" label="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>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <response name="stage" />
-
-      <field name="staged-size" domain="longlong" label="already staged amount">
-        <doc>
-          The amount of previously-staged content in octets. For a new message this will be zero.
-        </doc>
-
-        <rule name="behaviour">
-          <doc>
-            The sender MUST start sending data from this octet offset in the message, counting from
-            zero.
-            <!-- TODO: review this text, it seems ambiguous or confusing... -->
-          </doc>
-        </rule>
-
-        <rule name="staging">
-          <doc>
-            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>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: file.stage  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="stage" content="1" index="50" label="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: file.publish  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="publish" index="60" label="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">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "passive" access rights to the
-            realm for the exchange and "write" access rights to the realm for the queue to which the
-            message will be published.
-          </doc>
-        </rule>
-      </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>
-
-        <rule name="default">
-          <doc>
-            The server MUST accept a blank exchange name to mean the default exchange.
-          </doc>
-        </rule>
-
-        <rule name="internal" on-failure="access-refused">
-          <doc>
-            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>
-        </rule>
-
-        <rule name="refusal" on-failure="not-implemented">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="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" domain="bit" label="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>
-
-        <rule name="implementation">
-          <doc>
-            The server SHOULD implement the mandatory flag.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="immediate" domain="bit" label="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>
-
-        <rule name="implementation">
-          <doc>
-            The server SHOULD implement the immediate flag.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="identifier" domain="shortstr" label="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: file.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="return" content="1" index="70" label="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" domain="shortstr" label="Message routing key">
-        <doc>
-          Specifies the routing key name specified when the message was published.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: file.deliver  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="deliver" index="80" label="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>
-
-      <rule name="redelivery-tracking">
-        <doc>
-          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>
-      </rule>
-
-      <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" domain="shortstr" label="Message routing key">
-        <doc>
-          Specifies the routing key name specified when the message was published.
-        </doc>
-      </field>
-
-      <field name="identifier" domain="shortstr" label="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: file.ack  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="ack" index="90" label="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" domain="bit" label="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 messages.
-        </doc>
-
-        <rule name="validation">
-          <doc>
-            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>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: file.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="reject" index="100" label="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>
-
-      <rule name="server-interpretation">
-        <doc>
-          The server SHOULD interpret this method as meaning that the client is unable to process
-          the message at this time.
-        </doc>
-      </rule>
-
-      <rule name="not-selection">
-        <doc>
-          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>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="delivery-tag" domain="delivery-tag" />
-
-      <field name="requeue" domain="bit" label="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>
-
-        <rule name="requeue-strategy">
-          <doc>
-            The server MUST NOT deliver the message to the same client within the context of the
-            current session. 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>
-        </rule>
-      </field>
-    </method>
-
-  </class>
-
-  <!-- == Class: stream ======================================================================== -->
-
-  <class name="stream" index="80" label="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 unacknowledged 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 type="grammar">
-      stream  = C:QOS S:QOS-OK
-              / C:CONSUME S:CONSUME-OK
-              / C:CANCEL
-              / C:PUBLISH content
-              / S:RETURN
-              / S:DELIVER content
-    </doc>
-
-    <rule name="overflow-discard">
-      <doc>
-        The server SHOULD discard stream messages on a priority basis if the queue size exceeds some
-        configured limit.
-      </doc>
-    </rule>
-
-    <rule name="priority-levels">
-      <doc>
-        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>
-    </rule>
-
-    <rule name="acknowledgement-support">
-      <doc>
-        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>
-    </rule>
-
-    <chassis name="server" implement="MAY" />
-    <chassis name="client" implement="MAY" />
-
-    <!--  These are the properties for a Stream content  -->
-
-    <field name="content-type" domain="shortstr" label="MIME content type" />
-    <field name="content-encoding" domain="shortstr" label="MIME content encoding" />
-    <field name="headers" domain="table" label="message header field table" />
-    <field name="priority" domain="octet" label="message priority, 0 to 9" />
-    <field name="timestamp" domain="timestamp" label="message timestamp" />
-
-    <!-- - Method: stream.qos  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="qos" synchronous="1" index="10" label="specify quality of service">
-      <doc>
-        This method requests a specific quality of service. The QoS can be specified for the current
-        session or for all sessions 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" domain="long" label="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 within the session. 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" domain="short" label="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 session and connection level) allow it.
-        </doc>
-      </field>
-
-      <field name="consume-rate" domain="long" label="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>
-
-        <rule name="ignore-prefetch">
-          <doc>
-            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.
-          </doc>
-        </rule>
-
-        <rule name="drop-by-priority">
-          <doc>
-            The server MAY drop low-priority messages in favour of high-priority messages.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="global" domain="bit" label="apply to entire connection">
-        <doc>
-          By default the QoS settings apply to the current session only. If this field is set, they
-          are applied to the entire connection.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: stream.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="qos-ok" synchronous="1" index="11" label="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: stream.consume  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="consume" synchronous="1" index="20" label="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 session they were created on, or until
-        the client cancels them.
-      </doc>
-
-      <rule name="min-consumers">
-        <doc>
-          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>
-      </rule>
-
-      <rule name="priority-based-delivery">
-        <doc>
-          Streaming applications SHOULD use different sessions 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>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <response name="consume-ok" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "read" access rights to the realm
-            for the queue from which the message will be consumed.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-
-        <rule name="queue-exists-if-empty" on-failure="not-allowed">
-          <doc>
-            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>
-        </rule>
-      </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>
-
-        <rule name="not-existing-consumer" on-failure="not-allowed">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="no-local" domain="no-local" />
-
-      <field name="exclusive" domain="bit" label="request exclusive access">
-        <doc>
-          Request exclusive consumer access, meaning only this consumer can access the queue.
-        </doc>
-
-        <rule name="in-use" on-failure="resource-locked">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="nowait" domain="bit" label="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="filter" domain="table" label="arguments for consuming">
-        <doc>
-          A set of filters for the consume. The syntax and semantics of these filters depends on the
-          providers implementation.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: stream.consume-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="consume-ok" synchronous="1" index="21" label="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: stream.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="cancel" synchronous="1" index="30" label="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 cancelling a consumer. It may process
-        or discard these as appropriate.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="consumer-tag" domain="consumer-tag" />
-    </method>
-
-    <!-- - Method: stream.publish  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="publish" content="1" index="40" label="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">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "passive" access rights to the
-            realm for the exchange and "write" access rights to the realm for the queue to which the
-            message will be published.
-          </doc>
-        </rule>
-      </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>
-
-        <rule name="default">
-          <doc>
-            The server MUST accept a blank exchange name to mean the default exchange.
-          </doc>
-        </rule>
-
-        <rule name="internal" on-failure="access-refused">
-          <doc>
-            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>
-        </rule>
-
-        <rule name="refusal" on-failure="not-implemented">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="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" domain="bit" label="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>
-
-        <rule name="implementation">
-          <doc>
-            The server SHOULD implement the mandatory flag.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="immediate" domain="bit" label="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>
-
-        <rule name="implementation">
-          <doc>
-            The server SHOULD implement the immediate flag.
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: stream.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="return" content="1" index="50" label="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" domain="shortstr" label="Message routing key">
-        <doc>
-          Specifies the routing key name specified when the message was published.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: stream.deliver  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="deliver" content="1" index="60" label="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 session can
-          start many consumers on different queues.
-        </doc>
-        <assert check="notnull" />
-      </field>
-    </method>
-
-  </class>
-
-  <!-- == Class: tx ============================================================================ -->
-
-  <class name="tx" index="90" label="work with standard transactions">
-    <doc>
-      Standard transactions provide so-called "1.5 phase commit". We can ensure that work is never
-      lost, but there is a chance of confirmations being lost, so that messages may be resent.
-      Applications that use standard transactions must be able to detect and ignore duplicate
-      messages.
-    </doc>
-
-    <doc type="grammar">
-      tx  = C:SELECT
-          / C:COMMIT
-          / C:ROLLBACK
-    </doc>
-
-    <rule name="duplicate-tracking">
-      <doc>
-        An client using standard transactions SHOULD be able to track all messages received within a
-        reasonable period, and thus detect and reject duplicates of the same message. It SHOULD NOT
-        pass these to the application layer.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="SHOULD" />
-    <chassis name="client" implement="MAY" />
-
-    <!-- - Method: tx.select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="select" synchronous="1" index="10" label="select standard transaction mode">
-      <doc>
-        This method sets the session to use standard transactions. The client must use this method
-        at least once on a session before using the Commit or Rollback methods.
-      </doc>
-      <chassis name="server" implement="MUST" />
-    </method>
-
-    <!-- - Method: tx.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="commit" synchronous="1" index="20" label="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" />
-    </method>
-
-    <!-- - Method: tx.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="rollback" synchronous="1" index="30" label="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" />
-    </method>
-
-  </class>
-
-  <!-- == Class: dtx-demarcation =============================================================== -->
-
-  <!-- NOTE: (TODO) Comments on AMQP-4 JIRA made since the proposed XML was posted on June 1 have
-    not yet been incorporated here.
-  -->
-
-  <class name="dtx-demarcation" index="100" label="Demarcates dtx branches">
-    <doc>
-      This class is part of the X-Open XA distributed transaction protocol support. It allows a
-      session to be selected for use with distributed transactions and the transactional boundaries
-      for work on that session to be demarcated.
-    </doc>
-
-    <doc type="grammar">
-      dtx-demarcation = C:SELECT *demarcation
-      demarcation     = C:START C:END
-    </doc>
-
-    <rule name="access-control">
-      <doc>
-        Access-tickets are propagated with XA association methods with the aim of restricting which
-        users are allowed to control which transactions. The server MAY restrict transaction
-        association to a particular identity.
-      </doc>
-    </rule>
-
-    <rule name="transactionality">
-      <doc>
-        Enabling XA transaction support on a session implies that the server MUST manage
-        transactions demarcated by start-end blocks. That is to say that on this XA-enabled session,
-        work undergone within transactional blocks is performed on behalf a transaction branch
-        whereas work performed outside of transactional blocks is NOT transactional.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MAY" />
-    <chassis name="client" implement="MAY" />
-
-
-    <!-- - Method: dtx-demarcation.select  - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="select" synchronous="1" index="10" label="Select dtx mode">
-      <doc>
-        This method sets the session to use distributed transactions. The client must use this
-        method at least once on a session before using XA demarcation operations.
-      </doc>
-
-      <chassis name="server" implement="MAY" />
-    </method>
-
-    <!-- - Method: dtx-demarcation.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="start" synchronous="1" index="20" label="Start a dtx branch">
-      <doc>
-        This method is called when messages should be produced and consumed on behalf a transaction
-        branch identified by xid.
-      </doc>
-
-      <rule name="command-invalid" on-failure="command-invalid">
-        <doc>
-          If the method is invoked in an improper context (see class grammar) then the server MUST
-          raise a channel exception with reply code 503 (command invalid)
-        </doc>
-      </rule>
-
-      <rule name="already-known" on-failure="not-allowed">
-        <doc>
-          If neither join nor resume is specified is specified and the transaction branch specified
-          by xid has previously been seen then the server MUST raise a channel exception with reply
-          code 530 (not allowed).
-        </doc>
-      </rule>
-
-      <rule name="join-and-resume" on-failure="command-invalid">
-        <doc>
-          If join and resume are specified then the server MUST raise a channel exception with reply
-          code 503 (command invalid).
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch to be started.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-allowed">
-          <doc>
-            If xid is already known by the broker then the server MUST raise a channel exception
-            with reply code 530 (not allowed).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="join" domain="bit" label="Join with existing xid flag">
-        <doc>
-          Indicate whether this is joining an already associated xid. Indicate that the start
-          applies to joining a transaction previously seen.
-        </doc>
-
-        <rule name="unsupported" on-failure="not-implemented">
-          <doc>
-            If the broker does not support join the server MUST raise a channel exception with reply
-            code 540 (not implemented).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="resume" domain="bit" label="Resume flag">
-        <doc>
-          Indicate that the start applies to resuming a suspended transaction branch specified.
-        </doc>
-
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="21">
-          <doc>
-            This confirms to the client that the transaction branch is started or specify the error
-            condition.
-          </doc>
-
-          <field name="status" domain="short" label="Status code">
-            <doc>
-              The value of this field may be one of the following constants:
-
-              xa-ok: Normal execution.
-
-              xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
-                  reason.
-
-              xa-rbtimeout: The work represented by this transaction branch took too long.
-            </doc>
-
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-    <!-- - Method: dtx-demarcation.end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="end" synchronous="1" index="30" label="End a dtx branch">
-      <doc>
-        This method is called when the work done on behalf a transaction branch finishes or needs to
-        be suspended.
-      </doc>
-
-      <rule name="command-invalid" on-failure="command-invalid">
-        <doc>
-          If the method is invoked in an improper context (see class grammar) then the server MUST
-          raise a channel exception with reply code 503 (command invalid).
-        </doc>
-      </rule>
-
-      <rule name="suspend-and-fail" on-failure="command-invalid">
-        <doc>
-          If suspend and fail are specified then the server MUST raise a channel exception with
-          reply code 503 (command invalid).
-        </doc>
-      </rule>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in ending the transaction branch then the server MUST raise a channel
-          exception with reply code 541 (internal error).
-        </doc>
-      </rule>
-
-      <rule name="success">
-        <doc>
-          If neither fail nor suspend are specified then the portion of work has completed
-          successfully.
-        </doc>
-      </rule>
-
-      <rule name="session-closed">
-        <doc>
-          When a session is closed then the currently associated transaction branches MUST be marked
-          rollback-only.
-        </doc>
-      </rule> 
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch to be ended.
-        </doc>
-
-        <rule name="not-associated" on-failure="command-invalid">
-          <doc>
-            The channel MUST be currently associated with the given xid (through an earlier start
-            call with the same xid). 
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="fail" domain="bit" label="Failure flag">
-        <doc>
-          If set, indicates that this portion of work has failed; otherwise this portion of work has
-          completed successfully.
-        </doc>
-
-        <rule name="failure">
-          <doc>
-            An implementation MAY elect to roll a transaction back if this failure notification is
-            recieved. Should an implementation elect to implement this behaviour, and this bit is
-            set, then then the transaction branch SHOULD be marked as rollback-only and the end
-            result SHOULD have the xa-rbrollback status set.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="suspend" domain="bit" label="Temporary suspension flag">
-        <doc>
-          Indicates that the transaction branch is temporarily suspended in an incomplete state.
-        </doc>
-
-        <rule name="resume">
-          <doc>
-            The transaction context is in a suspended state and must be resumed via the start method
-            with resume specified.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="31">
-          <doc>
-            This method confirms to the client that the transaction branch is ended or specify the
-            error condition.
-          </doc>
-
-          <field name="status" domain="short" label="Status code">
-            <doc>
-              The value of this field may be one of the following constants:
-
-              xa-ok: Normal execution.
-
-              xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
-                  reason. If an implementation chooses to implement rollback-on-failure behaviour, then
-                  this value should be selected if the dtx-demarcation.end.fail bit was set.
-
-              xa-rbtimeout: The work represented by this transaction branch took too long.
-            </doc>
-
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-  </class>
-
-
-  <!-- == Class: dtx-coordination ============================================================== -->
-
-  <class name="dtx-coordination" index="105" label="Coordinate dtx outcomes">
-    <doc>
-      This class is part of the X-Open XA distributed transaction protocol support. It allows the
-      transaction manager to coordinate transaction outcomes.
-    </doc>
-
-    <doc type="grammar">
-      dtx-coordination    = *coordination
-      coordination        = command
-                          / outcome
-                          / recovery
-      command             = C:SET-TIMEOUT
-                          / C:GET-TIMEOUT
-      outcome             = one-phase-commit
-                          / one-phase-rollback
-                          / two-phase-commit
-                          / two-phase-rollback
-      one-phase-commit    = C:COMMIT
-      one-phase-rollback  = C:ROLLBACK
-      two-phase-commit    = C:PREPARE C:COMMIT
-      two-phase-rollback  = C:PREPARE C:ROLLBACK
-      recovery            = C:RECOVER *recovery-outcome
-      recovery-outcome    = one-phase-commit
-                          / one-phase-rollback
-                          / C:FORGET
-    </doc>
-
-    <rule name="security">
-      <doc>
-        Access-tickets are propagated with XA demarcation methods with the aim of restricting which
-        users are allowed to control which transactions. The server MAY restrict transaction
-        coordination to a particular identity.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MAY" />
-    <chassis name="client" implement="MAY" />
-
-    <!-- - Method: dtx-coordination.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="commit" synchronous="1" index="10" label="Commit work on dtx branch">
-      <doc>
-        Commit the work done on behalf a transaction branch. This method commits the work associated
-        with xid. Any produced messages are made available and any consumed messages are discarded.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in committing the transaction branch then the server MUST raise a
-          channel exception with reply code 541 (internal error)
-        </doc>
-      </rule>
-
-      <rule name="command-invalid" on-failure="command-invalid">
-        <doc>
-          If the method is invoked in an improper context (see class grammar) then the server MUST
-          raise a channel exception with reply code 503 (command invalid)
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch to be committed.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-found">
-          <doc>
-            If xid is unknown (the transaction branch has not been started or has already been
-            ended) then the server MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-
-        <rule name="not-disassociated" on-failure="command-invalid">
-          <doc>
-            If this method is called when xid is still associated with a session then the server
-            MUST raise a channel exception with reply code 503 (command invalid)
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="one-phase" domain="bit" label="One-phase optimization flag">
-        <doc>
-          When set then one-phase commit optimization is used.
-        </doc>
-
-        <rule name="prerequisite" on-failure="command-invalid">
-          <doc>
-            This bit MUST be set if a commit is sent without a preceding prepare.
-          </doc>
-        </rule>
-
-        <rule name="validity" on-failure="command-invalid">
-          <doc>
-            This bit MUST NOT be set if a preceding prepare has been sent.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="11">
-          <doc>
-            This confirms to the client that the transaction branch is committed or specify the
-            error condition.
-          </doc>
-
-          <field name="status" domain="short" label="Status code">
-            <doc>
-              The value of this field may be one of the following constants:
-
-              xa-ok: Normal execution
-
-              xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction
-                  branch may have been heuristically completed.
-
-              xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified
-                  transaction branch was committed.
-
-              xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified
-                  transaction branch was rolled back.
-
-              xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified
-                transaction branch was partially committed and partially rolled back.
-
-              xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
-                  reason.
-
-              xa-rbtimeout: The work represented by this transaction branch took too long.
-            </doc>
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-    <!-- - Method: dtx-coordination.forget - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="forget" synchronous="1" index="20" label="Discard dtx branch">
-      <doc>
-        This method is called to forget about a heuristically completed transaction branch.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in forgetting the transaction branch then the server MUST raise a
-          channel exception with reply code 541 (internal error)
-        </doc>
-      </rule>
-
-      <rule name="command-invalid" on-failure="command-invalid">
-        <doc>
-          If the method is invoked in an improper context (see class grammar) then the server MUST
-          raise a channel exception with reply code 503 (command invalid)
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch to be forgotten.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-found">
-          <doc>
-            If xid is unknown (the transaction branch has not been started or has already been
-            ended) then the server MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-
-        <rule name="not-disassociated" on-failure="command-invalid">
-          <doc>
-            If this method is called when xid is still associated with a session then the server
-            MUST raise a channel exception with reply code 503 (command invalid).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-    </method>
-
-    <!-- - Method: dtx-coordination.get-timeout  - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="get-timeout" synchronous="1" index="30" label="Obtain dtx timeout in seconds">
-      <doc>
-        This method obtains the current transaction timeout value in seconds. If set-timeout was not
-        used prior to invoking this method, the return value is the default timeout; otherwise, the
-        value used in the previous set-timeout call is returned.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in setting the transaction timeout then the server MUST raise a channel
-          exception with reply code 541 (internal error).
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch for getting the timeout.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-found">
-          <doc>
-            If xid is unknown (the transaction branch has not been started or has already been
-            ended) then the server MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="31">
-          <doc>
-            Returns the value of the timeout last specified through set-timeout.
-          </doc>
-
-          <field name="timeout" domain="long" label="The current transaction timeout value">
-            <doc>
-              The current transaction timeout value in seconds.
-            </doc>
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-    <!-- - Method: dtx-coordination.prepare  - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="prepare" synchronous="1" index="40" label="Prepare a dtx branch">
-      <doc>
-        This method prepares for commitment any message produced or consumed on behalf of xid.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in preparing the transaction branch then the server MUST raise a
-          channel exception with reply code 541 (internal error). The specified xid may or may not
-          have been prepared.
-        </doc>
-      </rule>
-
-      <rule name="command-invalid" on-failure="command-invalid">
-        <doc>
-          If the method is invoked in an improper context (see class grammar) then the server MUST
-          raise a channel exception with reply code 503 (command invalid)
-        </doc>
-      </rule>
-
-      <rule name="obligation-1">
-        <doc>
-          Once this method successfully returns it is guaranteed that the transaction branch may be
-          either committed or rolled back regardless of failures.
-        </doc>
-      </rule>
-
-      <rule name="obligation-2">
-        <doc>
-          The knowledge of xid cannot be erased before commit or rollback complete the branch.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch that can be prepared.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-found">
-          <doc>
-            If xid is unknown (the transaction branch has not been started or has already been
-            ended) then the server MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-
-        <rule name="not-disassociated" on-failure="command-invalid">
-          <doc>
-            If this method is called when xid is still associated with a session then the server
-            MUST raise a channel exception with reply code 503 (command invalid)
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="41">
-          <doc>
-            This method confirms to the client that the transaction branch is prepared or specify the
-            error condition.
-          </doc>
-
-          <field name="status" domain="short" label="Status code">
-            <doc>
-              The value of this field may be one of the following constants:
-
-              xa-ok: Normal execution.
-
-              xa-rdonly: The transaction branch was read-only and has been committed.
-
-              xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
-                  reason.
-
-              xa-rbtimeout: The work represented by this transaction branch took too long.
-            </doc>
-
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-    <!-- - Method: dtx-coordination.recover  - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="recover" synchronous="1" index="50" label="Get prepared or completed xids">
-      <doc>
-        This method is called to obtain a list of transaction branches that are in a prepared or
-        heuristically completed state.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in recovering then the server MUST raise a channel exception with reply
-          code 541 (internal error)
-        </doc>
-      </rule>
-
-      <rule name="start-end">
-        <doc>
-          If this endscan is used in conjunction with startscan then a single call starts and then
-          ends a scan.
-        </doc>
-      </rule>
-
-      <rule name="must-be-started" on-failure="command-invalid">
-        <doc>
-          If none of endscan and startscan are set then a recovery scan must already be started
-          otherwise the server MUST raise a channel exception with reply code 503 (command invalid)
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="startscan" domain="bit" label="Start recovery scan flag">
-        <doc>
-          Indicates that recovery scan should start.
-        </doc>
-
-        <rule name="recovery-already-open">
-          <doc>
-            If a recovery scan is already open, the effect is as if the recovery scan were ended and
-            then restarted.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="endscan" domain="bit" label="Flag indicating end scan on return of xids">
-        <doc>
-          Indicates that the recovery scan should end after returning the xids.
-        </doc>
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="51">
-          <doc>
-            Returns to the client a table with single item that is a sequence of transaction xids that
-            are in a prepared or heuristically completed state.
-          </doc>
-
-          <field name="in-doubt" domain="table" label="Table of xids to be recovered">
-            <doc>
-              Table containing the sequence of xids to be recovered (xids that are in a prepared or
-              heuristically completed state).
-            </doc>
-
-            <rule name="xid-sequence">
-              <doc>
-                The field table must contain a field called 'xids' of type sequence of longstrs
-                representing the xids that are in a prepared or heuristically completed state.
-              </doc>
-            </rule>
-
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-    <!-- - Method: dtx-coordination.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="rollback" synchronous="1" index="60" label="Rollback a dtx branch">
-      <doc>
-        This method rolls back the work associated with xid. Any produced messages are discarded and
-        any consumed messages are re-enqueued.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in rolling back the transaction branch then the server MUST raise a
-          channel exception with reply code 541 (internal error)
-        </doc>
-      </rule>
-
-      <rule name="command-invalid" on-failure="command-invalid">
-        <doc>
-          If the method is invoked in an improper context (see class grammar) then the server MUST
-          raise a channel exception with reply code 503 (command invalid)
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch that can be rolled back.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-found">
-          <doc>
-            If xid is unknown (the transaction branch has not been started or has already been
-            ended) then the server MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-
-        <rule name="not-disassociated" on-failure="command-invalid">
-          <doc>
-            If this method is called when xid is still associated with a session then the server
-            MUST raise a channel exception with reply code 503 (command invalid)
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <result>
-        <struct size="long" type="61">
-          <doc>
-            This method confirms to the client that the transaction branch is rolled back or specify the
-            error condition.
-          </doc>
-
-          <field name="status" domain="short" label="Status code">
-            <doc>
-              The value of this field may be one of the following constants:
-
-              xa-ok: Normal execution
-
-              xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction
-                  branch may have been heuristically completed.
-
-              xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified
-                  transaction branch was committed.
-
-              xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified
-                  transaction branch was rolled back.
-
-              xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified
-                  transaction branch was partially committed and partially rolled back.
-
-              xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
-                  reason.
-
-              xa-rbtimeout: The work represented by this transaction branch took too long.
-            </doc>
-            <assert check="notnull" />
-          </field>
-        </struct>
-      </result>
-    </method>
-
-    <!-- - Method: dtx-coordination.set-timeout  - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="set-timeout" synchronous="1" index="70" label="Set dtx timeout value">
-      <doc>
-        Sets the specified transaction branch timeout value in seconds.
-      </doc>
-
-      <rule name="internal-error" on-failure="internal-error">
-        <doc>
-          If an error occurs in setting the transaction timeout then the server MUST raise a channel
-          exception with reply code 541 (internal error)
-        </doc>
-      </rule>
-
-      <rule name="effective">
-        <doc>
-          Once set, this timeout value is effective until this method is reinvoked with a different
-          value.
-        </doc>
-      </rule>
-
-      <rule name="reset">
-        <doc>
-          A value of zero resets the timeout value to the default value.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MAY" />
-
-      <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm">
-        <doc>
-          Access-ticket granted by the server for a specific realm.
-        </doc>
-
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "active" access rights to all the
-            realms touched by this transaction.
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="xid" domain="xid" label="Transaction xid">
-        <doc>
-          Specifies the xid of the transaction branch for setting the timeout.
-        </doc>
-
-        <rule name="unknown-xid" on-failure="not-found">
-          <doc>
-            If xid is unknown (the transaction branch has not been started or has already been
-            ended) then the server MUST raise a channel exception with reply code 404 (not found).
-          </doc>
-        </rule>
-
-        <assert check="notnull" />
-      </field>
-
-      <field name="timeout" domain="long" label="Dtx timeout in seconds">
-        <doc>
-          The transaction timeout value in seconds.
-        </doc>
-        <assert check="notnull" />
-      </field>
-    </method>
-
-  </class>
-
-
-  <!-- == Class: tunnel ========================================================================= -->
-
-  <class name="tunnel" index="110" label="methods for protocol tunnelling">
-    <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 type="grammar">
-      tunnel  = C:REQUEST
-              / S:REQUEST
-    </doc>
-
-    <chassis name="server" implement="MAY" />
-    <chassis name="client" implement="MAY" />
-
-    <field name="headers" domain="table" label="message header field table" />
-    <field name="proxy-name" domain="shortstr" label="identity of tunnelling proxy" />
-    <field name="data-name" domain="shortstr" label="name or type of message being tunnelled" />
-    <field name="durable" domain="octet" label="message durability indicator" />
-    <field name="broadcast" domain="octet" label="message broadcast mode" />
-
-    <!-- - Method: tunnel.request  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="request" content="1" index="10" label="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" domain="table" label="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: message ======================================================================= -->
-
-  <class name="message" index="120" label="message transfer">
-    <doc>
-      The message class provides methods that support an industry-standard messaging model.
-    </doc>
-
-    <doc type="grammar">
-      message = C:QOS
-              / C:CONSUME
-              / C:CANCEL
-              / C:TRANSFER [ S:REJECT ]
-              / S:TRANSFER [ C:REJECT ]
-              / C:GET [ S:EMPTY ]
-              / C:RECOVER
-              / C:OPEN
-              / S:OPEN
-              / C:APPEND
-              / S:APPEND
-              / C:CLOSE
-              / S:CLOSE
-              / C:CHECKPOINT
-              / S:CHECKPOINT
-              / C:RESUME S:OFFSET
-              / S:RESUME C:OFFSET
-    </doc>
-
-    <rule name="persistent-message">
-      <doc>
-        The server SHOULD respect the persistent property of messages and SHOULD make a best-effort
-        to hold persistent mess ages on a reliable storage mechanism.
-      </doc>
-      <doc type="scenario">
-        Send a persistent message to queue, stop server, restart server and then verify whether
-        message is still present. Assumes that queues are durable. Persistence without durable
-        queues makes no sense.
-      </doc>
-    </rule>
-
-    <rule name="no-persistent-message-discard">
-      <doc>
-        The server MUST NOT discard a persistent message in case of a queue overflow.
-      </doc>
-      <doc type="scenario">
-        Create a queue overflow situation with persistent messages and verify that messages do not
-        get lost (presumably the server will write them to disk).
-      </doc>
-    </rule>
-
-    <rule name="throttling">
-      <doc>
-        The server MAY use the Session.Flow method to slow or stop a message publisher when
-        necessary.
-      </doc>
-      <doc type="scenario">
-        Create a queue overflow situation with non-persistent messages and verify whether the server
-        responds with Session.Flow or not. Repeat with persistent messages.
-      </doc>
-    </rule>
-
-    <rule name="non-persistent-message-overflow">
-      <doc>
-        The server MAY overflow non-persistent messages to persistent storage.
-      </doc>
-    </rule>
-
-    <rule name="non-persistent-message-discard">
-      <doc>
-        The server MAY discard or dead-letter non-persistent messages on a priority basis if the
-        queue size exceeds some configured limit.
-      </doc>
-    </rule>
-
-    <rule name="min-priority-levels">
-      <doc>
-        The server MUST implement at least 2 priority levels for messages, where priorities 0-4 and
-        5-9 are treated as two distinct levels.
-      </doc>
-      <doc type="scenario">
-        Send a number of priority 0 messages to a queue. Send one priority 9 message. Consume
-        messages from the queue and verify that the first message received was priority 9.
-      </doc>
-    </rule>
-
-    <rule name="max-priority-levels">
-      <doc>
-        The server MAY implement up to 10 priority levels.
-      </doc>
-      <doc type="scenario">
-        Send a number of messages with mixed priorities to a queue, so that all priority values from
-        0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume
-        from queue and verify how many priority levels emerge.
-      </doc>
-    </rule>
-
-    <rule name="priority-delivery">
-      <doc>
-        The server MUST deliver messages of the same priority in order irrespective of their
-        individual persistence.
-      </doc>
-      <doc type="scenario">
-        Send a set of messages with the same priority but different persistence settings to a queue.
-        Consume and verify that messages arrive in same order as originally published.
-      </doc>
-    </rule>
-
-    <rule name="automatic-acknowledgements">
-      <doc>
-        The server MUST support automatic acknowledgements on messages, i.e. consumers with the
-        no-ack field set to FALSE.
-      </doc>
-      <doc type="scenario">
-        Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to
-        the queue. Consume the messages and verify that all messages are received.
-      </doc>
-    </rule>
-
-    <rule name="explicit-acknowledgements">
-      <doc>
-        The server MUST support explicit acknowledgements on messages, i.e. consumers with the
-        no-ack field set to TRUE.
-      </doc>
-      <doc type="scenario">
-        Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to
-        the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect,
-        and consume from the queue. Verify that the remaining messages are received.
-      </doc>
-    </rule>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MUST" />
-
-    <!-- - Method: message.transfer  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="transfer" content="1" index="10" label="transfer a message">
-      <doc>
-        This method transfers a message between two peers. When a client uses this method to publish
-        a message to a broker, the destination identifies a specific exchange. The message will then
-        be routed to queues as defined by the exchange configuration and distributed to any active
-        subscriptions when the transaction, if any, is committed.
-
-        The client may initiate transfers from the broker by starting a subscription using the
-        subscribe method and passing in a destination, then the broker responds with transfer
-        methods to the specified destination as and when messages arrive in the subscribed queue.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket" label="access ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "passive" access rights to the
-            realm for the exchange and "write" access rights to the realm for the queue to which the
-            message will be published.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="destination" domain="destination" label="message destination">
-        <doc>
-          Specifies the destination to which the message is to be transferred. The destination can
-          be empty, meaning the default exchange or subscription. If the destination is specified,
-          and that exchange or subscription does not exist, the peer must raise a channel exception.
-        </doc>
-
-        <rule name="blank-destination">
-          <doc>
-            The server MUST accept a blank destination to mean the default exchange.
-          </doc>
-        </rule>
-
-        <rule name="internal-exchange">
-          <doc>
-            If the destination refers to an internal exchange, the server MUST raise a channel
-            exception with a reply code 403 (access refused).
-          </doc>
-        </rule>
-
-        <rule name="message-refusal">
-          <doc>
-            A destination MAY refuse message content in which case it MUST raise a channel exception
-            with reply code 540 (not implemented).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="confirm-mode" domain="confirm-mode" />
-      <field name="acquire-mode" domain="acquire-mode" />
-    </method>
-
-    <!-- - Method: message.reject  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="reject" index="160" label="reject a message">
-      <doc>
-        Indicates that the message transfers are un-processable in some way. A message may be
-        rejected for a number of reasons. A server may reject a message if it is unroutable. A
-        client may reject a message if it is invalid.
-      </doc>
-
-      <rule name="alternate-exchange">
-        <doc>
-          When a client rejects a message, the server MUST deliver that message to the
-          alternate-exchange on the queue from which it was delivered. If no alternate-exchange is
-          defined for that queue the broker MAY discard the message.
-        </doc>
-      </rule>
-
-      <rule name="acquisition">
-        <doc>
-          The recipient MUST have acquired a message in order to reject it. If the message is not
-          acquired any reject MUST be ignored.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MAY" />
-
-      <field name="transfers" domain="correlation" />
-      <field name="code" domain="reject-code" />
-      <field name="text" domain="reject-text" />
-    </method>
-
-    <!-- - Method: message.acquire - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="acquire" index="170" label="acquire messages for consumption">
-      <doc>
-        Acquires previously transferred messages for consumption. The acquired ids (if any) are
-        sent via message.acquired.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="transfers" domain="correlation" />
-      <!-- do we need this field? -->
-      <field name="mode" domain="octet">
-        <doc>
-          One of:
-            - any (0): acquire any available messages for consumption
-            - all (1): only acquire messages if all are available for consumption
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: message.acquired  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="acquired" index="180" label="indicates acquired messages">
-      <doc>
-        Identifies a set of previously transferred messages now available for consumption.
-      </doc>
-
-      <chassis name="client" implement="MAY" />
-
-      <field name="transfers" domain="correlation" />
-    </method>
-
-    <!-- - Method: message.release - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="release" index="190" label="release a message">
-      <doc>
-        Release previously transferred messages that have been acquired for consumption (whether
-        implicitly or explicitly). Released messages will be available for acquisition by other
-        consumers. The order of released messages may be lost.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MAY" />
-
-      <field name="transfers" domain="correlation" />
-    </method>
-
-    <!-- - Method: message.subscribe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="subscribe" index="20" label="start a queue subscription">
-      <doc>
-        This method asks the server to start a "subscription", which is a transient request for
-        messages from a specific queue. Subscriptions last as long as the session they were created
-        on, or until the client cancels them.
-      </doc>
-
-      <rule name="simultaneous-subscriptions">
-        <doc>
-          The server SHOULD support at least 16 subscriptions per queue, and ideally, impose no
-          limit except as defined by available resources.
-        </doc>
-        <doc type="scenario">
-          Create a queue and create subscriptions on that queue until the server closes the
-          connection. Verify that the number of subscriptions created was at least sixteen and
-          report the total number.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "read" access rights to the realm
-            for the subscribed queue.
-          </doc>
-          <doc type="scenario">
-            Attempt to create a subscription with an invalid (non-zero) access ticket.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="queue" domain="queue-name">
-        <doc>
-          Specifies the name of the subscribed queue.
-        </doc>
-      </field>
-
-      <field name="destination" domain="destination" label="incoming message destination">
-        <doc>
-          Specifies the destination for the subscription. The destination is local to a connection,
-          so two clients can use the same destination.
-        </doc>
-
-        <rule name="destination-non-existing-subscription" on-failure="not-allowed">
-          <doc>
-            The client MUST NOT specify a destination that refers to an existing subscription.
-          </doc>
-          <doc type="scenario">
-            Attempt to create two subscriptions with the same non-empty destination.
-          </doc>
-        </rule>
-
-        <rule name="destination-session-bound" on-failure="not-allowed">
-          <doc>
-            The destination is valid only within the session from which the subscription was
-            created. i.e. A client MUST NOT create a subscription in one session and then use it in
-            another.
-          </doc>
-          <doc type="scenario">
-            Attempt to create a subscription in one session, then use in another session, in which
-            subscriptions have also been created (to test that the server uses unique destinations).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="no-local" domain="no-local" label="messages not returned to publisher">
-        <doc>
-          If the no-local field is set the server will not send messages to the connection that
-          published them.
-        </doc>
-      </field>
-
-      <field name="confirm-mode" domain="confirm-mode">
-        <doc>
-          The default confirm-mode for this subscription.
-        </doc>
-      </field>
-
-      <field name="acquire-mode" domain="acquire-mode">
-        <doc>
-          The default acquire-mode for this subscription.
-        </doc>
-      </field>
-
-      <field name="exclusive" domain="bit" label="request exclusive access">
-        <doc>
-          Request exclusive subscription access, meaning only this subscription can access the queue.
-        </doc>
-
-        <rule name="in-use" on-failure="access-refused">
-          <doc>
-            The client MUST NOT gain exclusive access to a queue that already has active subscriptions.
-          </doc>
-          <doc type="scenario">
-            Open two connections to a server, and in one connection create a shared (non-exclusive)
-            queue and then subscribe to the queue. In the second connection attempt to subscribe to
-            the same queue using the exclusive option.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="filter" domain="table" label="arguments for filtering">
-        <doc>
-          A set of filters for the subscription. The syntax and semantics of these filters depends
-          on the providers implementation.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: message.cancel  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="cancel" index="30" label="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. The client may receive an
-        arbitrary number of messages in between sending the cancel method and receiving the
-        notification of completion of the cancel command.
-      </doc>
-
-      <rule name="ignore">
-        <doc>
-          If the queue does not exist the server MUST ignore the cancel method, so long as the
-          consumer tag is valid for that session.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="destination" domain="destination" />
-    </method>
-
-    <!-- - Method: message.get - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="get" index="40" label="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>
-
-      <chassis name="server" implement="MUST" />
-
-      <!-- 
-      <response name="empty" />
-      -->
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="ticket-required" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "read" access rights to the realm
-            for the queue from which the message will be consumed.
-          </doc>
-        </rule>
-      </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 session, which is the last declared queue.
-        </doc>
-        <rule name="empty-name">
-          <doc>
-            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>
-        </rule>
-      </field>
-
-      <field name="destination" domain="destination">
-        <doc>
-          On normal completion of the get request (i.e. a response of ok). A message will be
-          transferred to the supplied destination.
-        </doc>
-      </field>
-
-      <field name="no-ack" domain="no-ack" />
-    </method>
-
-    <!-- - Method: message.recover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="recover" index="50" label="redeliver unacknowledged messages">
-      <doc>
-        This method asks the broker to redeliver all unacknowledged messages on a specified session.
-        Zero or more messages may be redelivered. This method is only allowed on non-transacted
-        sessions.
-      </doc>
-
-      <rule name="redelivered-flag">
-        <doc>
-          The server MUST set the redelivered flag on all messages that are resent.
-        </doc>
-      </rule>
-
-      <rule name="transacted-session">
-        <doc>
-          The server MUST raise a channel exception if this is called on a transacted session.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="requeue" domain="bit" label="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>
-    </method>
-
-    <!-- - Method: message.open  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="open" index="60" label="create a reference to an empty message body">
-      <doc>
-        This method creates a reference. A references provides a means to send a message body into a
-        temporary area at the recipient end and then deliver the message by referring to this
-        temporary area. This is how the protocol handles large message transfers.
-
-        The scope of a ref is defined to be between calls to open (or resume) and close. Between
-        these points it is valid for a ref to be used from any content data type, and so the
-        receiver must hold onto its contents. Should the session be closed when a ref is still in
-        scope, the receiver may discard its contents (unless it is checkpointed). A ref that is in
-        scope is considered open.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="reference" domain="reference">
-        <rule name="duplicate-reference">
-          <doc>
-            The recipient MUST generate an error if the reference is currently open (in scope).
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: message.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="close" index="70" label="close a reference">
-      <doc>
-        This method signals the recipient that no more data will be appended to the reference.
-      </doc>
-
-      <rule name="message-acknowledge-after-close">
-        <doc>
-          A recipient MUST NOT acknowledge a message until its reference is closed (not in scope).
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="reference" domain="reference" label="target reference">
-        <rule name="non-existent-reference">
-          <doc>
-            The recipient MUST generate an error if the reference was not previously open (in
-            scope).
-          </doc>
-        </rule>
-      </field>
-    </method>
-
-    <!-- - Method: message.append  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="append" index="80" label="append to a reference">
-      <doc>This method appends data to a reference.</doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="reference" domain="reference" label="target reference">
-        <rule name="non-existent-reference">
-          <doc>
-            The recipient MUST generate an error if the reference is not open (not in scope).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="bytes" domain="longstr" label="data to append" />
-    </method>
-
-    <!-- - Method: message.checkpoint  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="checkpoint" index="90" label="checkpoint a message body">
-      <doc>
-        This method provides a means to checkpoint large message transfer. The sender may ask the
-        recipient to checkpoint the contents of a reference using the supplied identifier. The
-        sender may then resume the transfer at a later point. It is at the discretion of the
-        recipient how much data to save with the checkpoint, and the sender MUST honour the offset
-        returned by the resume method.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="reference" domain="reference" label="target reference">
-        <rule name="non-existent-reference">
-          <doc>
-            The recipient MUST generate an error if the reference is not open (not in scope).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="identifier" domain="shortstr" label="checkpoint identifier">
-        <doc>
-          This is the checkpoint identifier. This is an arbitrary string chosen by the sender. For
-          checkpointing to work correctly the sender must use the same checkpoint identifier when
-          resuming the message. A good choice for the checkpoint identifier would be the SHA1 hash
-          of the message properties data (including the original filename, revised time, etc.).
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: message.resume  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="resume" index="100" label="open and resume a checkpointed message">
-      <doc>
-        This method resumes a reference from the last checkpoint. A reference is considered to be
-        open (in scope) after a resume even though it will not have been opened via the open method
-        during this session.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <response name="offset" />
-
-      <field name="reference" domain="reference" label="target reference">
-        <rule name="non-existent-reference">
-          <doc>
-            The recipient MUST generate an error if the reference is currently open (in scope).
-          </doc>
-        </rule>
-      </field>
-
-      <field name="identifier" domain="shortstr" label="checkpoint identifier" />
-    </method>
-
-    <!-- - Method: message.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="qos" index="110" label="specify quality of service">
-      <doc>
-        This method requests a specific quality of service. The QoS can be specified for the current
-        session or for all sessions 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" />
-
-      <field name="prefetch-size" domain="long" label="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 within the session. 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>
-        <rule name="non-responsive-client">
-          <doc>
-            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>
-          <doc type="scenario">
-            Define a QoS prefetch-size limit and send a single message that exceeds that limit.
-            Verify that the message arrives correctly.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="prefetch-count" domain="short" label="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 session and connection level) allow it. The
-          prefetch-count is ignored if the no-ack option is set.
-        </doc>
-        <rule name="prefetch-maximum">
-          <doc>
-            The server may send less data in advance than allowed by the client's specified prefetch
-            windows but it MUST NOT send more.
-          </doc>
-          <doc type="scenario">
-            Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send
-            multiple messages that exceed the prefetch size. Verify that no more than one message
-            arrives at once.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="global" domain="bit" label="apply to entire connection">
-        <doc>
-          By default the QoS settings apply to the current session only. If this field is set, they
-          are applied to the entire connection.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: message.flow-mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="flow-mode" index="120" label="set the flow control mode">
-      <doc>
-        Sets the mode of flow control used for a given destination.
-
-        With credit based flow control, the sender of messages continually maintains its current
-        credit balance with the recipient. The credit balance consists of two values, a message
-        count, and a byte count. Whenever message data is sent, both counts must be decremented.
-        If either value reaches zero, the flow of message data must stop. Additional credit is
-        received via the message.flow method.
-
-        The sender MUST NOT send partial framesets. This means that if there is not enough byte
-        credit available to send a complete message, the sender must either wait or use chunked
-        transfer to send the first part of the message data in a complete frameset.
-
-        Window based flow control is identical to credit based flow control, however message
-        acknowledgment implicitly grants a single unit of message credit, and the size of the
-        message in byte credits for each acknowledged message.
-      </doc>
-
-      <rule name="byte-accounting">
-        <doc>
-          The byte count is decremented by the payload size of each transmitted frame with
-          segment type header or body appearing within a message.transfer command. Note that
-          the payload size is the frame size less the frame header size (frame-size - 12).
-        </doc>
-      </rule>
-
-      <rule name="mode-switching">
-        <doc>
-          Mode switching may only occur if both outstanding credit balances are zero. There are
-          three ways for a recipient of messages to be sure that the sender 's credit balance is
-          zero:
-
-            1) The recipient may send a message.stop command to the sender. When the recipient
-               receives confirmation of completion for the message.stop command, it knows that the
-               sender's credit is zero.
-
-            2) The recipient may perform the same steps described in (1) with the message.flush
-               command substituted for the message.stop command.
-
-            3) Immediately after receiving a message.consume, the credit for that destination
-               defaults to zero.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="destination" domain="destination" />
-      <field name="mode" domain="octet">
-        <doc>
-          One of:
-            - credit (0): choose credit based flow control
-            - window (1): choose window based flow control
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: message.flow  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="flow" index="130" label="control message flow">
-      <doc>
-        This method controls the flow of message data to a given destination. It is used by the
-        recipient of messages to dynamically match the incoming rate of message flow to its
-        processing or forwarding capacity. Upon receipt of this method, the sender must add "value"
-        number of the specified unit to the available credit balance for the specified destination.
-        A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for
-        the given unit until the credit balance is zeroed with message.stop or message.flush.
-      </doc>
-
-      <!-- throws no-such-destination -->
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="destination" domain="destination"/>
-      <field name="unit" domain="octet">
-        <doc>
-          Specifies the unit of credit balance.
-
-          One of:
-            - message (0)
-            - byte    (1)
-        </doc>
-      </field>
-      <field name="value" domain="long">
-        <doc>
-          A value of (0xFFFFFFFF) indicates an infinite amount of credit.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: message.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="flush" index="140">
-      <doc>
-        Forces the sender to exhaust his credit supply. The sender's credit will always be zero when
-        this method completes. The message does not complete until all the message transfers occur.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="destination" domain="destination" />
-    </method>
-
-    <!-- - Method: message.stop  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="stop" index="150">
-      <doc>
-        On receipt of this method, a producer of messages MUST set his credit to zero for the given
-        destination. This obeys the generic semantics of command completion, i.e. when confirmation
-        is issued credit MUST be zero and no further messages will be sent until such a time as
-        further credit is received.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="destination" domain="destination" />
-    </method>
-
-    <!-- - Method: message.empty - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="empty" index="200" label="empty queue">
-      <doc>
-        Signals that a queue does not contain any messages; usually sent in response to the get
-        method.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-    </method>
-
-    <!-- - Method: message.offset  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="offset" index="210" label="return an offset">
-      <doc>
-        Returns the data offset into a reference body; usually sent in response to resume method.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-      <chassis name="client" implement="MUST" />
-
-      <field name="value" domain="offset" label="offset into a reference body">
-        <doc>
-          Offset in bytes into message body data.
-        </doc>
-      </field>
-    </method>
-
-  </class>
-
-  <!-- == Class: binding ======================================================================= -->
-
-  <class name="binding" index="130"
-    label="provides the ability to query bindings">
-    <doc>
-      This is a utility class for querying and exchange about its bindings to queues.
-    </doc>
-
-    <chassis name="server" implement="MUST" />
-    <chassis name="client" implement="MAY" />
-
-    <!-- - Method: binding.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="query" synchronous="1" index="10"
-      label="request information about bindings to an exchange">
-      <doc>
-        This method is used to request information on the bindings to a particular exchange.
-      </doc>
-
-      <chassis name="server" implement="MUST" />
-
-      <field name="ticket" domain="access-ticket">
-        <rule name="validity" on-failure="access-refused">
-          <doc>
-            The client MUST provide a valid access ticket giving "passive" access rights to the
-            exchange's access realm.
-          </doc>
-        </rule>
-      </field>
-
-      <field name="exchange" domain="shortstr" label="the exchange name">
-        <doc>
-           The name of the exchange for which binding information is being requested. If not
-           specified explicitly the default exchange is implied.
-        </doc>
-      </field>
-
-      <field name="queue" domain="shortstr" label="a queue name">
-        <doc>
-          If populated then determine whether the given queue is bound to the exchange.
-        </doc>
-      </field>
-
-      <field name="routing-key" domain="shortstr" label="a routing-key">
-        <doc>
-         If populated defines the routing key of the binding of interest, if not populated the
-         request will ignore the routing key on bindings when searching for a match.
-        </doc>
-      </field>
-
-      <field name="arguments" domain="table" label="a set of binding arguments">
-        <doc>
-          If populated defines the arguments of the binding of interest if not populated the request
-          will ignore the arguments on bindings when searching for a match
-        </doc>
-      </field>
-
-      <result>
-        <struct size="long" type="11">
-          <doc>
-            This method is used in response to a query and conveys information on the bindings to a
-            particular exchange.
-          </doc>
-
-          <field name="exchange-not-found" domain="bit" label="indicate an unknown exchange">
-            <doc>
-               If set, the exchange for which information was requested is not known.
-            </doc>
-          </field>
-
-          <field name="queue-not-found" domain="bit" label="indicate an unknown queue">
-            <doc>
-               If set, the queue specified is not known.
-            </doc>
-          </field>
-
-          <field name="queue-not-matched" domain="bit" label="indicate no matching queue">
-            <doc>
-              A bit which if set indicates that no binding was found from the specified exchange to the
-              specified queue.
-            </doc>
-          </field>
-
-          <field name="key-not-matched" domain="bit" label="indicate no matching routing key">
-            <doc>
-              A bit which if set indicates that no binding was found from the specified exchange with
-              the specified routing key.
-            </doc>
-          </field>
-
-          <field name="args-not-matched" domain="bit" label="indicate no matching args">
-            <doc>
-              A bit which if set indicates that no binding was found from the specified exchange with
-              the specified arguments.
-            </doc>
-          </field>
-        </struct>
-      </result>
-    </method>
-
-  </class>
-
-  <!-- == Class: execution ===================================================================== -->
-
-  <class name="execution" index="140">
-    <doc>
-      This class allows for efficiently communicating information about completion of processing.
-    </doc>
-
-    <chassis name="server" implement="MUST"/>
-    <chassis name="client" implement="MUST"/>
-
-    <!-- - Method: execution.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="flush" index="10" label="request an execution.complete return method">
-      <doc>
-        Requests notification of all currently complete commands. The server should issue an
-        execution.complete at the earliest possible opportunity.
-      </doc>
-
-      <chassis name="server" implement="MUST"/>
-      <chassis name="client" implement="MUST"/>
-    </method>
-
-    <!-- - Method: execution.complete  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="complete" index="20">
-      <doc>
-        Signals completion of all commands such that command-id &lt;= cumulative-execution-mark, or
-        command-id is in the set defined by ranged-execution-set. This can be sent spontaneously,
-        in response to a execution.flush, or as requested by use of the sync bit.
-
-        <!-- TODO: See chapter (TBD here) for how command ids are computed. -->
-      </doc>
-
-      <rule name="unique-encoding">
-        <doc>
-          In order to ensure a canonical wire representation, the value cumulative-execution-mark +
-          1 must not be covered by the ranged-execution-set.
-        </doc>
-      </rule>
-
-      <chassis name="server" implement="MUST"/>
-      <chassis name="client" implement="MUST"/>
-
-      <field name="cumulative-execution-mark" domain="rfc1982-long"
-        label="Low-water mark for command ids">
-        <doc>
-          The low-water mark for executed command-ids. All ids below this mark have been executed;
-          above this mark, there are gaps containing unexecuted command ids (i.e. discontinuous). By
-          definition, the first id above this mark (if it exists) is an unexecuted command-id.
-        </doc>
-      </field>
-
-      <field name="ranged-execution-set" domain="rfc1982-long-set"
-        label="Set of discontinuous command ids above cumulative-execution-mark">
-        <doc>
-          This set contains a sequence of discontinuous executed command-ids above the low-water
-          mark (i.e. above the first gap of unexecuted command ids).
-        </doc>
-      </field>
-    </method>
-
-    <!-- - Method: execution.noop  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="noop" index="30" label="a command that does nothing">
-      <doc>
-        This command may be used when it is desirable to send a command that has no effect. This
-        situation can occur after issuing a number of commands with sync=False. If, after issuing
-        the commands, a peer wishes to receive confirmation of completion, the peer can do so by
-        sending an execution.noop command with sync=True.
-      </doc>
-
-      <chassis name="server" implement="MUST"/>
-      <chassis name="client" implement="MUST"/>
-    </method>
-
-    <!-- - Method: execution.result  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="result" index="40" label="carries execution results">
-      <doc>
-        This method carries data resulting from the execution of a command.
-      </doc>
-
-      <chassis name="server" implement="MUST"/>
-      <chassis name="client" implement="MUST"/>
-
-      <field name="command-id" domain="command-id"/>
-      <field name="data" domain="long-struct"/>
-    </method>
-
-    <!-- - Method: execution.sync  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name="sync" index="50" label="request notification of completion for issued commands">
-      <doc>
-        Requests notification (via execution.complete) when all commands issued prior to the sync
-        control are complete. If the recipient of this control has already notified the
-        sender that said commands are complete, it may safely ignore the control.
-      </doc>
-
-      <chassis name="server" implement="MUST"/>
-      <chassis name="client" implement="MUST"/>
-    </method>
-
-  </class>
-
-
-  <!-- This is no longer an official part of 0-10 and is included here only as a transitional aid -->
-  <!-- ==  CHANNEL  ========================================================== -->
-
-  <class name = "channel" handler = "channel" index = "21" label = "work with channels">
-    <doc>
-      The channel class provides methods for a client to establish a channel to a
-      server and for both peers to operate the channel thereafter.
-    </doc>
-
-    <doc type = "grammar">
-      channel             = open-channel *use-channel close-channel
-      open-channel        = C:OPEN S:OPEN-OK
-                          / C:RESUME S:OK
-      use-channel         = C:FLOW S:FLOW-OK
-                          / S:FLOW C:FLOW-OK
-                          / S:PING C:OK
-                          / C:PONG S:OK
-                          / C:PING S:OK
-                          / S:PONG C:OK
-                          / 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" label = "open a channel for use">
-      <doc>
-        This method opens a channel to the server.
-      </doc>
-      <rule name = "state" on-failure = "channel-error">
-        <doc>
-          The client MUST NOT use this method on an already-opened channel.
-        </doc>
-        <doc type = "scenario">
-          Client opens a channel and then reopens the same channel.
-        </doc>
-      </rule>
-      <chassis name = "server" implement = "MUST" />
-      <response name = "open-ok" />
-      <field name = "out-of-band" domain = "shortstr" label = "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" label = "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" label = "enable/disable flow from peer">
-      <doc>
-        This method asks the peer to pause or restart the flow of content data. This is a
-        simple flow-control mechanism that a peer can use to avoid overflowing its queues or
-        otherwise finding itself receiving more messages than it can process. Note that this
-        method is not intended for window control. The peer that receives a disable flow
-        method should finish sending the current content frame, if any, then pause.
-      </doc>
-
-      <rule name = "initial-state">
-        <doc>
-          When a new channel is opened, it is active (flow is active). Some applications
-          assume that channels are inactive until started. To emulate this behaviour a
-          client MAY open the channel, then pause it.
-        </doc>
-      </rule>
-
-      <rule name = "bidirectional">
-        <doc>
-          When sending content frames, a peer SHOULD monitor the channel for incoming
-          methods and respond to a Channel.Flow as rapidly as possible.
-        </doc>
-      </rule>
-
-      <rule name = "throttling">
-        <doc>
-          A peer MAY use the Channel.Flow method to throttle incoming content data for
-          internal reasons, for example, when exchanging data over a slower connection.
-        </doc>
-      </rule>
-
-      <rule name = "expected-behaviour">
-        <doc>
-          The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer
-          that does not respect the request.  This is to prevent badly-behaved clients
-          from overwhelming a broker.
-        </doc>
-      </rule>
-
-      <chassis name = "server" implement = "MUST" />
-      <chassis name = "client" implement = "MUST" />
-
-      <response name = "flow-ok" />
-
-      <field name = "active" domain = "bit" label = "start/stop content frames">
-        <doc>
-          If 1, the peer starts sending content frames. If 0, the peer stops sending
-          content frames.
-        </doc>
-      </field>
-    </method>
-
-    <method name = "flow-ok" index = "21" label = "confirm a flow method">
-      <doc>
-        Confirms to the peer that a flow command was received and processed.
-      </doc>
-      <chassis name = "server" implement = "MUST" />
-      <chassis name = "client" implement = "MUST" />
-      <field name = "active" domain = "bit" label = "current flow setting">
-        <doc>
-          Confirms the setting of the processed flow method: 1 means the peer will start
-          sending or continue to send content frames; 0 means it will not.
-        </doc>
-      </field>
-    </method>
-
-    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
-
-    <method name = "close" synchronous = "1" index = "40" label = "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>
-
-      <!-- TODO: the channel close behaviour needs to be reviewed from the ODF
-           documentation and better expressed as rules here. /PH 2006/07/20
-           -->
-      <rule name = "stability">
-        <doc>
-          After sending this method any received method except the Close-OK method MUST
-          be discarded.
-        </doc>
-      </rule>
-
-      <chassis name = "client" implement = "MUST" />
-      <chassis name = "server" implement = "MUST" />
-      <response name = "close-ok" />
-
-      <field name = "reply-code" domain = "reply-code" />
-      <field name = "reply-text" domain = "reply-text" />
-
-      <field name = "class-id" domain = "class-id" label = "failing method class">
-        <doc>
-          When the close is provoked by a method exception, this is the class of the
-          method.
-        </doc>
-      </field>
-
-      <field name = "method-id" domain = "method-id" label = "failing method ID">
-        <doc>
-          When the close is provoked by a method exception, this is the ID of the method.
-        </doc>
-      </field>
-    </method>
-
-    <method name = "close-ok" synchronous = "1" index = "41" label = "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.
-      </doc>
-      <rule name = "reporting">
-        <doc>
-          A peer that detects a socket closure without having received a Channel.Close-Ok
-          handshake method SHOULD log the error.
-        </doc>
-      </rule>
-      <chassis name = "client" implement = "MUST" />
-      <chassis name = "server" implement = "MUST" />
-    </method>
-  </class> 
-
-</amqp>
diff --git a/qpid/specs/amqp.0-10-preview.xml b/qpid/specs/amqp.0-10-preview.xml
index 7d81b29302..a743025f65 100644
--- a/qpid/specs/amqp.0-10-preview.xml
+++ b/qpid/specs/amqp.0-10-preview.xml
@@ -2068,7 +2068,9 @@
       <chassis name="client" implement="MUST" />
       <chassis name="server" implement="MUST" />
 
+      <!--
       <response name="closed" />
+      -->
     </method>
 
     <!-- - Method: session.closed  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
@@ -6926,7 +6928,7 @@
 
     <!-- - Method: message.empty - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 
-    <method name="empty" index="510" label="empty queue">
+    <method name="empty" index="200" label="empty queue">
       <doc>
         Signals that a queue does not contain any messages; usually sent in response to the get
         method.
@@ -6938,7 +6940,7 @@
 
     <!-- - Method: message.offset  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
 
-    <method name="offset" index="530" label="return an offset">
+    <method name="offset" index="210" label="return an offset">
       <doc>
         Returns the data offset into a reference body; usually sent in response to resume method.
       </doc>