qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject svn commit: r562325 [2/3] - in /incubator/qpid/trunk/qpid: java/client/src/main/java/org/apache/qpid/nclient/api/ java/client/src/main/java/org/apache/qpid/nclient/impl/ java/common/ java/common/src/main/java/org/apache/qpidity/ specs/
Date Fri, 03 Aug 2007 04:25:26 GMT
Added: incubator/qpid/trunk/qpid/specs/amqp.0-10-preview.xml
URL: http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid/specs/amqp.0-10-preview.xml?view=auto&rev=562325
==============================================================================
--- incubator/qpid/trunk/qpid/specs/amqp.0-10-preview.xml (added)
+++ incubator/qpid/trunk/qpid/specs/amqp.0-10-preview.xml Thu Aug  2 21:25:25 2007
@@ -0,0 +1,7062 @@
+<?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="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="method-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>
+
+  <!-- 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: connextion.start  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="start" synchronous="1" index="10" label="start connection negotiation">
+      <doc>
+        This method starts the connection negotiation process by telling the client the protocol
+        version that the server proposes, along with a list of security mechanisms which the client
+        can use for authentication.
+      </doc>
+
+      <rule name="protocol-name">
+        <doc>
+          If the server cannot support the protocol specified in the protocol header, it MUST close
+          the socket connection without sending any response method.
+        </doc>
+        <doc type="scenario">
+          The client sends a protocol header containing an invalid protocol name. The server must
+          respond by closing the connection.
+        </doc>
+      </rule>
+
+      <rule name="server-support">
+        <doc>
+          The server MUST provide a protocol version that is lower than or equal to that requested
+          by the client in the protocol header.
+        </doc>
+        <doc type="scenario">
+          The client requests a protocol version that is higher than any valid implementation, e.g.
+          9.0. The server must respond with a current protocol version, e.g. 1.0.
+        </doc>
+      </rule>
+
+      <rule name="client-support">
+        <doc>
+          If the client cannot handle the protocol version suggested by the server it MUST close the
+          socket connection.
+        </doc>
+        <doc type="scenario">
+          The server sends a protocol version that is lower than any valid implementation, e.g. 0.1.
+          The client must respond by closing the connection.
+        </doc>
+      </rule>
+
+      <chassis name="client" implement="MUST" />
+
+      <response name="start-ok" />
+
+      <field name="version-major" domain="octet" label="protocol major version">
+        <doc>
+          The protocol version, major component, as transmitted in the AMQP protocol header. This,
+          combined with the protocol minor component fully describe the protocol version, which is
+          written in the format major-minor. Hence, with major=1, minor=3, the protocol version
+          would be "1-3".
+        </doc>
+      </field>
+
+      <field name="version-minor" domain="octet" label="protocol minor version">
+        <doc>
+          The protocol version, minor component, as transmitted in the AMQP protocol header. This,
+          combined with the protocol major component fully describe the protocol version, which is
+          written in the format major-minor. Hence, with major=1, minor=3, the protocol version
+          would be "1-3".
+        </doc>
+      </field>
+
+      <field name="server-properties" domain="peer-properties" label="server properties">
+        <rule name="required-fields">
+          <doc>
+            The properties SHOULD contain at least these fields: "host", specifying the server host
+            name or address, "product", giving the name of the server product, "version", giving the
+            name of the server version, "platform", giving the name of the operating system,
+            "copyright", if appropriate, and "information", giving other general information.
+          </doc>
+          <doc type="scenario">
+            Client connects to server and inspects the server properties. It checks for the presence
+            of the required fields.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="mechanisms" domain="longstr" label="available security mechanisms">
+        <doc>
+          A list of the security mechanisms that the server supports, delimited by spaces.
+        </doc>
+        <assert check="notnull" />
+      </field>
+
+      <field name="locales" domain="longstr" label="available message locales">
+        <doc>
+          A list of the message locales that the server supports, delimited by spaces. The locale
+          defines the language in which the server will send reply texts.
+        </doc>
+
+        <rule name="required-support">
+          <doc>
+            The server MUST support at least the en_US locale.
+          </doc>
+          <doc type="scenario">
+            Client connects to server and inspects the locales field. It checks for the presence of
+            the required locale(s).
+          </doc>
+        </rule>
+
+        <assert check="notnull" />
+      </field>
+    </method>
+
+    <!-- - Method: connextion.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="start-ok" synchronous="1" index="11"
+      label="select security mechanism and locale">
+      <doc>
+        This method selects a SASL security mechanism.
+      </doc>
+
+      <chassis name="server" implement="MUST" />
+
+      <field name="client-properties" domain="peer-properties" label="client properties">
+        <rule name="required-fields">
+          <!-- This rule is not testable from the client side -->
+          <doc>
+            The properties SHOULD contain at least these fields: "product", giving the name of the
+            client product, "version", giving the name of the client version, "platform", giving the
+            name of the operating system, "copyright", if appropriate, and "information", giving
+            other general information.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="mechanism" domain="shortstr" label="selected security mechanism">
+        <doc>
+          A single security mechanisms selected by the client, which must be one of those specified
+          by the server.
+        </doc>
+
+        <rule name="security">
+          <doc>
+            The client SHOULD authenticate using the highest-level security profile it can handle
+            from the list provided by the server.
+          </doc>
+        </rule>
+
+        <rule name="validity">
+          <doc>
+            If the mechanism field does not contain one of the security mechanisms proposed by the
+            server in the Start method, the server MUST close the connection without sending any
+            further data.
+          </doc>
+          <doc type="scenario">
+            Client connects to server and sends an invalid security mechanism. The server must
+            respond by closing the connection (a socket close, with no connection close
+            negotiation).
+          </doc>
+        </rule>
+
+        <assert check="notnull" />
+      </field>
+
+      <field name="response" domain="longstr" label="security response data">
+        <doc>
+          A block of opaque data passed to the security mechanism. The contents of this data are
+          defined by the SASL security mechanism.
+        </doc>
+        <assert check="notnull" />
+      </field>
+
+      <field name="locale" domain="shortstr" label="selected message locale">
+        <doc>
+          A single message locale selected by the client, which must be one of those specified by
+          the server.
+        </doc>
+        <assert check="notnull" />
+      </field>
+    </method>
+
+    <!-- - Method: connextion.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="secure" synchronous="1" index="20" label="security mechanism challenge">
+      <doc>
+        The SASL protocol works by exchanging challenges and responses until both peers have
+        received sufficient information to authenticate each other. This method challenges the
+        client to provide more information.
+      </doc>
+
+      <chassis name="client" implement="MUST" />
+
+      <response name="secure-ok" />
+
+      <field name="challenge" domain="longstr" label="security challenge data">
+        <doc>
+          Challenge information, a block of opaque binary data passed to the security mechanism.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: connextion.secure-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="secure-ok" synchronous="1" index="21" label="security mechanism response">
+      <doc>
+        This method attempts to authenticate, passing a block of SASL data for the security
+        mechanism at the server side.
+      </doc>
+
+      <chassis name="server" implement="MUST" />
+
+      <field name="response" domain="longstr" label="security response data">
+        <doc>
+          A block of opaque data passed to the security mechanism. The contents of this data are
+          defined by the SASL security mechanism.
+        </doc>
+        <assert check="notnull" />
+      </field>
+    </method>
+
+    <!-- - Method: connextion.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="tune" synchronous="1" index="30" label="propose connection tuning parameters">
+      <doc>
+        This method proposes a set of connection configuration values to the client. The client can
+        accept and/or adjust these.
+      </doc>
+
+      <chassis name="client" implement="MUST" />
+
+      <response name="tune-ok" />
+
+      <field name="channel-max" domain="short" label="proposed maximum channels">
+        <doc>
+          The maximum total number of channels that the server allows per connection. Zero means
+          that the server does not impose a fixed limit, but the number of allowed channels may be
+          limited by available server resources.
+        </doc>
+      </field>
+
+      <field name="frame-max" domain="long" label="proposed maximum frame size">
+        <doc>
+          The largest frame size that the server proposes for the connection. The client can
+          negotiate a lower value. Zero means that the server does not impose any specific limit but
+          may reject very large frames if it cannot allocate resources for them.
+        </doc>
+
+        <rule name="minimum">
+          <doc>
+            Until the frame-max has been negotiated, both peers MUST accept frames of up to
+            frame-min-size octets large, and the minimum negotiated value for frame-max is also
+            frame-min-size.
+          </doc>
+          <doc type="scenario">
+            Client connects to server and sends a large properties field, creating a frame of
+            frame-min-size octets. The server must accept this frame.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="heartbeat" domain="short" label="desired heartbeat delay">
+        <!-- TODO 0.82 - the heartbeat negotiation mechanism was changed during implementation
+          because the model documented here does not actually work properly.  The best model we
+          found is that the server proposes a heartbeat value to the client; the client can reply
+          with zero, meaning 'do not use heartbeats (as documented here), or can propose its own
+          heartbeat value, which the server should then accept.  This is different from the model
+          here which is disconnected - e.g. each side requests a heartbeat independently.  Basically
+          a connection is heartbeated in both ways, or not at all, depending on whether both peers
+          support heartbeating or not, and the heartbeat value should itself be chosen by the client
+          so that remote links can get a higher value.  Also, the actual heartbeat mechanism needs
+          documentation, and is as follows: so long as there is activity on a connection - in or out
+          - both peers assume the connection is active.  When there is no activity, each peer must
+          send heartbeat frames.  When no heartbeat frame is received after N cycles (where N is at
+          least 2), the connection can be considered to have died. /PH 2006/07/19
+        -->
+        <doc>
+          The delay, in seconds, of the connection heartbeat that the server wants. Zero means the
+          server does not want a heartbeat.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: connextion.tune-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="tune-ok" synchronous="1" index="31"
+      label="negotiate connection tuning parameters">
+      <doc>
+        This method sends the client's connection tuning parameters to the server. Certain fields
+        are negotiated, others provide capability information.
+      </doc>
+
+      <chassis name="server" implement="MUST" />
+
+      <field name="channel-max" domain="short" label="negotiated maximum channels">
+        <doc>
+          The maximum total number of channels that the client will use per connection.
+        </doc>
+
+        <rule name="upper-limit">
+          <doc>
+            If the client specifies a channel max that is higher than the value provided by the
+            server, the server MUST close the connection without attempting a negotiated close. The
+            server may report the error in some fashion to assist implementors.
+          </doc>
+        </rule>
+
+        <assert check="notnull" />
+        <assert check="le" value="channel-max" />
+      </field>
+
+      <field name="frame-max" domain="long" label="negotiated maximum frame size">
+        <doc>
+          The largest frame size that the client and server will use for the connection. Zero means
+          that the client does not impose any specific limit but may reject very large frames if it
+          cannot allocate resources for them. Note that the frame-max limit applies principally to
+          content frames, where large contents can be broken into frames of arbitrary size.
+        </doc>
+
+        <rule name="minimum">
+          <doc>
+            Until the frame-max has been negotiated, both peers MUST accept frames of up to
+            frame-min-size octets large, and the minimum negotiated value for frame-max is also
+            frame-min-size.
+          </doc>
+        </rule>
+
+        <rule name="upper-limit">
+          <doc>
+            If the client specifies a frame max that is higher than the value provided by the
+            server, the server MUST close the connection without attempting a negotiated close. The
+            server may report the error in some fashion to assist implementors.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="heartbeat" domain="short" label="desired heartbeat delay">
+        <doc>
+          The delay, in seconds, of the connection heartbeat that the client wants. Zero means the
+          client does not want a heartbeat.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: connextion.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="open" synchronous="1" index="40" label="open connection to virtual host">
+      <doc>
+        This method opens a connection to a virtual host, which is a collection of resources, and
+        acts to separate multiple application domains within a server. The server may apply
+        arbitrary limits per virtual host, such as the number of each type of entity that may be
+        used, per connection and/or in total.
+      </doc>
+
+      <chassis name="server" implement="MUST" />
+
+      <response name="open-ok" />
+      <response name="redirect" />
+
+      <field name="virtual-host" domain="path" label="virtual host name">
+        <!-- TODO 0.82 - the entire vhost model needs review. This concept was prompted by the HTTP
+          vhost concept but does not fit very well into AMQP.  Currently we use the vhost as a 
+          "cluster identifier" which is inaccurate usage. /PH 2006/07/19
+        -->
+        <doc>
+          The name of the virtual host to work with.
+        </doc>
+
+        <rule name="separation">
+          <doc>
+            If the server supports multiple virtual hosts, it MUST enforce a full separation of
+            exchanges, queues, and all associated entities per virtual host. An application,
+            connected to a specific virtual host, MUST NOT be able to access resources of another
+            virtual host.
+          </doc>
+        </rule>
+
+        <rule name="security">
+          <doc>
+            The server SHOULD verify that the client has permission to access the specified virtual
+            host.
+          </doc>
+        </rule>
+        <assert check="regexp" value="^[a-zA-Z0-9/-_]+$" />
+      </field>
+
+      <field name="capabilities" domain="shortstr" label="required capabilities">
+        <doc>
+          The client can specify zero or more capability names, delimited by spaces. The server can
+          use this string to how to process the client's connection request.
+        </doc>
+      </field>
+
+      <field name="insist" domain="bit" label="insist on connecting to server">
+        <doc>
+          In a configuration with multiple collaborating servers, the server may respond to a
+          Connection.Open method with a Connection.Redirect. The insist option tells the server that
+          the client is insisting on a connection to the specified server.
+        </doc>
+        <rule name="behaviour">
+          <doc>
+            When the client uses the insist option, the server MUST NOT respond with a
+            Connection.Redirect method. If it cannot accept the client's connection request it
+            should respond by closing the connection with a suitable reply code.
+          </doc>
+        </rule>
+      </field>
+    </method>
+
+    <!-- - Method: connextion.open-ok  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="open-ok" synchronous="1" index="41" label="signal that connection is ready">
+      <doc>
+        This method signals to the client that the connection is ready for use.
+      </doc>
+
+      <chassis name="client" implement="MUST" />
+
+      <field name="known-hosts" domain="known-hosts" />
+    </method>
+
+    <!-- - Method: connextion.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="redirect" synchronous="1" index="42" label="redirects client to other server">
+      <doc>
+        This method redirects the client to another server, based on the requested virtual host
+        and/or capabilities.
+      </doc>
+
+      <rule name="usage">
+        <doc>
+          When getting the Connection.Redirect method, the client SHOULD reconnect to the host
+          specified, and if that host is not present, to any of the hosts specified in the
+          known-hosts list.
+        </doc>
+      </rule>
+
+      <chassis name="client" implement="MUST" />
+
+      <field name="host" domain="shortstr" label="server to connect to">
+        <doc>
+          Specifies the server to connect to. This is an IP address or a DNS name, optionally
+          followed by a colon and a port number. If no port number is specified, the client should
+          use the default port number for the protocol.
+        </doc>
+        <assert check="notnull" />
+      </field>
+
+      <field name="known-hosts" domain="known-hosts" />
+    </method>
+
+    <!-- - Method: connextion.close  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="close" synchronous="1" index="50" label="request a connection close">
+      <doc>
+        This method indicates that the sender wants to close the connection. This may be due to
+        internal conditions (e.g. a forced shut-down) or due to an error handling a specific method,
+        i.e. an exception. When a close is due to an exception, the sender provides the class and
+        method id of the method which caused the exception.
+      </doc>
+      <!-- TODO: The connection close mechanism needs to be reviewed from the ODF documentation and
+        better expressed as rules here. /PH 2006/07/20
+      -->
+
+      <rule name="stability">
+        <doc>
+          After sending this method any received method except the Close-OK method MUST be
+          discarded.
+        </doc>
+      </rule>
+
+      <chassis name="client" implement="MUST" />
+      <chassis name="server" implement="MUST" />
+
+      <response name="close-ok" />
+
+      <field name="reply-code" domain="reply-code" />
+      <field name="reply-text" domain="reply-text" />
+
+      <field name="class-id" domain="class-id" label="failing method class">
+        <doc>
+          When the close is provoked by a method exception, this is the class of the method.
+        </doc>
+      </field>
+
+      <field name="method-id" domain="method-id" label="failing method ID">
+        <doc>
+          When the close is provoked by a method exception, this is the ID of the method.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: connextion.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="close-ok" synchronous="1" index="51" label="confirm a connection close">
+      <doc>
+        This method confirms a Connection.Close method and tells the recipient that it is safe to
+        release resources for the connection and close the socket.
+      </doc>
+
+      <rule name="reporting">
+        <doc>
+          A peer that detects a socket closure without having received a Close-Ok handshake method
+          SHOULD log the error.
+        </doc>
+      </rule>
+
+      <chassis name="client" implement="MUST" />
+      <chassis name="server" implement="MUST" />
+    </method>
+
+  </class>
+
+  <!-- == Class: session ======================================================================= -->
+
+  <class name="session" index="20" label="session control methods">
+    <doc>
+      The session class provides methods for a client to establish a session with a server and for
+      both peers to operate the session thereafter.
+    </doc>
+
+    <doc type="grammar">
+      session       = open-session
+                      *use-session
+                      close-session
+      open-session  = C:OPEN S:ATTACHED
+                    / C:RESUME S:ATTACHED
+      use-session   = C:FLOW S:FLOW-OK
+                    / S:FLOW C:FLOW-OK
+                    / S:PING
+                    / C:PONG
+                    / C:PING
+                    / S:PONG
+      close-session = C:SUSPEND S:DETACHED
+                    / C:CLOSE S:CLOSED
+                    / S:CLOSED
+                    / S:CLOSE C:CLOSED
+                    / C:CLOSED
+    </doc>
+
+    <chassis name="server" implement="MUST" />
+    <chassis name="client" implement="MUST" />
+
+    <!-- - Method: session.open  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="open" synchronous="1" index="10" label="open a session for use">
+      <doc>
+        This method opens a session with the server.
+
+        When the responding peer creates the session, it MUST create a new, appropriately-unique
+        name for the session and return this to the creator with the rest of the session details.
+
+        Note that the timer controlling a session's automatic expiry, if any, counts down
+        immediately from the moment of its creation, unless simultaneously with that moment a
+        channel (or equivalent) is attached to the session. For this reason, it is recommended that
+        network protocol mappings create sessions simultaneously with the creation and attachment of
+        their channel-equivalents, since a zero lease time is perfectly valid and indicates that the
+        session should be destroyed as soon as it first finds itself inactive.
+
+        During the period that a channel (or equivalent) is attached to a session, the session has
+        no deletion timer. Every time a channel is detached from a session such that the session is
+        left without any attached network-level entities, the timer is created, set to its declared
+        value and started.
+
+        Note that if the peer decides that the requested detached-lifetime timeout is too long,
+        either because the replying peer does not support sessions with non-zero requested timeouts,
+        or because the requested timeout exceeds some peer-specific limitation, it may substitute an
+        acceptable value for the detached-lifetime parameter in its reply to the creation request.
+        An exception is not required.
+      </doc>
+
+      <rule name="expiration">
+        <doc>
+          Whether the detachment is explicit or implicit, as a result of application action or of
+          application error, the channel (or equivalent) is detached from its session and the
+          session timer MUST start counting down as defined in session.open.
+        </doc>
+      </rule>
+
+      <rule name="channel-busy">
+        <!-- TODO: Figure out how to make this error conditional to stateful network mappings with
+          channels.
+        -->
+        <doc>
+          The client MUST NOT send session.open on a channel that is already associated with a
+          session. A "channel busy" connection exception will occur if the channel down which the
+          open request was sent was already attached to a session.
+        </doc>
+        <doc type="scenario">
+          Client sends session.open twice down the same channel.
+        </doc>
+      </rule>
+
+      <!--
+      <throws name="out-of-resources"/>
+      -->
+
+      <chassis name="server" implement="MUST" />
+
+      <response name="attached" />
+
+      <field name="detached-lifetime" domain="detached-lifetime">
+        <doc>
+          The number of seconds the session's state is retained during periods when no channel (or
+          equivalent) is attached to the session.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: session.attached  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="attached" synchronous="1" index="11" label="signal that the session is ready">
+      <doc>
+        This method signals to the client that the session is ready for use.
+
+        Once a session.attached is received by the client, everything is in place for normal
+        transmission of frames. However, depending on the network protocol mapping in use, the
+        frame-id be undefined until certain control frames have been sent. Please see the specific
+        details for each protocol mapping.
+
+        If the attached session was freshly created, the session-id here will be a freshly-generated
+        UUID.
+
+        Note that the actual session detached-lifetime value, as decided by the peer, is returned
+        using this method. The value returned may not be the same as that requested in the
+        corresponding session creation request. In particular, a request for an unbounded
+        detached-lifetime of may be fulfilled by creation of a session with a bounded actual
+        lifetime parameter. The requesting peer SHOULD take the lifetime value returned as
+        authoritative for its own session-related record-keeping.
+      </doc>
+
+      <chassis name="client" implement="MUST" />
+
+      <field name="session-id" domain="session-id">
+        <doc>
+          The session identifier (a UUID) used to identify this session.
+        </doc>
+      </field>
+
+      <field name="detached-lifetime" domain="detached-lifetime">
+        <doc>
+          The number of seconds the session's state is retained during periods when no channel (or
+          equivalent) is attached to the session.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: session.flow  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="flow" synchronous="1" index="20" label="enable/disable flow from peer">
+      <doc>
+        This method asks the peer to pause or restart the flow of content data. This is a simple
+        flow-control mechanism that a peer can use to avoid overflowing its queues or otherwise
+        finding itself receiving more messages than it can process. Note that this method is not
+        intended for window control. The peer that receives a disable flow method should finish
+        sending the current content frame, if any, then pause.
+      </doc>
+
+      <rule name="initial-state">
+        <doc>
+          When a new session is opened, it is active (flow is active). Some applications assume that
+          sessions are inactive until started. To emulate this behaviour a client MAY open the
+          session, then pause it.
+        </doc>
+      </rule>
+
+      <rule name="bidirectional">
+        <doc>
+          When sending content frames, a peer SHOULD monitor the session for incoming methods and
+          respond to a Session.Flow as rapidly as possible.
+        </doc>
+      </rule>
+
+      <rule name="throttling">
+        <doc>
+          A peer MAY use the Session.Flow method to throttle incoming content data for internal
+          reasons, for example, when exchanging data over a slower connection.
+        </doc>
+      </rule>
+
+      <rule name="expected-behaviour">
+        <doc>
+          The peer that requests a Session.Flow method MAY disconnect and/or ban a peer that does
+          not respect the request. This is to prevent badly-behaved clients from overwhelming a
+          broker.
+        </doc>
+      </rule>
+
+      <chassis name="server" implement="MUST" />
+      <chassis name="client" implement="MUST" />
+
+      <response name="flow-ok" />
+
+      <field name="active" domain="bit" label="start/stop content frames">
+        <doc>
+          If true (1), the peer starts sending content frames. If false (0), the peer stops sending
+          content frames.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: session.flow-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="flow-ok" index="21" label="confirm a flow method">
+      <doc>
+        Confirms to the peer that a flow command was received and processed.
+      </doc>
+
+      <chassis name="server" implement="MUST" />
+      <chassis name="client" implement="MUST" />
+
+      <field name="active" domain="bit" label="current flow setting">
+        <doc>
+          Confirms the setting of the processed flow method: true (1) means the peer will start
+          sending or continue to send content frames; false (0) means it will not.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: session.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="close" index="40" label="request a session close">
+      <doc>
+        Requests that the receiving peer destroy a session, implicitly detaching any attached
+        channels or channel-equivalents.
+
+        Note that the reply, session.closed, is also used for asynchronous exception notifications.
+        For normal closure, such as in response to a session.close request, reason code 200 ("ok")
+        is to be used.
+      </doc>
+
+      <chassis name="client" implement="MUST" />
+      <chassis name="server" implement="MUST" />
+
+      <response name="closed" />
+    </method>
+
+    <!-- - Method: session.closed  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="closed" index="41" label="notify of a session close">
+      <doc>
+        Notifies the receiver that not only has the current channel been detached from its
+        underlying session, but that the session itself has been destroyed.
+
+        This method confirms a session.close method and tells the recipient that it is safe to
+        release resources for the channel.
+
+        Note also that for normal closure, reason code 200 ("ok") is to be used.
+      </doc>
+
+      <chassis name="client" implement="MUST" />
+      <chassis name="server" implement="MUST" />
+
+      <field name="reply-code" domain="reply-code">
+        <doc>
+          The numeric reply code.
+        </doc>
+      </field>
+
+      <field name="reply-text" domain="reply-text">
+        <doc>
+          The localised reply text.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: session.resume  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <method name="resume" index="50" label="resume an interrupted session">
+      <doc>
+        Attaches to an already-existing session.
+      </doc>
+
+      <rule name="session-busy">
+        <doc>
+          A "session busy" exception is returned if the session exists, but is not in a condition
+          where it can accept the requested attachment. Peers receiving this exception may wish to
+          retain their session state and retry the session.resume operation after a delay.
+        </doc>
+      </rule>
+
+      <chassis name="server" implement="MAY" />
+
+      <response name="attached" />
+
+      <field name="session-id" domain="session-id">
+        <doc>
+          The session identifier (a UUID) used to identify this session.
+        </doc>
+      </field>
+    </method>
+
+    <!-- - Method: session.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>

[... 4796 lines stripped ...]


Mime
View raw message