qpid-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject svn commit: r687540 [2/3] - in /incubator/qpid/branches/qpid.rnr: java/common/ java/common/src/main/java/org/apache/qpid/transport/ java/common/src/main/java/org/apache/qpid/transport/network/ specs/
Date Thu, 21 Aug 2008 02:59:54 GMT
Added: incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml?rev=687540&view=auto
==============================================================================
--- incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml (added)
+++ incubator/qpid/branches/qpid.rnr/specs/amqp.1-0-draft.xml Wed Aug 20 19:59:53 2008
@@ -0,0 +1,5102 @@
+<?xml version="1.0"?>
+
+<!--
+  Copyright Notice
+  ================
+  (c) Copyright Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,
+  Goldman Sachs, IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A,
+  Novell, Rabbit Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, and 29West Inc.
+  2006, 2007. All rights reserved.
+
+  License
+  =======
+
+  Cisco Systems, Credit Suisse, Deutsche Borse Systems, Envoy Technologies, Inc.,Goldman Sachs,
+  IONA Technologies PLC, iMatix Corporation sprl.,JPMorgan Chase Bank Inc. N.A, Novell, Rabbit
+  Technologies Ltd., Red Hat, Inc., TWIST Process Innovations ltd, 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.1-0-draft.dtd">
+
+<amqp xmlns="http://www.amqp.org/schema/amqp.xsd"
+    major="99" minor="0" port="5672" comment="working version">
+
+  <!--
+    ====================== == type definitions == ======================
+  -->
+
+  <!--
+    0x00 - 0x0f: Fixed width, 1 octet
+  -->
+
+  <type name="bin8" code="0x00" fixed-width="1" label="octet of unspecified encoding">
+    <doc>
+      The bin8 type consists of exactly one octet of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET
+      +----------+
+      |   bin8   |
+      +----------+
+    </doc>
+
+    <doc type="bnf">
+               bin8 = OCTET
+    </doc>
+  </type>
+
+  <type name="int8" code="0x01" fixed-width="1" label="8-bit signed integral value (-128 - 127)">
+    <doc>
+      The int8 type is a signed integral value encoded using an 8-bit two's complement
+      representation.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET
+      +----------+
+      |   int8   |
+      +----------+
+    </doc>
+
+    <doc type="bnf">
+               int8 = OCTET
+    </doc>
+  </type>
+
+  <type name="uint8" code="0x02" fixed-width="1" label="8-bit unsigned integral value (0 - 255)">
+    <doc>
+      The uint8 type is an 8-bit unsigned integral value.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET
+      +---------+
+      |  uint8  |
+      +---------+
+    </doc>
+
+    <doc type="bnf">
+              uint8 = OCTET
+    </doc>
+  </type>
+
+  <type name="char" code="0x04" fixed-width="1" label="an iso-8859-15 character">
+    <doc>
+      The char type encodes a single character from the iso-8859-15 character set.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET
+      +----------+
+      |   char   |
+      +----------+
+    </doc>
+
+    <doc type="bnf">
+               char = OCTET
+    </doc>
+  </type>
+
+  <type name="boolean" code="0x08" fixed-width="1"
+        label="boolean value (zero represents false, nonzero represents true)">
+    <doc>
+      The boolean type is a single octet that encodes a true or false value. If the octet is zero,
+      then the boolean is false. Any other value represents true.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET
+      +---------+
+      | boolean |
+      +---------+
+    </doc>
+
+    <doc type="bnf">
+            boolean = OCTET
+    </doc>
+  </type>
+
+  <!--
+    0x10 - 0x1f: Fixed width, 2 octets
+  -->
+
+  <type name="bin16" code="0x10" fixed-width="2" label="two octets of unspecified binary encoding">
+    <doc>
+      The bin16 type consists of two consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET
+      +-----------+-----------+
+      | octet-one | octet-two |
+      +-----------+-----------+
+    </doc>
+
+    <doc type="bnf">
+              bin16 = 2 OCTET
+    </doc>
+  </type>
+
+  <type name="int16" code="0x11" fixed-width="2" label="16-bit signed integral value">
+    <doc>
+      The int16 type is a signed integral value encoded using a 16-bit two's complement
+      representation in network byte order.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET    1 OCTET
+      +-----------+----------+
+      | high-byte | low-byte |
+      +-----------+----------+
+    </doc>
+
+    <doc type="bnf">
+              int16 = high-byte low-byte
+          high-byte = OCTET
+           low-byte = OCTET
+    </doc>
+  </type>
+
+  <type name="uint16" code="0x12" fixed-width="2" label="16-bit unsigned integer">
+    <doc>
+      The uint16 type is a 16-bit unsigned integral value encoded in network byte order.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET    1 OCTET
+      +-----------+----------+
+      | high-byte | low-byte |
+      +-----------+----------+
+    </doc>
+
+    <doc type="bnf">
+             uint16 = high-byte low-byte
+          high-byte = OCTET
+           low-byte = OCTET
+    </doc>
+  </type>
+
+  <type name="channel" fixed-width="2" label="channel identifier">
+    <doc>
+      The channel type identifies both a direction and a 15 bit channel number packed into a 16 bit
+      value. The channel number may be computed by treating the channel identifier as a uint16 and
+      masking off the most significant bit. The most significant bit of the channel identifier
+      indicates the direction of the channel. If this bit is zero, the channel identifier refers to
+      a channel number where the initiator of the network connection (i.e. the network client) is
+      the AMQP client. If this bit is one, the channel identifier refers to a channel number where
+      the initiator of the network connection (i.e. the network client) is the AMQP server.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+          1 BIT        15 BITs
+      +-----------+----------------+
+      | direction | channel-number |
+      +-----------+----------------+
+        MSB                    LSB
+    </doc>
+
+    <doc type="bnf">
+            channel = direction channel-number
+          direction = 1 BIT
+     channel-number = 15 BIT
+    </doc>
+  </type>
+
+  <!--
+    0x20 - 0x2f: Fixed width, 4 octets
+  -->
+
+  <type name="bin32" code="0x20" fixed-width="4" label="four octets of unspecified binary encoding">
+    <doc>
+      The bin32 type consists of 4 consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET      1 OCTET      1 OCTET
+      +-----------+-----------+-------------+------------+
+      | octet-one | octet-two | octet-three | octet-four |
+      +-----------+-----------+-------------+------------+
+    </doc>
+
+    <doc type="bnf">
+              bin32 = 4 OCTET
+    </doc>
+  </type>
+
+  <type name="int32" code="0x21" fixed-width="4" label="32-bit signed integral value">
+    <doc>
+      The int32 type is a signed integral value encoded using a 32-bit two's complement
+      representation in network byte order.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET     1 OCTET    1 OCTET
+      +-----------+------------+----------+----------+
+      | byte-four | byte-three | byte-two | byte-one |
+      +-----------+------------+----------+----------+
+          MSB                                 LSB
+    </doc>
+
+    <doc type="bnf">
+              int32 = byte-four byte-three byte-two byte-one
+          byte-four = OCTET ; most significant byte (MSB)
+         byte-three = OCTET
+           byte-two = OCTET
+           byte-one = OCTET ; least significant byte (LSB)
+    </doc>
+  </type>
+
+  <type name="uint32" code="0x22" fixed-width="4" label="32-bit unsigned integral value">
+    <doc>
+      The uint32 type is a 32-bit unsigned integral value encoded in network byte order.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET     1 OCTET    1 OCTET
+      +-----------+------------+----------+----------+
+      | byte-four | byte-three | byte-two | byte-one |
+      +-----------+------------+----------+----------+
+          MSB                                 LSB
+    </doc>
+
+    <doc type="bnf">
+             uint32 = byte-four byte-three byte-two byte-one
+          byte-four = OCTET ; most significant byte (MSB)
+         byte-three = OCTET
+           byte-two = OCTET
+           byte-one = OCTET ; least significant byte (LSB)
+    </doc>
+  </type>
+
+  <type name="float" code="0x23" fixed-width="4"
+        label="single precision IEEE 754 32-bit floating point">
+    <doc>
+      The float type encodes a single precision 32-bit floating point number. The format and
+      operations are defined by the IEEE 754 standard for 32-bit floating point numbers.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+              4 OCTETs
+      +-----------------------+
+      |         float         |
+      +-----------------------+
+        IEEE 754 32-bit float
+    </doc>
+
+    <doc type="bnf">
+              float = 4 OCTET ; IEEE 754 32-bit floating point number
+    </doc>
+  </type>
+
+  <type name="char-utf32" code="0x27" fixed-width="4"
+        label="single unicode character in UTF-32 encoding">
+    <doc>
+      The char-utf32 type consists of a single unicode character in the UTF-32 encoding.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+            4 OCTETs
+      +------------------+
+      |    char-utf32    |
+      +------------------+
+        UTF-32 character
+    </doc>
+
+    <doc type="bnf">
+         char-utf32 = 4 OCTET ; single UTF-32 character
+    </doc>
+  </type>
+
+  <type name="sequence-no" fixed-width="4" label="serial number defined in RFC-1982">
+    <doc>
+      The sequence-no type encodes, in network byte order, a serial number as defined in RFC-1982.
+      The arithmetic, operators, and ranges for numbers of this type are defined by RFC-1982.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+               4 OCTETs
+      +------------------------+
+      |      sequence-no       |
+      +------------------------+
+        RFC-1982 serial number
+    </doc>
+
+    <doc type="bnf">
+        sequence-no = 4 OCTET ; RFC-1982 serial number
+    </doc>
+  </type>
+
+  <!--
+    0x30 - 0x3f: Fixed width types - 8 octets
+  -->
+
+  <type name="bin64" code="0x30" fixed-width="8"
+        label="eight octets of unspecified binary encoding">
+    <doc>
+      The bin64 type consists of eight consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET            1 OCTET       1 OCTET
+      +-----------+-----------+-----+-------------+-------------+
+      | octet-one | octet-two | ... | octet-seven | octet-eight |
+      +-----------+-----------+-----+-------------+-------------+
+    </doc>
+
+    <doc type="bnf">
+              bin64 = 8 OCTET
+    </doc>
+  </type>
+
+  <type name="int64" code="0x31" fixed-width="8" label="64-bit signed integral value">
+    <doc>
+      The int64 type is a signed integral value encoded using a 64-bit two's complement
+      representation in network byte order.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET      1 OCTET           1 OCTET    1 OCTET
+      +------------+------------+-----+----------+----------+
+      | byte-eight | byte-seven | ... | byte-two | byte-one |
+      +------------+------------+-----+----------+----------+
+          MSB                                        LSB
+    </doc>
+
+    <doc type="bnf">
+              int64 = byte-eight byte-seven byte-six byte-five
+                      byte-four byte-three byte-two byte-one
+         byte-eight = 1 OCTET ; most significant byte (MSB)
+         byte-seven = 1 OCTET
+           byte-six = 1 OCTET
+          byte-five = 1 OCTET
+          byte-four = 1 OCTET
+         byte-three = 1 OCTET
+           byte-two = 1 OCTET
+           byte-one = 1 OCTET ; least significant byte (LSB)
+    </doc>
+  </type>
+
+  <type name="uint64" code="0x32" fixed-width="8" label="64-bit unsigned integral value">
+    <doc>
+      The uint64 type is a 64-bit unsigned integral value encoded in network byte order.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET      1 OCTET           1 OCTET    1 OCTET
+      +------------+------------+-----+----------+----------+
+      | byte-eight | byte-seven | ... | byte-two | byte-one |
+      +------------+------------+-----+----------+----------+
+          MSB                                        LSB
+    </doc>
+
+    <doc type="bnf">
+             uint64 = byte-eight byte-seven byte-six byte-five
+                      byte-four byte-three byte-two byte-one
+         byte-eight = 1 OCTET ; most significant byte (MSB)
+         byte-seven = 1 OCTET
+           byte-six = 1 OCTET
+          byte-five = 1 OCTET
+          byte-four = 1 OCTET
+         byte-three = 1 OCTET
+           byte-two = 1 OCTET
+           byte-one = 1 OCTET ; least significant byte (LSB)
+    </doc>
+  </type>
+
+  <type name="double" code="0x33" fixed-width="8" label="double precision IEEE 754 floating point">
+    <doc>
+      The double type encodes a double precision 64-bit floating point number. The format and
+      operations are defined by the IEEE 754 standard for 64-bit double precision floating point
+      numbers.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+              8 OCTETs
+      +-----------------------+
+      |        double         |
+      +-----------------------+
+        IEEE 754 64-bit float
+    </doc>
+
+    <doc type="bnf">
+             double = 8 OCTET ; double precision IEEE 754 floating point number
+    </doc>
+  </type>
+
+  <type name="datetime" code="0x38" fixed-width="8" label="datetime in 64 bit POSIX time_t format">
+    <doc>
+      The datetime type encodes a date and time using the 64 bit POSIX time_t format.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+             8 OCTETs
+      +---------------------+
+      |      datetime       |
+      +---------------------+
+        posix time_t format
+    </doc>
+
+    <doc type="bnf">
+           datetime = 8 OCTET ; 64 bit posix time_t format
+    </doc>
+  </type>
+
+  <!--
+    0x40 - 0x4f: Fixed width types - 16 octets
+  -->
+
+  <type name="bin128" code="0x40" fixed-width="16"
+        label="sixteen octets of unspecified binary encoding">
+    <doc>
+      The bin128 type consists of 16 consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET             1 OCTET         1 OCTET
+      +-----------+-----------+-----+---------------+---------------+
+      | octet-one | octet-two | ... | octet-fifteen | octet-sixteen |
+      +-----------+-----------+-----+---------------+---------------+
+    </doc>
+
+    <doc type="bnf">
+             bin128 = 16 OCTET
+    </doc>
+  </type>
+
+  <type name="uuid" code="0x48" fixed-width="16" label="UUID (RFC-4122 section 4.1.2) - 16 octets">
+    <doc>
+      The uuid type encodes a universally unique id as defined by RFC-4122. The format and
+      operations for this type can be found in section 4.1.2 of RFC-4122.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+          16 OCTETs
+      +---------------+
+      |     uuid      |
+      +---------------+
+        RFC-4122 UUID
+    </doc>
+
+    <doc type="bnf">
+               uuid = 16 OCTET ; RFC-4122 section 4.1.2
+    </doc>
+  </type>
+
+  <!--
+    0x50 - 0x5f: Fixed width types - 32 octets
+  -->
+
+  <type name="bin256" code="0x50" fixed-width="32"
+        label="thirty two octets of unspecified binary encoding">
+    <doc>
+      The bin256 type consists of thirty two consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET              1 OCTET            1 OCTET
+      +-----------+-----------+-----+------------------+------------------+
+      | octet-one | octet-two | ... | octet-thirty-one | octet-thirty-two |
+      +-----------+-----------+-----+------------------+------------------+
+    </doc>
+
+    <doc type="bnf">
+             bin256 = 32 OCTET
+    </doc>
+  </type>
+
+  <!--
+    0x60 - 0x6f: Fixed width types - 64 octets
+  -->
+
+  <type name="bin512" code="0x60" fixed-width="64"
+        label="sixty four octets of unspecified binary encoding">
+    <doc>
+      The bin512 type consists of sixty four consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET               1 OCTET            1 OCTET
+      +-----------+-----------+-----+-------------------+------------------+
+      | octet-one | octet-two | ... | octet-sixty-three | octet-sixty-four |
+      +-----------+-----------+-----+-------------------+------------------+
+    </doc>
+
+    <doc type="bnf">
+             bin512 = 64 OCTET
+    </doc>
+  </type>
+
+  <!--
+    0x70 - 0x7f: Fixed width types - 128 octets
+  -->
+
+  <type name="bin1024" code="0x70" fixed-width="128"
+        label="one hundred and twenty eight octets of unspecified binary encoding">
+    <doc>
+      The bin1024 type consists of one hundred and twenty eight octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET                 1 OCTET                  1 OCTET
+      +-----------+-----------+-----+------------------------+------------------------+
+      | octet-one | octet-two | ... | octet-one-twenty-seven | octet-one-twenty-eight |
+      +-----------+-----------+-----+------------------------+------------------------+
+    </doc>
+
+    <doc type="bnf">
+            bin1024 = 128 OCTET
+    </doc>
+  </type>
+
+  <!--
+    0x80 - 0x8f: Variable length - one byte length field (up to 255 octets)
+  -->
+
+  <type name="vbin8" code="0x80" variable-width="1" label="up to 255 octets of opaque binary data">
+    <doc>
+      The vbin8 type encodes up to 255 octets of opaque binary data. The number of octets is first
+      encoded as an 8-bit unsigned integral value. This is followed by the actual data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET   size OCTETs
+      +---------+-------------+
+      |  size   |   octets    |
+      +---------+-------------+
+         uint8
+    </doc>
+
+    <doc type="bnf">
+              vbin8 = size octets
+               size = uint8
+             octets = 0*255 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="str8-latin" code="0x84" variable-width="1" label="up to 255 iso-8859-15 characters">
+    <doc>
+      The str8-latin type encodes up to 255 octets of iso-8859-15 characters. The number of octets
+      is first encoded as an 8-bit unsigned integral value. This is followed by the actual
+      characters.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET        size OCTETs
+      +---------+------------------------+
+      |  size   |       characters       |
+      +---------+------------------------+
+        uint16    iso-8859-15 characters
+    </doc>
+
+    <doc type="bnf">
+         str8-latin = size characters
+               size = uint8
+         characters = 0*255 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="str8" code="0x85" variable-width="1" label="up to 255 octets worth of UTF-8 unicode">
+    <doc>
+      The str8 type encodes up to 255 octets worth of UTF-8 unicode. The number of octets of unicode
+      is first encoded as an 8-bit unsigned integral value. This is followed by the actual UTF-8
+      unicode. Note that the encoded size refers to the number of octets of unicode, not necessarily
+      the number of characters since the UTF-8 unicode may include multi-byte character sequences.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET   size OCTETs
+      +---------+--------------+
+      |  size   | utf8-unicode |
+      +---------+--------------+
+         uint8
+    </doc>
+
+    <doc type="bnf">
+               str8 = size utf8-unicode
+               size = uint8
+       utf8-unicode = 0*255 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="str8-utf16" code="0x86" variable-width="1"
+        label="up to 255 octets worth of UTF-16 unicode">
+    <doc>
+      The str8-utf16 type encodes up to 255 octets worth of UTF-16 unicode. The number of octets of
+      unicode is first encoded as an 8-bit unsigned integral value. This is followed by the actual
+      UTF-16 unicode. Note that the encoded size refers to the number of octets of unicode, not the
+      number of characters since the UTF-16 unicode will include at least two octets per unicode
+      character.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET    size OCTETs
+      +---------+---------------+
+      |  size   | utf16-unicode |
+      +---------+---------------+
+         uint8
+    </doc>
+
+    <doc type="bnf">
+         str8-utf16 = size utf16-unicode
+               size = uint8
+      utf16-unicode = 0*255 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <!--
+    0x90 - 0x9f: Variable length types - two byte length field (up to 65535 octets)
+  -->
+
+  <type name="vbin16" code="0x90" variable-width="2"
+        label="up to 65535 octets of opaque binary data">
+    <doc>
+      The vbin16 type encodes up to 65535 octets of opaque binary data. The number of octets is
+      first encoded as a 16-bit unsigned integral value in network byte order. This is followed by
+      the actual data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        2 OCTETs   size OCTETs
+      +----------+-------------+
+      |   size   |   octets    |
+      +----------+-------------+
+         uint16
+    </doc>
+
+    <doc type="bnf">
+             vbin16 = size octets
+               size = uint16
+             octets = 0*65535 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="str16-latin" code="0x94" variable-width="2"
+        label="up to 65535 iso-8859-15 characters">
+    <doc>
+      The str16-latin type encodes up to 65535 octets of is-8859-15 characters. The number of octets
+      is first encoded as a 16-bit unsigned integral value in network byte order. This is followed
+      by the actual characters.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        2 OCTETs        size OCTETs
+      +----------+------------------------+
+      |   size   |       characters       |
+      +----------+------------------------+
+         uint16    iso-8859-15 characters
+    </doc>
+
+    <doc type="bnf">
+        str16-latin = size characters
+               size = uint16
+         characters = 0*65535 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="str16" code="0x95" variable-width="2"
+        label="up to 65535 octets worth of UTF-8 unicode">
+    <doc>
+      The str16 type encodes up to 65535 octets worth of UTF-8 unicode. The number of octets is
+      first encoded as a 16-bit unsigned integral value in network byte order. This is followed by
+      the actual UTF-8 unicode. Note that the encoded size refers to the number of octets of
+      unicode, not necessarily the number of unicode characters since the UTF-8 unicode may include
+      multi-byte character sequences.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        2 OCTETs   size OCTETs
+      +----------+--------------+
+      |   size   | utf8-unicode |
+      +----------+--------------+
+         uint16
+    </doc>
+
+    <doc type="bnf">
+              str16 = size utf8-unicode
+               size = uint16
+       utf8-unicode = 0*65535 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="str16-utf16" code="0x96" variable-width="2"
+        label="up to 65535 octets worth of UTF-16 unicode">
+    <doc>
+      The str16-utf16 type encodes up to 65535 octets worth of UTF-16 unicode. The number of octets
+      is first encoded as a 16-bit unsigned integral value in network byte order. This is followed
+      by the actual UTF-16 unicode. Note that the encoded size refers to the number of octets of
+      unicode, not the number of unicode characters since the UTF-16 unicode will include at least
+      two octets per unicode character.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        2 OCTETs    size OCTETs
+      +----------+---------------+
+      |   size   | utf16-unicode |
+      +----------+---------------+
+         uint16
+    </doc>
+
+    <doc type="bnf">
+        str16-utf16 = size utf16-unicode
+               size = uint16
+      utf16-unicode = 0*65535 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="sequence-set" variable-width="2" label="ranged set representation">
+    <doc>
+      The sequence-set type is a set of pairs of RFC-1982 numbers representing a discontinuous range
+      within an RFC-1982 sequence. Each pair represents a closed interval within the list.
+    </doc>
+
+    <doc>
+      Sequence-sets can be represented as lists of pairs of positive 32-bit numbers, each pair
+      representing a closed interval that does not overlap or touch with any other interval in the
+      list. For example, a set containing words 0, 1, 2, 5, 6, and 15 can be represented:
+    </doc>
+
+    <doc type="picture">
+      [(0, 2), (5, 6), (15, 15)]
+    </doc>
+
+    <doc>
+      1) The list-of-pairs representation is sorted ascending (as defined by RFC 1982
+      (http://www.ietf.org/rfc/rfc1982.txt) ) by the first elements of each pair.
+    </doc>
+
+    <doc>
+      2) The list-of-pairs is flattened into a list-of-words.
+    </doc>
+
+    <doc>
+      3) Each word in the list is packed into ascending locations in memory with network byte
+      ordering.
+    </doc>
+
+    <doc>
+      4) The size in bytes, represented as a 16-bit network-byte-order unsigned value, is prepended.
+    </doc>
+
+    <doc>
+      For instance, the example from above would be encoded:
+    </doc>
+
+    <doc type="picture">
+      [(0, 2), (5, 6), (15, 15)]                           -- already sorted.
+      [0, 2, 5, 6, 15, 15]                                 -- flattened.
+      000000000000000200000005000000060000000F0000000F     -- bytes in hex
+      0018000000000000000200000005000000060000000F0000000F -- bytes in hex,
+                                                              length (24) prepended
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+                 +----= size OCTETs =----+
+                 |                       |
+        2 OCTETs |       8 OCTETs        |
+      +----------+-----+-----------+-----+
+      |   size   | .../|   range   |\... |
+      +----------+---/ +-----------+ \---+
+         uint16     / /             \ \
+                   / /               \ \
+                  / /                 \ \
+                 / /                   \ \
+                / 4 OCTETs       4 OCTETs \
+               +-------------+-------------+
+               |    lower    |    upper    |
+               +-------------+-------------+
+                 sequence-no   sequence-no
+    </doc>
+
+    <doc type="bnf">
+       sequence-set = size *range
+               size = uint16         ; length of variable portion in bytes
+
+              range = lower upper   ; inclusive
+              lower = sequence-no
+              upper = sequence-no
+    </doc>
+  </type>
+
+  <!--
+    0xa0 - 0xaf: Variable length types - four byte length field (up to 4294967295 octets)
+  -->
+
+  <type name="vbin32" code="0xa0" variable-width="4"
+        label="up to 4294967295 octets of opaque binary data">
+    <doc>
+      The vbin32 type encodes up to 4294967295 octets of opaque binary data. The number of octets is
+      first encoded as a 32-bit unsigned integral value in network byte order. This is followed by
+      the actual data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        4 OCTETs   size OCTETs
+      +----------+-------------+
+      |   size   |   octets    |
+      +----------+-------------+
+         uint32
+    </doc>
+
+    <doc type="bnf">
+             vbin32 = size octets
+               size = uint32
+             octets = 0*4294967295 OCTET ; size OCTETs
+    </doc>
+  </type>
+
+  <type name="map" code="0xa8" variable-width="4" label="a mapping of keys to typed values">
+    <doc>
+      A map is a set of distinct keys where each key has an associated (type,value) pair. The triple
+      of the key, type, and value, form an entry within a map. Each entry within a given map MUST
+      have a distinct key. A map is encoded as a size in octets, a count of the number of entries,
+      followed by the encoded entries themselves.
+    </doc>
+
+    <doc>
+      An encoded map may contain up to (4294967295 - 4) octets worth of encoded entries. The size is
+      encoded as a 32-bit unsigned integral value in network byte order equal to the number of
+      octets worth of encoded entries plus 4. (The extra 4 octets is added for the entry count.) The
+      size is then followed by the number of entries encoded as a 32-bit unsigned integral value in
+      network byte order. Finally the entries are encoded sequentially.
+    </doc>
+
+    <doc>
+      An entry is encoded as the key, followed by the type, and then the value. The key is always a
+      string encoded as a str8. The type is a single octet that may contain any valid AMQP type
+      code. The value is encoded according to the rules defined by the type code for that entry.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+                 +------------= size OCTETs =-----------+
+                 |                                      |
+        4 OCTETs | 4 OCTETs                             |
+      +----------+----------+-----+---------------+-----+
+      |   size   |  count   | .../|     entry     |\... |
+      +----------+----------+---/ +---------------+ \---+
+         uint32     uint32     / /                 \ \
+                              / /                   \ \
+                             / /                     \ \
+                            / /                       \ \
+                           / /                         \ \
+                          / k OCTETs   1 OCTET   n OCTETs \
+                         +-----------+---------+-----------+
+                         |    key    |  type   |   value   |
+                         +-----------+---------+-----------+
+                             str8                 *type*
+    </doc>
+
+    <doc type="bnf">
+                map = size count *entry
+
+               size = uint32             ; size of count and entries in octets
+              count = uint32             ; number of entries in the map
+
+              entry = key type value
+                key = str8
+               type = OCTET              ; type code of the value
+              value = *OCTET             ; the encoded value
+    </doc>
+  </type>
+
+  <type name="list" code="0xa9" variable-width="4" label="a series of consecutive type-value pairs">
+    <doc>
+      A list is an ordered sequence of (type, value) pairs. The (type, value) pair forms an item
+      within the list.  The list may contain items of many distinct types. A list is encoded as a
+      size in octets, followed by a count of the number of items, followed by the items themselves
+      encoded in their defined order.
+    </doc>
+
+    <doc>
+      An encoded list may contain up to (4294967295 - 4) octets worth of encoded items. The size is
+      encoded as a 32-bit unsigned integral value in network byte order equal to the number of
+      octets worth of encoded items plus 4. (The extra 4 octets is added for the item count.) The
+      size is then followed by the number of items encoded as a 32-bit unsigned integral value in
+      network byte order. Finally the items are encoded sequentially in their defined order.
+    </doc>
+
+    <doc>
+      An item is encoded as the type followed by the value. The type is a single octet that may
+      contain any valid AMQP type code. The value is encoded according to the rules defined by the
+      type code for that item.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+                 +---------= size OCTETs =---------+
+                 |                                 |
+        4 OCTETs | 4 OCTETs                        |
+      +----------+----------+-----+----------+-----+
+      |   size   |  count   | .../|   item   |\... |
+      +----------+----------+---/ +----------+ \---+
+         uint32     uint32     / /            \ \
+                              / /              \ \
+                             / 1 OCTET   n OCTETs \
+                            +----------+-----------+
+                            |   type   |   value   |
+                            +----------+-----------+
+                                          *type*
+    </doc>
+
+    <doc type="bnf">
+               list = size count *item
+
+               size = uint32            ; size of count and items in octets
+              count = uint32            ; number of items in the list
+
+               item = type value
+               type = OCTET             ; type code of the value
+              value = *OCTET            ; the encoded value
+    </doc>
+  </type>
+
+  <type name="array" code="0xaa" variable-width="4"
+        label="a defined length collection of values of a single type">
+    <doc>
+      An array is an ordered sequence of values of the same type. The array is encoded in as a size
+      in octets, followed by a type code, then a count of the number values in the array, and
+      finally the values encoded in their defined order.
+    </doc>
+
+    <doc>
+      An encoded array may contain up to (4294967295 - 5) octets worth of encoded values. The size
+      is encoded as a 32-bit unsigned integral value in network byte order equal to the number of
+      octets worth of encoded values plus 5. (The extra 5 octets consist of 4 octets for the count
+      of the number of values, and one octet to hold the type code for the items in the array.) The
+      size is then followed by a single octet that may contain any valid AMQP type code. The type
+      code is then followed by the number of values encoded as a 32-bit unsigned integral value in
+      network byte order. Finally the values are encoded sequentially in their defined order
+      according to the rules defined by the type code for the array.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        4 OCTETs   1 OCTET   4 OCTETs      (size - 5) OCTETs
+      +----------+---------+----------+-------------------------+
+      |   size   |  type   |  count   |         values          |
+      +----------+---------+----------+-------------------------+
+         uint32               uint32    *count* encoded *types*
+    </doc>
+
+    <doc type="bnf">
+              array = size type count values
+
+               size = uint32            ; size of type, count, and values in octets
+               type = OCTET             ; the type of the encoded values
+              count = uint32            ; number of items in the array
+
+             values = 0*4294967290 OCTET ; (size - 5) OCTETs
+    </doc>
+  </type>
+
+  <type name="struct32" code="0xab" variable-width="4" label="a coded struct with a 32-bit size">
+    <doc>
+      The struct32 type describes any coded struct with a 32-bit (4 octet) size. The type is
+      restricted to be only coded structs with a 32-bit size, consequently the first six octets of
+      any encoded value for this type MUST always contain the size, class-code, and struct-code in
+      that order.
+    </doc>
+
+    <doc>
+      The size is encoded as a 32-bit unsigned integral value in network byte order that is equal to
+      the size of the encoded field-data, packing-flags, class-code, and struct-code. The class-code
+      is a single octet that may be set to any valid class code. The struct-code is a single octet
+      that may be set to any valid struct code within the given class-code.
+    </doc>
+
+    <doc>
+      The first six octets are then followed by the packing flags and encoded field data. The
+      presence and quantity of packing-flags, as well as the specific fields are determined by the
+      struct definition identified with the encoded class-code and struct-code.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        4 OCTETs    1 OCTET       1 OCTET     pack-width OCTETs    n OCTETs
+      +----------+------------+-------------+-------------------+------------+
+      |   size   | class-code | struct-code |   packing-flags   | field-data |
+      +----------+------------+-------------+-------------------+------------+
+         uint32
+
+                          n = (size - 2 - pack-width)
+    </doc>
+
+    <doc type="bnf">
+           struct32 = size class-code struct-code packing-flags field-data
+
+               size = uint32
+
+         class-code = OCTET     ; zero for top-level structs
+        struct-code = OCTET     ; together with class-code identifies the struct
+                                ; definition which determines the pack-width and
+                                ; fields
+
+      packing-flags = 0*4 OCTET ; pack-width OCTETs
+
+         field-data = *OCTET    ; (size - 2 - pack-width) OCTETs
+    </doc>
+  </type>
+
+  <!--
+    0xb0 - 0xbf: Reserved
+  -->
+
+  <!--
+    0xc0 - 0xcf:Fixed width types - 5 octets
+  -->
+
+  <type name="bin40" code="0xc0" fixed-width="5" label="five octets of unspecified binary encoding">
+    <doc>
+      The bin40 type consists of five consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET      1 OCTET      1 OCTET      1 OCTET
+      +-----------+-----------+-------------+------------+------------+
+      | octet-one | octet-two | octet-three | octet-four | octet-five |
+      +-----------+-----------+-------------+------------+------------+
+    </doc>
+
+    <doc type="bnf">
+              bin40 = 5 OCTET
+    </doc>
+  </type>
+
+  <type name="dec32" code="0xc8" fixed-width="5"
+        label="32-bit decimal value (e.g. for use in financial values)">
+    <doc>
+      The dec32 type is decimal value with a variable number of digits following the decimal point.
+      It is encoded as an 8-bit unsigned integral value representing the number of decimal places.
+      This is followed by the signed integral value encoded using a 32-bit two's complement
+      representation in network byte order.
+    </doc>
+
+    <doc>
+      The former value is referred to as the exponent of the divisor. The latter value is the
+      mantissa. The decimal value is given by: mantissa / 10^exponent.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET    4 OCTETs
+      +----------+----------+
+      | exponent | mantissa |
+      +----------+----------+
+         uint8      int32
+    </doc>
+
+    <doc type="bnf">
+              dec32 = exponent mantissa
+           exponent = uint8
+           mantissa = int32
+    </doc>
+  </type>
+
+  <!--
+    0xd0 - 0xdf: Fixed width types - 9 octets
+  -->
+
+  <type name="bin72" code="0xd0" fixed-width="9"
+        label="nine octets of unspecified binary encoding">
+    <doc>
+      The bin72 type consists of nine consecutive octets of opaque binary data.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+         1 OCTET     1 OCTET            1 OCTET      1 OCTET
+      +-----------+-----------+-----+-------------+------------+
+      | octet-one | octet-two | ... | octet-eight | octet-nine |
+      +-----------+-----------+-----+-------------+------------+
+    </doc>
+
+    <doc type="bnf">
+              bin64 = 9 OCTET
+    </doc>
+  </type>
+
+  <type name="dec64" code="0xd8" fixed-width="9"
+        label="64-bit decimal value (e.g. for use in financial values)">
+    <doc>
+      The dec64 type is decimal value with a variable number of digits following the decimal point.
+      It is encoded as an 8-bit unsigned integral value representing the number of decimal places.
+      This is followed by the signed integral value encoded using a 64-bit two's complement
+      representation in network byte order.
+    </doc>
+
+    <doc>
+      The former value is referred to as the exponent of the divisor. The latter value is the
+      mantissa. The decimal value is given by: mantissa / 10^exponent.
+    </doc>
+
+    <doc type="picture" title="Wire Format">
+        1 OCTET    8 OCTETs
+      +----------+----------+
+      | exponent | mantissa |
+      +----------+----------+
+         uint8      int64
+    </doc>
+
+    <doc type="bnf">
+              dec64 = exponent mantissa
+           exponent = uint8
+           mantissa = int64
+    </doc>
+  </type>
+
+  <!--
+    0xe0 - 0xef: Reserved
+  -->
+
+  <!--
+    0xf0 - 0xff: Zero-length types
+  -->
+
+  <type name="void" code="0xf0" fixed-width="0" label="the void type">
+    <doc>
+      The void type is used within tagged data structures such as maps and lists to indicate an
+      empty value. The void type has no value and is encoded as an empty sequence of octets.
+    </doc>
+  </type>
+
+  <type name="bit" code="0xf1" fixed-width="0" label="presence indicator">
+    <doc>
+      The bit type is used to indicate that a packing flag within a packed struct is being used to
+      represent a boolean value based on the presence of an empty value. The bit type has no value
+      and is encoded as an empty sequence of octets.
+    </doc>
+  </type>
+
+  <!--
+    ======================================================
+    ==       CONSTANTS
+    ======================================================
+  -->
+
+  <!-- Protocol constants -->
+
+  <constant name="MIN-MAX-FRAME-SIZE" value="4096" label="The minimum size (in bytes) which can be
+    agreed upon as the maximum frame size.">
+    <doc>
+      During the initial connection negotiation, the two peers must agree upon a maximum frame size.
+      This constant defines the minimum value to which the maximum frame size can be set.  By
+      defining this value, the peers can guarantee that they can send frames of up to this size
+      until they have agreed a definitive maximum frame size for that connection.
+    </doc>
+  </constant>
+
+  <!--
+    ======================================================
+    ==       DOMAIN TYPES
+    ======================================================
+  -->
+
+  <!-- Segment types -->
+
+  <domain name="segment-type" type="uint8" label="valid values for the frame type indicator.">
+    <doc>
+      Segments are defined in <xref ref="specification.transport.assemblies_segments_and_frames"/>.
+      The segment domain defines the valid values that may be used for the segment indicator within
+      the frame header.
+    </doc>
+
+    <enum>
+      <choice name="control" value="0">
+        <doc>
+          The frame type indicator for Control segments (see <xref
+          ref="specification.formal_notation.controls"/>).
+        </doc>
+      </choice>
+      <choice name="command" value="1">
+        <doc>
+          The frame type indicator for Command segments (see <xref
+            ref="specification.formal_notation.commands"/>).
+        </doc>
+      </choice>
+      <choice name="header" value="2" >
+        <doc>
+          The frame type indicator for Header segments (see <xref
+            ref="specification.formal_notation.segments.header"/>).
+        </doc>
+      </choice>
+      <choice name="body" value="3" >
+        <doc>
+          The frame type indicator for Body segments (see <xref
+            ref="specification.formal_notation.segments.body"/>).
+        </doc>
+      </choice>
+    </enum>
+  </domain>
+
+
+  <domain name="str16-array" type="array" label="An array of values of type str16.">
+    <doc>
+      An array of values of type str16.
+    </doc>
+  </domain>
+
+
+
+  <!-- == Class: connection ==================================================================== -->
+
+  <class name="connection" code="0x1" label="work with connections">
+    <doc>
+      The connection class provides controls for two peers to establish a network connection, and
+      for both peers to operate the connection thereafter. Either peer may operate in the server or
+      client roles.
+    </doc>
+
+    <doc type="grammar">
+      connection        = open-connection
+                          *use-connection
+                          close-connection
+      open-connection   = C:protocol-header
+                          S:OPEN C:OPEN
+                          [ sasl-exchange ]
+      sasl-exchange     = C:SASL-INIT *( S:SASL-CHALLENGE C:SASL-RESPONSE ) C:SASL-DONE
+      use-connection    = *channel
+      close-connection  = S:CLOSE C:CLOSE
+    </doc>
+
+    <role name="server" implement="MUST" />
+    <role name="client" implement="MUST" />
+
+    <domain name="close-code" type="uint16" label="code used in the connection.close control to
+      indicate reason for closure">
+      <enum>
+        <choice name="normal" value="200">
+          <doc>
+            The connection closed normally.
+          </doc>
+        </choice>
+
+        <choice name="connection-forced" value="320">
+          <doc>
+            An operator intervened to close the connection for some reason. The client may retry at
+            some later date.
+          </doc>
+        </choice>
+
+        <choice name="authentication-failure" value="401">
+          <doc>
+            The SASL authentication exchange failed.
+          </doc>
+        </choice>
+
+        <choice name="invalid-path" value="402">
+          <doc>
+            The client tried to work with an unknown virtual host.
+          </doc>
+        </choice>
+
+        <choice name="framing-error" value="501">
+          <doc>
+            A valid frame header cannot be formed from the incoming byte stream.
+          </doc>
+        </choice>
+      </enum>
+    </domain>
+
+    <domain name="amqp-host-url" type="str16" label="URL for identifying an AMQP Server">
+      <doc>
+        The amqp-url domain defines a format for identifying an AMQP Server.  It is used to provide
+        alternate hosts in the case where a client has to reconnect because of failure, or because
+        the server requests the client to do so upon initial connection.
+      </doc>
+      <doc type="bnf"><![CDATA[
+        amqp_url          = "amqp:" prot_addr_list
+        prot_addr_list    = [prot_addr ","]* prot_addr
+        prot_addr         = tcp_prot_addr | tls_prot_addr
+
+        tcp_prot_addr     = tcp_id tcp_addr
+        tcp_id            = "tcp:" | ""
+        tcp_addr          = [host [":" port] ]
+        host              = <as per http://www.ietf.org/rfc/rfc3986.txt>
+        port              = number]]>
+      </doc>
+    </domain>
+
+    <domain name="amqp-host-array" type="array" label="An array of values of type amqp-host-url">
+      <doc>
+        Used to provide a list of alternate hosts.
+      </doc>
+    </domain>
+
+    <domain name="sasl-code" type="uint8" label="indicates the disposition of the sasl dialog">
+      <enum>
+        <choice name="ok" value="0">
+          <doc>
+            The connection was successfully authenticated.
+          </doc>
+        </choice>
+        <choice name="authentication-failed" value="1">
+          <doc>
+            Connection authentication failed.
+          </doc>
+        </choice>
+      </enum>
+    </domain>
+
+    <!-- - Control: connection.open  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="open" code="0x1" label="open connection to a virtual host">
+      <doc>
+        This control 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>
+
+      <implement role="server" handle="MUST" />
+      <implement role="client" handle="MUST" />
+
+      <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 control.
+        </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="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>
+
+      <field name="virtual-host" type="str16" default="" label="virtual host name">
+        <doc>
+          The name of the virtual host to which the connection is being opened. The default virtual
+          host is the virtual host with name of length zero. It is not mandatory to provide such a
+          virtual host.
+        </doc>
+
+        <rule name="isolation">
+          <doc>
+            If the server supports multiple virtual hosts, it MUST enforce a full isolation 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>
+      </field>
+
+      <field name="max-frame-size" type="uint16" label="proposed maximum frame size">
+        <doc>
+          The largest frame size that the peer proposes for the connection. If this is not set means
+          that the server does not impose any specific limit.
+        </doc>
+
+        <rule name="established-max-frame-size">
+          <doc>
+            The max-frame-size established for the connection is the minimum of the two proposed
+            values. If neither peer sets a max-frame-size the established max-frame-size is
+            (2^16)-1.
+          </doc>
+        </rule>
+
+        <rule name="minimum">
+          <doc>
+            Until the max-frame-size has been negotiated, both peers MUST accept frames of up to
+            MIN-MAX-FRAME-SIZE octets large.
+          </doc>
+        </rule>
+
+        <rule name="frame-size-limit">
+          <doc>
+            A peer MUST NOT send frames larger than the agreed-upon size. A peer that receives an
+            oversized frame MUST close the connection with the framing-error close-code.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="channel-max" type="uint16"
+             label="the maximum number of channels available for session attachment">
+        <doc>
+          The maximum number of channels available for session attachment by the recipient. For a
+          typical client this would be zero. For a typical server this would be the maximum number
+          of supported channels.
+        </doc>
+
+        <rule name="upper-limit">
+          <doc>
+            The channel-max value may never exceed 2^15.
+          </doc>
+        </rule>
+
+        <rule name="available-channels">
+          <doc>
+            If a peer advertises a channel-max of N channels, then the channels available for
+            session attachment are precisely the channels numbered 0 to (N-1).
+          </doc>
+        </rule>
+      </field>
+
+      <field name="heartbeat-interval" type="uint16" label="proposed heartbeat interval">
+        <doc>
+          The proposed interval, in seconds, of the connection heartbeat desired by the sender. A
+          value of zero means heartbeats are not supported. If the value is not set, the sender
+          supports all heartbeat intervals.
+        </doc>
+
+        <rule name="established-heartbeat">
+          <doc>
+            The heartbeat-interval established is the minimum of the two proposed
+            heartbeat-intervals. If neither value is set, there is no heartbeat.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="sasl-server-mechanisms" type="str16-array" label="supported sasl mechanisms">
+        <doc>
+          A list of the sasl security mechanisms supported by the sending peer. If the sending peer
+          does not require its partner to authenticate with it, this array may be empty or absent.
+          The server mechanisms are ordered in decreasing level of preference.
+        </doc>
+      </field>
+
+      <field name="supported-locales" type="str16-array" label="locales that are supported">
+        <doc>
+          A list of the locales that the peer supports. The locale defines the language in which the
+          peer will send protocol level error messages. This includes connection close text, reject
+          text, and session exception text. The default is the en_US locale.
+        </doc>
+
+        <rule name="required-support">
+          <doc>
+            The peer MUST support at least the en_US locale. Since this value is always supported,
+            it need not be supplied in the supported-locales array.
+          </doc>
+        </rule>
+      </field>
+
+      <field name="preferred-locales" type="str16-array"
+             label="acceptable locales in decreasing level of preference">
+        <doc>
+          A list of locales that the sending peer will accept. This list is ordered in decreasing
+          level of preference. The receiving partner will chose the most preferred locale from its
+          supported-locales list. If none of the preferred locales are supported, en_US will be
+          chosen. Note that en_US need not be supplied in this list as it always the fallback.
+        </doc>
+      </field>
+
+      <field name="client-properties" type="map" 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="server-properties" type="map" 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>
+    </control>
+
+    <!-- - Control: connection.sasl-init - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="sasl-init" code="0x2" label="initiate sasl exchange">
+      <doc>
+        Selects the sasl mechanism and provides the initial response if needed.
+      </doc>
+
+      <implement role="server" handle="MUST" />
+
+      <field name="mechanism" type="str16" label="selected security mechanism" required="true">
+        <doc>
+          The name of the SASL mechanism used for the SASL exchange.
+        </doc>
+
+        <rule name="supported-mechanisms">
+          <doc>
+            The mechanism chosen must be the one of the supported mechanisms supplied by the peer.
+          </doc>
+        </rule>
+
+        <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 connection.open control, the server MUST close the connection without
+            sending any further data.
+          </doc>
+        </rule>
+      </field>
+
+
+      <field name="initial-response" type="vbin32" 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>
+      </field>
+    </control>
+
+    <!-- - Control: connection.sasl-challenge  - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="sasl-challenge" code="0x3" label="security mechanism challenge">
+      <implement role="client" handle="MUST" />
+
+      <response name="sasl-response" />
+
+      <field name="challenge" type="vbin32" label="security challenge data" required="true">
+        <doc>
+          Challenge information, a block of opaque binary data passed to the security mechanism.
+        </doc>
+      </field>
+    </control>
+
+    <!-- - Control: connection.sasl-response - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="sasl-response" code="0x4" label="security mechanism response">
+      <doc>
+        This control attempts to authenticate, passing a block of SASL data for the security
+        mechanism at the server side.
+      </doc>
+
+      <implement role="server" handle="MUST" />
+
+      <field name="response" type="vbin32" label="security response data" required="true">
+        <doc>
+          A block of opaque data passed to the security mechanism. The contents of this data are
+          defined by the SASL security mechanism.
+        </doc>
+      </field>
+    </control>
+
+    <!-- - Control: connection.sasl-done - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="sasl-done" code="0x5" label="terminate sasl dialog">
+      <doc>
+        This control terminates the sasl dialog.
+      </doc>
+
+      <implement role="client" handle="MUST" />
+
+      <field name="code" type="sasl-code" label="indicates the disposition of the sasl dialog">
+        <doc>
+          A reply-code indicating the disposition of the sasl dialog.
+        </doc>
+      </field>
+    </control>
+
+    <!-- - Control: connection.heartbeat - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="heartbeat" code="0x6" label="indicates connection is still alive">
+      <doc>
+        The heartbeat control may be used to generate artificial network traffic when a connection
+        is idle. If a connection is idle for more than twice the negotiated heartbeat delay, the
+        peers MAY be considered disconnected.
+      </doc>
+    </control>
+
+    <!-- - Control: connection.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <control name="close" code="0x7" label="request a connection close">
+      <doc>
+        This control indicates that the sender wants to close the connection. The reason for close
+        is indicated with the reply-code and reply-text. The channel this control is sent on MAY be
+        used to indicate which channel caused the connection to close.
+      </doc>
+
+      <implement role="client" handle="MUST" />
+      <implement role="server" handle="MUST" />
+
+      <field name="reply-code" type="close-code" label="the numeric reply code"
+        required="true">
+        <doc>
+          Indicates the reason for connection closure.
+        </doc>
+      </field>
+      <field name="reply-text" type="str8" label="the localized reply text">
+        <doc>
+          This text can be logged as an aid to resolving issues.
+        </doc>
+      </field>
+    </control>
+  </class>
+
+  <!-- == Class: session ======================================================================= -->
+
+  <class name="session" code="0x2" label="session controls">
+    <doc>
+      A session is a named interaction between two peers. Session names are chosen by the upper
+      layers and may be used indefinitely. The model layer may associate long-lived or durable state
+      with a given session name. The session layer provides transport of commands associated with
+      this interaction.
+    </doc>
+
+    <doc type="picture"><![CDATA[
+  Sender:                                                   Receiver:
+                                  |--in-flight--|
+      +--------------+--------------------------+               +-----------------+-----------+
+      |   C1 C2 C3   |   C4 C5 C6   C7 C8 C9    |    ------>    |   C1 C2 C3 C4   |   C5 C6   |
+      +--------------+--------------------------+               +-----------------+-----------+
+          complete          replay queue                             complete       work queue
+
+  C1, C2, C3: completed at the receiver, known to be completed by the sender
+          C4: completed at the receiver, *not* known to be completed by the sender
+      C5, C6: received by the sender, but not yet completed
+  C7, C8, C9: transmitted by the sender, but not yet received
+
+  Sender state:
+    last-completed: marks the tail of replay queue
+    last-sent:      marks the head of replay queue
+
+  Receiver state:
+    last-completed: marks the tail of the work queue
+    last-received:  marks the head of work queue
+
+  State exchanged periodically between the two endpoints of a full
+  duplex session. Each endpoint has both a sender and a receiver:
+
+             (sender-completed, receiver-completed)
+                      /|\            /|\
+                       |              |
+                       |    allows the sender to shrink replay queue
+                       |
+      allows the receiver to know that sender won't replay
+
+  State exchanged between the two endpoints on open/resume:
+
+                 (last-sent, last-received)
+                     /|\          /|\
+                      |            |
+                      |    tells sender where to resume from
+                      |    (null for open)
+                      |
+      tells receiver where to start counting command-ids on open
+      (null for resume)]]>
+    </doc>
+
+    <doc>
+      The controls defined within this class are specified in terms of the "sender" of commands and
+      the "receiver" of commands. Since both client and server send and receive commands, the
+      overall session dialog is symmetric, however the semantics of the session controls are defined
+      in terms of a single sender/receiver pair, and it is assumed that the client and server will
+      each contain both a sender and receiver implementation.
+    </doc>
+
+    <rule name="attachment">
+      <doc>
+        The transport MUST be attached in order to use any control other than "attach", "attached",
+        "detach", or "detached". A peer receiving any other control on a detached transport MUST
+        discard it and send a session.detached with the "not-attached" reason code.
+      </doc>
+    </rule>
+
+    <role name="server" implement="MUST" />
+    <role name="client" implement="MUST" />
+
+    <role name="sender" implement="MUST">
+      <doc>
+        The sender of commands.
+      </doc>
+    </role>
+    <role name="receiver" implement="MUST">
+      <doc>
+        The receiver of commands.
+      </doc>
+    </role>
+
+    <domain name="name" type="vbin16" label="opaque session name">
+      <doc>
+        The session name uniquely identifies an interaction between two peers. It is scoped to a
+        given authentication principal.
+      </doc>
+    </domain>
+
+    <domain name="detach-code" type="uint8" label="reason for detach">
+      <enum>
+        <choice name="normal" value="0">
+          <doc>
+            The session was detached by request.
+          </doc>
+        </choice>
+        <choice name="session-busy" value="1">
+          <doc>
+            The session is currently attached to another transport.
+          </doc>
+        </choice>
+        <choice name="transport-busy" value="2">
+          <doc>
+            The transport is currently attached to another session.
+          </doc>
+        </choice>
+        <choice name="not-attached" value="3">
+          <doc>
+            The transport is not currently attached to any session.
+          </doc>
+        </choice>
+        <choice name="unknown-ids" value="4">
+          <doc>
+            Command data was received prior to any use of the command-point control.
+          </doc>
+        </choice>
+      </enum>
+    </domain>
+
+    <domain name="commands" type="sequence-set" label="identifies a set of commands">
+    </domain>
+
+    <struct name="exception" size="2" pack="2" label="notifies a peer of an execution error">
+      <doc>
+        This command informs a peer of an execution exception. The command-id, when given,
+        correlates the error to a specific command.
+      </doc>
+
+      <field name="error-code" type="error-code" required="true" label="error code indicating the
+        type of error"/>
+      <field name="command-id" type="sequence-no" label="exceptional command">
+        <doc>
+          The command-id of the command which caused the exception. If the exception was not caused
+          by a specific command, this value is not set.
+        </doc>
+      </field>
+      <field name="class-code" type="uint8" label="the class code of the command whose execution
+        gave rise to the error (if appropriate)"/>
+      <field name="command-code" type="uint8" label="the class code of the command whose execution
+        gave rise to the error (if appropriate)"/>
+      <field name="field-index" type="uint8" label="index of the exceptional field">
+        <doc>
+          The zero based index of the exceptional field within the arguments to the exceptional
+          command. If the exception was not caused by a specific field, this value is not set.
+        </doc>
+      </field>
+      <field name="description" type="str16" label="descriptive text on the exception">
+        <doc>
+          The description provided is implementation defined, but MUST be in the language
+          appropriate for the selected locale.  The intention is that this description is suitable
+          for logging or alerting output.
+        </doc>
+      </field>
+      <field name="error-info" type="map" label="map to carry additional information about the
+        error"/>
+    </struct>
+
+    <control name="attach" code="0x1" label="attach to the named session">
+      <doc>
+        Requests that the current transport be attached to the named session. Success or failure
+        will be indicated with an attached or detached response. This control is idempotent.
+      </doc>
+
+      <rule name="one-transport-per-session">
+        <doc>
+          A session MUST NOT be attached to more than one transport at a time.
+        </doc>
+      </rule>
+
+      <rule name="one-session-per-transport">
+        <doc>
+          A transport MUST NOT be attached to more than one session at a time.
+        </doc>
+      </rule>
+
+      <rule name="idempotence">
+        <doc>
+          Attaching a session to its current transport MUST succeed and result in an attached
+          response.
+        </doc>
+      </rule>
+
+      <rule name="scoping">
+        <doc>
+          Attachment to the same session name from distinct authentication principals MUST succeed.
+        </doc>
+      </rule>
+
+      <implement role="server" handle="MUST" />
+      <implement role="client" handle="MUST" />
+
+      <field name="name" type="name" label="the session name" required="true">
+        <doc>
+          Identifies the session to be attached to the current transport.
+        </doc>
+      </field>
+
+      <field name="force" type="bit" label="force attachment to a busy session">
+        <doc>
+          If set then a busy session will be forcibly detached from its other transport and
+          reattached to the current transport.
+        </doc>
+      </field>
+
+      <field name="exists" type="bit" label="true iff the session exists at the endpoint"/>
+
+      <field name="first-unsent" type="sequence-no">
+<!-- XXX
+    <control name="command-point" code="0x7"
+             label="the command id and byte offset of subsequent data">
+      <doc>
+        This control is sent by the sender of commands and handled by the receiver of commands. This
+        establishes the sequence numbers associated with all subsequent command data sent from the
+        sender to the receiver. The subsequent command data will be numbered starting with the
+        values supplied in this control and proceeding sequentially. This must be used at least once
+        prior to sending any command data on newly attached transports.
+      </doc>
+
+      <rule name="newly-attached-transports">
+        <doc>
+          If command data is sent on a newly attached transport the session MUST be detached with an
+          "unknown-id" reason-code.
+        </doc>
+      </rule>
+
+      <rule name="zero-offset">
+        <doc>
+          If the offset is zero, the next data frame MUST have the first-frame and first-segment
+          flags set. Violation of this is a framing error.
+        </doc>
+      </rule>
+
+      <rule name="nonzero-offset">
+        <doc>
+          If the offset is nonzero, the next data frame MUST NOT have both the first-frame and
+          first-segment flag set. Violation of this is a framing error.
+        </doc>
+      </rule>
+
+      <implement role="receiver" handle="MUST" />
+
+      <field name="command-id" type="sequence-no" label="the command-id of the next command"
+        required="true"/>
+    </control>
+-->
+      </field>
+
+      <field name="first-resendable" type="sequence-no">
+        <doc>
+          The id of the first command the peer can resend, this may be null.
+        </doc>
+      </field>
+
+      <field name="last-received" type="sequence-no" label="the id of the last command received">
+        <doc>
+          This field carries the id of the last command received by this peer for the session. This
+          field MUST be set if and only if the session has received commands.
+        </doc>
+      </field>
+
+      <field name="requested-timeout" type="uint32" label="the requested timeout">
+        <doc>
+          The requested timeout for execution state in seconds. If not set, this control requests
+          that execution state is preserved for the maximum duration permitted by the receiving
+          peer.
+        </doc>
+
+<!-- XXX
+    <control name="request-timeout" code="0x5" label="requests the execution timeout be changed">
+      <doc>
+        This control may be sent by either the sender or receiver of commands. It requests that the
+        execution timeout be changed. This is the minimum amount of time that a peer must preserve
+        execution state for a detached session.
+      </doc>
+
+      <rule name="maximum-granted-timeout">
+        <doc>
+          The handler of this request MUST set his timeout to the maximum allowed value less than or
+          equal to the requested timeout, and MUST convey the chosen timeout in the response.
+        </doc>
+      </rule>
+
+      <implement role="sender" handle="MUST" />
+      <implement role="receiver" handle="MUST" />
+
+      <response name="timeout"/>
+
+      <field name="timeout" type="uint32" label="the requested timeout">
+        <doc>
+          The requested timeout for execution state in seconds. If not set, this control requests
+          that execution state is preserved indefinitely.
+        </doc>
+      </field>
+    </control>
+
+    <control name="timeout" code="0x6" label="the granted timeout">
+      <doc>
+        This control may be sent by the either the sender or receiver of commands. It is a
+        one-to-one reply to the request-timeout control that indicates the granted timeout for
+        execution state.
+      </doc>
+
+      <implement role="sender" handle="MUST" />
+      <implement role="receiver" handle="MUST" />
+
+      <field name="timeout" type="uint32" label="the execution timeout">
+        <doc>
+          The timeout for execution state. If not set, then execution state is preserved
+          indefinitely.
+        </doc>
+      </field>
+    </control>
+-->
+      </field>
+    </control>
+
+    <control name="detach" code="0x3" label="detach from the named session">
+      <doc>
+        Signals the end of communication on this channel for this session in this direction.
+      </doc>
+
+      <implement role="server" handle="MUST" />
+      <implement role="client" handle="MUST" />
+
+      <field name="name" type="name" label="the session name" required="true">
+        <doc>
+          Identifies the detached session.
+        </doc>
+      </field>
+      <field name="code" type="detach-code" label="the reason for detach" required="true">
+        <doc>
+          Identifies the reason for detaching from the named session.
+        </doc>
+      </field>
+      <field name="last-successful" type="sequence-no"/>
+      <field name="exception" type="exception"/>
+    </control>
+
+    <!--
+        Execution state is the set of completed incoming commands, as well as the set of outgoing
+        in-doubt commands held for replay.
+    -->
+
+    <control name="state" code="0xa" label="carries periodic updates of session state between
+                                            endpoints">
+      <doc>
+        This control carries ongoing session state between the two session endpoints.
+      </doc>
+
+      <implement role="sender" handle="MUST" />
+      <implement role="receiver" handle="MUST" />
+
+      <field name="flush" type="bit" label="requests that the peer send its state">
+        <doc>
+          If set, the peer must respond with the state if its own session endpoint.
+        </doc>
+      </field>
+
+      <field name="receiver-completed" type="sequence-no" label="last incoming command completed">
+        <doc>
+          The id of the last incoming command completed by the receiver.
+        </doc>
+      </field>
+
+      <field name="sender-completed" type="sequence-no" label="last outgoing command completed">
+        <doc>
+          The id of the last outgoing command known by the sender to be complete.
+        </doc>
+      </field>
+    </control>
+
+<!--  </class> -->
+
+  <!-- == Class: execution ===================================================================== -->
+
+<!--  <class name="execution" code="0x3" label="execution commands"> -->
+    <doc>
+      The execution class provides commands that carry execution information about other model level
+      commands.
+    </doc>
+
+    <role name="server" implement="MUST"/>
+    <role name="client" implement="MUST"/>
+
+    <domain name="error-code" type="uint16">
+      <enum>
+        <choice name="unauthorized-access" value="403">
+          <doc>
+            The client attempted to work with a server entity to which it has no access due to
+            security settings.
+          </doc>
+        </choice>
+
+        <choice name="not-found" value="404">
+          <doc>
+            The client attempted to work with a server entity that does not exist.
+          </doc>
+        </choice>
+
+        <choice name="resource-locked" value="405">
+          <doc>
+            The client attempted to work with a server entity to which it has no access because
+            another client is working with it.
+          </doc>
+        </choice>
+
+        <choice name="precondition-failed" value="406">
+          <doc>
+            The client requested a command that was not allowed because some precondition failed.
+          </doc>
+        </choice>
+
+        <choice name="resource-deleted" value="408">
+          <doc>
+            A server entity the client is working with has been deleted.
+          </doc>
+        </choice>
+
+        <choice name="illegal-state" value="409">
+          <doc>
+            The peer sent a command that is not permitted in the current state of the session.
+          </doc>
+        </choice>
+
+        <choice name="command-invalid" value="503">
+          <doc>
+            The command segments could not be decoded.
+          </doc>
+        </choice>
+
+        <choice name="resource-limit-exceeded" value="506">
+          <doc>
+            The client exceeded its resource allocation.
+          </doc>
+        </choice>
+
+        <choice name="not-allowed" value="530">
+          <doc>
+            The peer tried to use a command a manner that is inconsistent with the rules described
+            in the specification.
+          </doc>
+        </choice>
+
+        <choice name="illegal-argument" value="531">
+          <doc>
+            The command argument is malformed, i.e. it does not fall within the specified domain.
+            The illegal-argument exception can be raised on execution of any command which has
+            domain valued fields.
+          </doc>
+        </choice>
+
+        <choice name="not-implemented" value="540">
+          <doc>
+            The peer tried to use functionality that is not implemented in its partner.
+          </doc>
+        </choice>
+
+        <choice name="internal-error" value="541">
+          <doc>
+            The peer could not complete the command because of an internal error. The peer may
+            require intervention by an operator in order to resume normal operations.
+          </doc>
+        </choice>
+
+        <choice name="invalid-argument" value="542">
+          <doc>
+            An invalid argument was passed to a command, and the operation could not
+            proceed.  An invalid argument is not illegal (see illegal-argument), i.e. it matches
+            the domain definition; however the particular value is invalid in this context.
+          </doc>
+        </choice>
+      </enum>
+    </domain>
+
+    <!-- - Command: execution.sync - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <command name="sync" code="0xb" label="request notification of completion for issued commands">
+      <doc>
+        This command is complete when all prior commands are completed.
+      </doc>
+
+      <implement role="server" handle="MUST"/>
+      <implement role="client" handle="MUST"/>
+    </command>
+
+    <!-- - Command: execution.result - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+    <command name="result" code="0xc" label="carries execution results">
+      <doc>
+        This command carries data resulting from the execution of a command.
+      </doc>
+
+      <implement role="server" handle="MUST"/>
+      <implement role="client" handle="MUST"/>
+
+      <field name="command-id" type="sequence-no" required="true"/>
+      <field name="value" type="struct32"/>
+    </command>
+
+  </class>
+
+  <!-- == Class: message ======================================================================= -->
+
+  <class name="message" code="0x4" label="message transfer">
+    <doc>
+      The message class provides commands that support an industry-standard messaging model.
+    </doc>
+
+    <doc type="picture" title="Transfer States">
+      START:
+
+        The message has yet to be sent to the recipient.
+
+      NOT-ACQUIRED:
+
+        The message has been sent to the recipient, but is not
+        acquired by the recipient.
+
+      ACQUIRED:
+
+        The message has been sent to and acquired by the recipient.
+
+      END:
+
+        The transfer is complete.
+    </doc>
+
+    <doc type="picture" title="State Transitions"><![CDATA[
+     *:TRANSFER (accept-mode=none)         *:TRANSFER (acquire-mode=pre-acquired)
+  +---------------------------------START------------------------------------------+
+  |                                   |                                            |
+  |                                   | *:TRANSFER (acquire-mode=not-acquired)     |
+  |                                   |                                            |
+  |                  R:RELEASE       \|/                                           |
+  |               +-------------NOT-ACQUIRED<--+                                   |
+  |               |               |      |     | R:ACQUIRE (if unavailable)        |
+  |               |               |      +-----+                                   |
+  |               |               |                                                |
+  |               |               | R:ACQUIRE (if available)                       |
+  |               |               |                                                |
+  |               |              \|/                                               |
+  |               |            ACQUIRED<-------------------------------------------+
+  |               |               |
+  |               |               | R:ACCEPT / R:REJECT / R:RELEASE
+  |               |               |
+  |               |              \|/
+  |               +------------->END
+  |                              /|\
+  |                               |
+  +-------------------------------+]]>
+    </doc>
+
+    <doc type="grammar">
+      message = *:TRANSFER [ R:ACQUIRE ] [ R:ACCEPT / R:REJECT / R:RELEASE ]
+              / *:RESUME
+              / *:SET-FLOW-MODE
+              / *:FLOW
+              / *:STOP
+              / C:SUBSCRIBE
+              / C:CANCEL
+              / C:FLUSH
+    </doc>
+
+    <rule name="persistent-message">
+      <doc>
+        The server SHOULD respect the delivery-mode property of messages and SHOULD make a
+        best-effort to hold persistent messages on a reliable storage mechanism.
+      </doc>
+      <doc type="scenario">
+        Send a persistent message to queue, stop server, restart server and then verify whether

[... 2785 lines stripped ...]


Mime
View raw message