summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRafael H. Schloming <rhs@apache.org>2008-08-21 02:59:53 +0000
committerRafael H. Schloming <rhs@apache.org>2008-08-21 02:59:53 +0000
commit07f401da1c757aa83305be0b94117581f29f82f3 (patch)
treed2fbbe893fa29bc8ab24c537907276a7801f0687
parentaed495cd26f6f3268ec13dbbec97825807ac164b (diff)
downloadqpid-python-07f401da1c757aa83305be0b94117581f29f82f3.tar.gz
added codegen for 1-0-draft xml
git-svn-id: https://svn.apache.org/repos/asf/incubator/qpid/branches/qpid.rnr@687540 13f79535-47bb-0310-9956-ffa450edef68
Diffstat
-rw-r--r--java/common/Composite.tpl11
-rw-r--r--java/common/Constant.tpl2
-rw-r--r--java/common/Enum.tpl2
-rw-r--r--java/common/Invoker.tpl7
-rw-r--r--java/common/MethodDelegate.tpl2
-rw-r--r--java/common/Option.tpl22
-rw-r--r--java/common/StructFactory.tpl4
-rw-r--r--java/common/Type.tpl2
-rw-r--r--java/common/build.xml28
-rwxr-xr-xjava/common/codegen20
-rw-r--r--java/common/src/main/java/org/apache/qpid/transport/Method.java17
-rw-r--r--java/common/src/main/java/org/apache/qpid/transport/SessionDelegate.java2
-rw-r--r--java/common/src/main/java/org/apache/qpid/transport/Struct.java2
-rw-r--r--java/common/src/main/java/org/apache/qpid/transport/network/Assembler.java2
-rw-r--r--java/common/src/main/java/org/apache/qpid/transport/network/Disassembler.java2
-rw-r--r--specs/amqp.1-0-draft.dtd246
-rw-r--r--specs/amqp.1-0-draft.xml5102
17 files changed, 5436 insertions, 37 deletions
diff --git a/java/common/Composite.tpl b/java/common/Composite.tpl
index 283fa24641..4aed9b0432 100644
--- a/java/common/Composite.tpl
+++ b/java/common/Composite.tpl
@@ -1,4 +1,4 @@
-package org.apache.qpid.transport;
+package $(pkg);
import java.nio.ByteBuffer;
import java.util.ArrayList;
@@ -7,6 +7,11 @@ import java.util.List;
import java.util.Map;
import java.util.UUID;
+import org.apache.qpid.transport.Future;
+import org.apache.qpid.transport.Method;
+import org.apache.qpid.transport.RangeSet;
+import org.apache.qpid.transport.Struct;
+
import org.apache.qpid.transport.codec.Decoder;
import org.apache.qpid.transport.codec.Encodable;
import org.apache.qpid.transport.codec.Encoder;
@@ -68,7 +73,7 @@ public final class $name extends $base {
return $pack;
}
- public final boolean hasPayload() {
+ public final boolean hasPayloadSegment() {
return $payload;
}
@@ -130,7 +135,7 @@ if options or base == "Method":
}
}
- public <C> void dispatch(C context, MethodDelegate<C> delegate) {
+ public final <C> void dispatch(C context, MethodDelegate<C> delegate) {
delegate.$(dromedary(name))(context, this);
}
diff --git a/java/common/Constant.tpl b/java/common/Constant.tpl
index 7194a61dfc..9f64cc657c 100644
--- a/java/common/Constant.tpl
+++ b/java/common/Constant.tpl
@@ -1,4 +1,4 @@
-package org.apache.qpid.transport;
+package $(pkg);
${from genutil import *}
diff --git a/java/common/Enum.tpl b/java/common/Enum.tpl
index 2ec1d22522..7ff451997a 100644
--- a/java/common/Enum.tpl
+++ b/java/common/Enum.tpl
@@ -1,4 +1,4 @@
-package org.apache.qpid.transport;
+package $(pkg);
public enum $name {
${
diff --git a/java/common/Invoker.tpl b/java/common/Invoker.tpl
index 9158922df7..43aaced780 100644
--- a/java/common/Invoker.tpl
+++ b/java/common/Invoker.tpl
@@ -1,10 +1,15 @@
-package org.apache.qpid.transport;
+package $(pkg);
import java.nio.ByteBuffer;
import java.util.List;
import java.util.Map;
import java.util.UUID;
+import org.apache.qpid.transport.Future;
+import org.apache.qpid.transport.Method;
+import org.apache.qpid.transport.RangeSet;
+import org.apache.qpid.transport.Struct;
+
public abstract class Invoker {
protected abstract void invoke(Method method);
diff --git a/java/common/MethodDelegate.tpl b/java/common/MethodDelegate.tpl
index 84fa0e43da..d2491dcf3a 100644
--- a/java/common/MethodDelegate.tpl
+++ b/java/common/MethodDelegate.tpl
@@ -1,4 +1,4 @@
-package org.apache.qpid.transport;
+package $(pkg);
public abstract class MethodDelegate<C> {
diff --git a/java/common/Option.tpl b/java/common/Option.tpl
index d45c004f6f..c1e8dcbe22 100644
--- a/java/common/Option.tpl
+++ b/java/common/Option.tpl
@@ -1,20 +1,24 @@
-package org.apache.qpid.transport;
+package $(pkg);
public enum Option {
${
from genutil import *
-options = {}
-
+names = ["NONE", "SYNC", "BATCH"]
for c in composites:
for f in c.query["field"]:
t = resolve_type(f)
if t["@name"] == "bit":
- option = scream(f["@name"])
- if not options.has_key(option):
- options[option] = None
- out(" $option,\n")}
- BATCH,
- NONE
+ names.append(scream(f["@name"]))
+
+options = {}
+
+for option in names:
+ if not options.has_key(option):
+ if options:
+ out(",\n ")
+ options[option] = None
+ out("$option")
+}
}
diff --git a/java/common/StructFactory.tpl b/java/common/StructFactory.tpl
index f3dcbbd68a..533005d561 100644
--- a/java/common/StructFactory.tpl
+++ b/java/common/StructFactory.tpl
@@ -1,4 +1,6 @@
-package org.apache.qpid.transport;
+package $(pkg);
+
+import org.apache.qpid.transport.Struct;
class StructFactory {
diff --git a/java/common/Type.tpl b/java/common/Type.tpl
index c58e08a342..818a53ffcf 100644
--- a/java/common/Type.tpl
+++ b/java/common/Type.tpl
@@ -1,4 +1,4 @@
-package org.apache.qpid.transport;
+package $(pkg);
${from genutil import *}
diff --git a/java/common/build.xml b/java/common/build.xml
index 6172a680ec..13c500b24e 100644
--- a/java/common/build.xml
+++ b/java/common/build.xml
@@ -30,7 +30,8 @@
<property name="xml.spec.list" value="${xml.spec.dir}/amqp.0-8.xml ${xml.spec.dir}/amqp.0-9.xml" />
<property name="mllib.dir" value="${project.root}/../python" />
<property name="gentools.timestamp" location="${generated.dir}/gentools.timestamp" />
- <property name="jython.timestamp" location="${generated.dir}/jython.timestamp" />
+ <property name="jython.timestamp" location="${module.precompiled}/jython.timestamp" />
+ <property name="jython_1_0.timestamp" location="${module.precompiled}/jython_1_0.timestamp" />
<target name="check_jython_deps">
<uptodate property="jython.notRequired" targetfile="${jython.timestamp}">
@@ -46,6 +47,7 @@
<arg value="${module.precompiled}"/>
<arg value="${xml.spec.dir}/amqp.0-10-qpid-errata.xml"/>
<arg value="${basedir}"/>
+ <arg value="org/apache/qpid/transport"/>
<classpath>
<pathelement location="jython-2.2-rc2.jar"/>
</classpath>
@@ -53,6 +55,28 @@
<touch file="${jython.timestamp}" />
</target>
+ <target name="check_jython_deps_1_0">
+ <uptodate property="jython.notRequired_1_0" targetfile="${jython_1_0.timestamp}">
+ <srcfiles dir="${xml.spec.dir}" includes="amqp.1-0-draft.xml" />
+ </uptodate>
+ </target>
+
+ <target name="jython_1_0" depends="check_jython_deps_1_0" unless="jython.notRequired_1_0">
+ <java classname="org.python.util.jython" fork="true" failonerror="true">
+ <arg value="-Dpython.cachedir.skip=true"/>
+ <arg value="-Dpython.path=${basedir}/jython-lib.jar/Lib${path.separator}${mllib.dir}"/>
+ <arg value="${basedir}/codegen"/>
+ <arg value="${module.precompiled}"/>
+ <arg value="${xml.spec.dir}/amqp.1-0-draft.xml"/>
+ <arg value="${basedir}"/>
+ <arg value="org/apache/qpid/transport/v1_0"/>
+ <classpath>
+ <pathelement location="jython-2.2-rc2.jar"/>
+ </classpath>
+ </java>
+ <touch file="${jython_1_0.timestamp}" />
+ </target>
+
<target name="compile_gentools">
<ant dir="${gentools.home}" />
</target>
@@ -103,6 +127,6 @@
</echo>
</target>
- <target name="precompile" depends="gentools,jython,version"/>
+ <target name="precompile" depends="gentools,jython,jython_1_0,version"/>
</project>
diff --git a/java/common/codegen b/java/common/codegen
index 6cd51565ea..07c5e5c6fb 100755
--- a/java/common/codegen
+++ b/java/common/codegen
@@ -7,7 +7,9 @@ from genutil import *
out_dir = sys.argv[1]
spec_file = sys.argv[2]
tpl_dir = sys.argv[3]
-pkg_dir = os.path.join(out_dir, "org/apache/qpid/transport")
+pkg_rel = sys.argv[4]
+pkg_dir = os.path.join(out_dir, pkg_rel)
+pkg = pkg_rel.replace("/", ".")
if not os.path.exists(pkg_dir):
os.makedirs(pkg_dir)
@@ -33,8 +35,8 @@ def execute(output, template, **kwargs):
f.write(p.output)
f.close()
-execute("Type.java", "Type.tpl", spec = spec)
-execute("Constant.java", "Constant.tpl", spec = spec)
+execute("Type.java", "Type.tpl", spec = spec, pkg = pkg)
+execute("Constant.java", "Constant.tpl", spec = spec, pkg = pkg)
structs = spec.query["amqp/struct"] + \
spec.query["amqp/class/struct", excludes] + \
@@ -46,12 +48,12 @@ composites = structs + controls + commands
for c in composites:
name = cname(c)
- execute("%s.java" % name, "Composite.tpl", type = c, name = name)
+ execute("%s.java" % name, "Composite.tpl", type = c, name = name, pkg = pkg)
-execute("MethodDelegate.java", "MethodDelegate.tpl", composites = composites)
-execute("Option.java", "Option.tpl", composites = composites)
-execute("Invoker.java", "Invoker.tpl", composites = controls + commands)
-execute("StructFactory.java", "StructFactory.tpl", composites = composites)
+execute("MethodDelegate.java", "MethodDelegate.tpl", composites = composites, pkg = pkg)
+execute("Option.java", "Option.tpl", composites = composites, pkg = pkg)
+execute("Invoker.java", "Invoker.tpl", composites = controls + commands, pkg = pkg)
+execute("StructFactory.java", "StructFactory.tpl", composites = composites, pkg = pkg)
def is_enum(nd):
return nd["enum"] is not None
@@ -61,4 +63,4 @@ enums = spec.query["amqp/domain", is_enum] + \
for e in enums:
name = cname(e)
- execute("%s.java" % name, "Enum.tpl", name = name, type = e)
+ execute("%s.java" % name, "Enum.tpl", name = name, type = e, pkg = pkg)
diff --git a/java/common/src/main/java/org/apache/qpid/transport/Method.java b/java/common/src/main/java/org/apache/qpid/transport/Method.java
index 6b99f6d5d3..37c347db98 100644
--- a/java/common/src/main/java/org/apache/qpid/transport/Method.java
+++ b/java/common/src/main/java/org/apache/qpid/transport/Method.java
@@ -75,7 +75,7 @@ public abstract class Method extends Struct implements ProtocolEvent
return sync;
}
- final void setSync(boolean value)
+ protected final void setSync(boolean value)
{
this.sync = value;
}
@@ -85,12 +85,12 @@ public abstract class Method extends Struct implements ProtocolEvent
return batch;
}
- final void setBatch(boolean value)
+ protected final void setBatch(boolean value)
{
this.batch = value;
}
- public abstract boolean hasPayload();
+ public abstract boolean hasPayloadSegment();
public Header getHeader()
{
@@ -114,7 +114,16 @@ public abstract class Method extends Struct implements ProtocolEvent
public abstract byte getEncodedTrack();
- public abstract <C> void dispatch(C context, MethodDelegate<C> delegate);
+ public <C> void dispatch(C context, MethodDelegate<C> delegate)
+ {
+ throw new UnsupportedOperationException();
+ }
+
+ public <C> void dispatch
+ (C context, org.apache.qpid.transport.v1_0.MethodDelegate<C> delegate)
+ {
+ throw new UnsupportedOperationException();
+ }
public <C> void delegate(C context, ProtocolDelegate<C> delegate)
{
diff --git a/java/common/src/main/java/org/apache/qpid/transport/SessionDelegate.java b/java/common/src/main/java/org/apache/qpid/transport/SessionDelegate.java
index b91763509c..5e4336f988 100644
--- a/java/common/src/main/java/org/apache/qpid/transport/SessionDelegate.java
+++ b/java/common/src/main/java/org/apache/qpid/transport/SessionDelegate.java
@@ -42,7 +42,7 @@ public abstract class SessionDelegate
public void command(Session ssn, Method method) {
ssn.identify(method);
method.dispatch(ssn, this);
- if (!method.hasPayload())
+ if (!method.hasPayloadSegment())
{
ssn.processed(method);
}
diff --git a/java/common/src/main/java/org/apache/qpid/transport/Struct.java b/java/common/src/main/java/org/apache/qpid/transport/Struct.java
index 22bd9f34ad..097a6de1b5 100644
--- a/java/common/src/main/java/org/apache/qpid/transport/Struct.java
+++ b/java/common/src/main/java/org/apache/qpid/transport/Struct.java
@@ -42,7 +42,7 @@ public abstract class Struct implements Encodable
return StructFactory.create(type);
}
- boolean dirty = true;
+ protected boolean dirty = true;
public boolean isDirty()
{
diff --git a/java/common/src/main/java/org/apache/qpid/transport/network/Assembler.java b/java/common/src/main/java/org/apache/qpid/transport/network/Assembler.java
index 33d552b91e..4ff8fec206 100644
--- a/java/common/src/main/java/org/apache/qpid/transport/network/Assembler.java
+++ b/java/common/src/main/java/org/apache/qpid/transport/network/Assembler.java
@@ -189,7 +189,7 @@ public class Assembler implements Receiver<NetworkEvent>, NetworkDelegate
dec.readUint16();
command = Method.create(commandType);
command.read(dec);
- if (command.hasPayload())
+ if (command.hasPayloadSegment())
{
incomplete[channel] = command;
}
diff --git a/java/common/src/main/java/org/apache/qpid/transport/network/Disassembler.java b/java/common/src/main/java/org/apache/qpid/transport/network/Disassembler.java
index bb7d2506e3..09586b357a 100644
--- a/java/common/src/main/java/org/apache/qpid/transport/network/Disassembler.java
+++ b/java/common/src/main/java/org/apache/qpid/transport/network/Disassembler.java
@@ -198,7 +198,7 @@ public final class Disassembler implements Sender<ProtocolEvent>,
byte flags = FIRST_SEG;
- boolean payload = method.hasPayload();
+ boolean payload = method.hasPayloadSegment();
if (!payload)
{
flags |= LAST_SEG;
diff --git a/specs/amqp.1-0-draft.dtd b/specs/amqp.1-0-draft.dtd
new file mode 100644
index 0000000000..2be198525a
--- /dev/null
+++ b/specs/amqp.1-0-draft.dtd
@@ -0,0 +1,246 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<!--
+ Copyright Notice
+ ================
+ (c) Copyright Cisco Systems, Credit Suisse, Deutsche Börse 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
+ =======
+ 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 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
+-->
+
+<!ELEMENT amqp (doc|type|struct|domain|constant|class)*>
+<!ATTLIST amqp
+ xmlns CDATA #IMPLIED
+ major CDATA #REQUIRED
+ minor CDATA #REQUIRED
+ port CDATA #REQUIRED
+ comment CDATA #IMPLIED
+>
+
+<!ELEMENT constant (doc|rule)*>
+<!ATTLIST constant
+ name CDATA #REQUIRED
+ value CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT type (doc|rule)*>
+<!ATTLIST type
+ name CDATA #REQUIRED
+ label CDATA #IMPLIED
+ code CDATA #IMPLIED
+ fixed-width CDATA #IMPLIED
+ variable-width CDATA #IMPLIED
+>
+
+<!ELEMENT domain (doc|rule|enum)*>
+<!ATTLIST domain
+ name CDATA #REQUIRED
+ type CDATA #IMPLIED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT struct (field|doc|rule)*>
+<!ATTLIST struct
+ name CDATA #REQUIRED
+ label CDATA #IMPLIED
+ size (0|1|2|4) #IMPLIED
+ pack (0|1|2|4) #IMPLIED
+ code CDATA #IMPLIED>
+
+<!ELEMENT enum (choice)*>
+
+<!ELEMENT choice (doc|rule)*>
+<!ATTLIST choice
+ name CDATA #REQUIRED
+ value CDATA #REQUIRED
+>
+
+<!ELEMENT class (doc|role|rule|struct|domain|control|command)*>
+<!ATTLIST class
+ name CDATA #REQUIRED
+ code CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT role (doc|rule)*>
+<!ATTLIST role
+ name CDATA #REQUIRED
+ implement (MAY|SHOULD|MUST) #REQUIRED
+>
+
+<!ELEMENT control (doc|implement|rule|field|response)*>
+<!ATTLIST control
+ name CDATA #REQUIRED
+ code CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT command ((doc|implement|rule|exception|field|response)*, result?, segments?)>
+<!ATTLIST command
+ name CDATA #REQUIRED
+ code CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT implement (doc|rule)*>
+<!ATTLIST implement
+ role CDATA #REQUIRED
+ handle (MAY|SHOULD|MUST) #REQUIRED
+ send (MAY|SHOULD|MUST) #IMPLIED
+>
+
+<!ELEMENT field (doc|rule|exception)*>
+<!ATTLIST field
+ name CDATA #REQUIRED
+ type CDATA #IMPLIED
+ default CDATA #IMPLIED
+ code CDATA #IMPLIED
+ label CDATA #IMPLIED
+ required CDATA #IMPLIED
+>
+
+<!ELEMENT rule (doc*)>
+<!ATTLIST rule
+ name CDATA #REQUIRED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT exception (doc*)>
+<!ATTLIST exception
+ name CDATA #REQUIRED
+ error-code CDATA #IMPLIED
+ label CDATA #IMPLIED
+>
+
+<!ELEMENT response (doc|rule)*>
+<!ATTLIST response
+ name CDATA #IMPLIED
+>
+
+<!ELEMENT result (doc|rule|struct)*>
+<!ATTLIST result
+ type CDATA #IMPLIED
+>
+
+<!ELEMENT segments (doc|rule|header|body)*>
+
+<!ELEMENT header (doc|rule|entry)*>
+<!ATTLIST header
+ required (true|false) #IMPLIED
+>
+
+<!ELEMENT entry (doc|rule)*>
+<!ATTLIST entry
+ type CDATA #REQUIRED
+>
+
+<!ELEMENT body (doc|rule)*>
+<!ATTLIST body
+ required (true|false) #IMPLIED
+>
+
+<!ELEMENT doc (#PCDATA|xref)*>
+<!ATTLIST doc
+ type (grammar|scenario|picture|bnf|todo) #IMPLIED
+ title CDATA #IMPLIED
+>
+
+<!ELEMENT xref (#PCDATA)>
+<!ATTLIST xref
+ ref CDATA #REQUIRED>
diff --git a/specs/amqp.1-0-draft.xml b/specs/amqp.1-0-draft.xml
new file mode 100644
index 0000000000..cdca7da05b
--- /dev/null
+++ b/specs/amqp.1-0-draft.xml
@@ -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
+ message is still present. Assumes that queues are durable. Persistence without durable
+ queues makes no sense.
+ </doc>
+ </rule>
+
+ <rule name="no-persistent-message-discard">
+ <doc>
+ The server MUST NOT discard a persistent message in case of a queue overflow.
+ </doc>
+ <doc type="scenario">
+ Create a queue overflow situation with persistent messages and verify that messages do not
+ get lost (presumably the server will write them to disk).
+ </doc>
+ </rule>
+
+ <rule name="throttling">
+ <doc>
+ The server MAY use the message.flow command to slow or stop a message publisher when
+ necessary.
+ </doc>
+ </rule>
+
+ <rule name="non-persistent-message-overflow">
+ <doc>
+ The server MAY overflow non-persistent messages to persistent storage.
+ </doc>
+ </rule>
+
+ <rule name="non-persistent-message-discard">
+ <doc>
+ The server MAY discard or dead-letter non-persistent messages on a priority basis if the
+ queue size exceeds some configured limit.
+ </doc>
+ </rule>
+
+ <rule name="min-priority-levels">
+ <doc>
+ The server MUST implement at least 2 priority levels for messages, where priorities 0 and
+ 9 are treated as two distinct levels.
+ </doc>
+ </rule>
+
+ <rule name="priority-level-implementation">
+ <doc>
+ The server SHOULD implement distinct priority levels in the following manner:
+ </doc>
+ <doc>
+ If the server implements n distinct priorities then priorities 0 to 5 - ceiling(n/2) should
+ be treated equivalently and should be the lowest effective priority. The priorities 4 +
+ floor(n/2) should be treated equivalently and should be the highest effective priority. The
+ priorities (5 - ceiling(n/2)) to (4 + floor(n/2)) inclusive must be treated as distinct
+ priorities.
+ </doc>
+ <doc>
+ Thus, for example, if 2 distinct priorities are implemented, then levels 0 to 4 are
+ equivalent, and levels 5 to 9 are equivalent and levels 4 and 5 are distinct. If 3 distinct
+ priorities are implements the 0 to 3 are equivalent, 5 to 9 are equivalent and 3, 4 and 5
+ are distinct.
+ </doc>
+ <doc>
+ This scheme ensures that if two priorities are distinct for a server which implements m
+ separate priority levels they are also distinct for a server which implements n different
+ priority levels where n > m.
+ </doc>
+ </rule>
+
+ <rule name="priority-delivery">
+ <doc>
+ The server MUST deliver messages of the same priority in order irrespective of their
+ individual persistence.
+ </doc>
+ <doc type="scenario">
+ Send a set of messages with the same priority but different persistence settings to a queue.
+ Subscribe and verify that messages arrive in same order as originally published.
+ </doc>
+ </rule>
+
+ <role name="server" implement="MUST" />
+ <role name="client" implement="MUST" />
+
+ <domain name="message-id" type="uuid" label="globally unique message id"/>
+
+ <domain name="accept-mode" type="uint8" label="indicates a confirmation mode">
+ <doc>
+ Controls how the sender of messages is notified of successful transfer.
+ </doc>
+
+ <enum>
+ <choice name="explicit" value="0">
+ <doc>
+ Successful transfer is signaled by message.accept. An acquired message (whether
+ acquisition was implicit as in pre-acquired mode or explicit as in not-acquired mode) is
+ not considered transferred until a message.accept that includes the transfer command is
+ received.
+ </doc>
+ </choice>
+
+ <choice name="none" value="1">
+ <doc>
+ Successful transfer is assumed when accept-mode is "pre-acquired". Messages transferred
+ with an accept-mode of "not-acquired" cannot be acquired when accept-mode is "none".
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+ <domain name="acquire-mode" type="uint8" 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.
+ </doc>
+
+ <enum>
+ <choice name="pre-acquired" value="0">
+ <doc>
+ the message is acquired when the transfer starts
+ </doc>
+ </choice>
+
+ <choice name="not-acquired" value="1">
+ <doc>
+ the message is not acquired when it arrives, and must be explicitly acquired by the
+ recipient
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+ <domain name="reject-code" type="uint16" label="reject code for transfer">
+ <doc>
+ Code specifying the reason for a message reject.
+ </doc>
+ <enum>
+ <choice name="unspecified" value="0">
+ <doc>
+ Rejected for an unspecified reason.
+ </doc>
+ </choice>
+ <choice name="unroutable" value="1">
+ <doc>
+ Delivery was attempted but there were no queues which the message could be routed to.
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+<!--
+ <domain name="resume-id" type="str16">
+ <doc>
+ A resume-id serves to identify partially transferred message content. The id is chosen by
+ the sender, and must be unique to a given user. A resume-id is not expected to be unique
+ across users.
+ </doc>
+ </domain>
+-->
+
+ <domain name="delivery-mode" type="uint8"
+ label="indicates whether a message should be treated as transient or durable">
+ <doc>
+
+ Used to set the reliability requirements for a message which is transferred to the server.
+ </doc>
+ <enum>
+ <choice name="non-persistent" value="1">
+ <doc>
+ 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>
+ </choice>
+
+ <choice name="persistent" value="2">
+ <doc>
+ 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 of 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.
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+ <domain name="delivery-priority" type="uint8"
+ label="indicates the desired priority to assign to a message transfer">
+ <doc>
+ Used to assign a priority to a message transfer. Priorities range from 0 (lowest) to 9
+ (highest).
+ </doc>
+ <enum>
+ <choice name="lowest" value="0">
+ <doc>
+ Lowest possible priority message.
+ </doc>
+ </choice>
+
+ <choice name="lower" value="1">
+ <doc>
+ Very low priority message
+ </doc>
+ </choice>
+
+ <choice name="low" value="2">
+ <doc>
+ Low priority message.
+ </doc>
+ </choice>
+
+ <choice name="below-average" value="3">
+ <doc>
+ Below average priority message.
+ </doc>
+ </choice>
+
+ <choice name="medium" value="4">
+ <doc>
+ Medium priority message.
+ </doc>
+ </choice>
+
+
+ <choice name="above-average" value="5">
+ <doc>
+ Above average priority message
+ </doc>
+ </choice>
+
+
+ <choice name="high" value="6">
+ <doc>
+ High priority message
+ </doc>
+ </choice>
+
+ <choice name="higher" value="7">
+ <doc>
+ Higher priority message
+ </doc>
+ </choice>
+
+ <choice name="very-high" value="8">
+ <doc>
+ Very high priority message.
+ </doc>
+ </choice>
+
+ <choice name="highest" value="9">
+ <doc>
+ Highest possible priority message.
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+ <struct name="delivery-properties" size="4" code="0x1" pack="2">
+ <field name="accept-mode" type="accept-mode" required="true">
+ <doc>
+ Indicates whether message.accept, session.complete, or nothing at all is required to
+ indicate successful transfer of the message.
+ </doc>
+ </field>
+
+ <field name="acquire-mode" type="acquire-mode" required="true">
+ <doc>
+ Indicates whether or not the transferred message has been acquired.
+ </doc>
+ </field>
+
+ <field name="discard-unroutable" type="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, an
+ unroutable message should be handled by reject when accept-mode is explicit; or by routing
+ to the alternate-exchange if defined when accept-mode is none.
+ </doc>
+ </field>
+
+ <field name="redelivered" type="bit" label="redelivery flag">
+ <doc>
+ This boolean flag indicates that the message may have been previously delivered to this
+ or another client.
+ </doc>
+ <doc>
+ If the redelivered flag is set on transfer to a Server, then any delivery of the message
+ from that Server to a Client must also have the redelivered flag set to true.
+ </doc>
+ <rule name="implementation">
+ <doc>
+ The server MUST try to signal redelivered messages when it can. When redelivering a
+ message that was not successfully accepted, 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. Subscribe using explicit
+ accept-mode, but do not accept the message. Close the session, reconnect, and subscribe
+ to the queue again. The message MUST arrive with the redelivered flag set.
+ </doc>
+ </rule>
+ <rule name="hinting">
+ <doc>
+ The client should not rely on the redelivered field to detect duplicate messages where
+ publishers may themselves produce duplicates. A fully robust client should be able to
+ track duplicate received messages on non-transacted, and locally-transacted sessions.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="priority" type="delivery-priority" label="message priority, 0 to 9"
+ required="true">
+ <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" type="delivery-mode" label="message persistence requirement"
+ required="true">
+ <doc> The delivery mode may be non-persistent or persistent. </doc>
+ </field>
+
+ <field name="ttl" type="uint64" label="time to live in ms">
+ <doc> Duration in milliseconds for which the message should be considered "live". If this is
+ set 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 subscriber the
+ ttl should be decremented before peer to peer transfer and both timestamp and expiration
+ should be cleared.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="timestamp" type="datetime" label="message timestamp">
+ <doc>
+ The timestamp is set by the broker on arrival of the message.
+ </doc>
+ </field>
+
+ <field name="expiration" type="datetime" 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 command and the current time.
+ (ttl=expiration - timestamp)
+ </doc>
+ </field>
+
+ <field name="exchange" type="exchange.name" label="originating exchange">
+ <doc>
+ Identifies the exchange specified in the destination field of the message.transfer used to
+ publish the message. This MUST be set by the broker upon receipt of a message.
+ </doc>
+ </field>
+
+ <field name="routing-key" type="str8" 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 a binding-key identical to the routing-key of
+ the message.
+ </doc>
+ </field>
+
+<!--
+ <field name="resume-id" type="resume-id" label="global id for message transfer">
+ <doc>
+ When a resume-id is provided the recipient MAY use it to retain message data should the
+ session expire while the message transfer is still incomplete.
+ </doc>
+ </field>
+-->
+
+ <field name="resume-ttl" type="uint64" label="ttl in ms for interrupted message data">
+ <doc>
+ When a resume-ttl is provided the recipient MAY use it has a guideline for how long to
+ retain the partially complete data.
+ </doc>
+ </field>
+ </struct>
+
+<!-- XXX
+ <struct name="reply-to" size="2" pack="2">
+ <doc>The reply-to domain provides a simple address structure for replying to to a message to a
+ destination within the same virtual-host.</doc>
+ <field name="exchange" type="exchange.name" label="the name of the exchange to reply to"/>
+ <field name="routing-key" type="str8" label="the routing-key to use when replying"/>
+ </struct>
+-->
+
+ <struct name="message-properties" size="4" code="0x3" pack="2">
+ <field name="content-length" type="uint64" label="length of the body segment in bytes">
+ <doc>
+ The length of the body segment in bytes.
+ </doc>
+ </field>
+
+ <field name="message-id" type="message-id" label="application message identifier">
+ <doc>
+ Message-id is an optional property of UUID type which uniquely identifies a message within
+ the message system. The message producer is usually responsible for setting the
+ message-id. The server MAY discard a message as a duplicate if the value of the message-id
+ matches that of a previously received message. Duplicate messages MUST still be accepted
+ if transferred with an accept-mode of "explicit".
+ </doc>
+
+ <rule name="unique">
+ <doc>
+ A message-id MUST be unique within a given server instance. A message-id 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>
+ </field>
+
+ <field name="correlation-id" type="vbin16" 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" type="route.address" 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" type="str8" 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" type="str8" 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-15.
+ </doc>
+ </field>
+
+ <field name="user-id" type="vbin16" label="creating user id">
+ <doc>
+ The identity of the user responsible for producing the message. The client sets this
+ value, and it is authenticated by the broker.
+ </doc>
+
+ <rule name="authentication">
+ <doc>
+ The server MUST produce an unauthorized-access exception if the user-id field is set to
+ a principle for which the client is not authenticated.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="app-id" type="vbin16" label="creating application id">
+ <doc>
+ The identity of the client application responsible for producing the message.
+ </doc>
+ </field>
+
+<!-- XXX: moved to top level headers map
+ <field name="application-headers" type="map" 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.
+ </doc>
+ </field>
+-->
+ </struct>
+
+ <!-- - Command: message.transfer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="transfer" code="0x1" label="transfer a message">
+ <doc>
+ This command transfers a message between two peers. When a client uses this command to
+ publish a message to a broker, the destination identifies a specific exchange. The message
+ will then be routed to queues as defined by the exchange configuration.
+
+ The client may request a broker to transfer messages to it, from a particular queue, by
+ issuing a subscribe command. The subscribe command specifies the destination that the broker
+ should use for any resulting transfers.
+ </doc>
+
+ <rule name="transactional-publish">
+ <doc>
+ If a transfer to an exchange occurs within a transaction, then it is not available from
+ the queue until the transaction commits. It is not specified whether routing takes place
+ when the transfer is received or when the transaction commits.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+ <implement role="client" handle="MUST" />
+
+
+ <field name="route" type="uint64" label="handle for message route">
+ <doc>
+ Specifies the destination to which the message is to be transferred.
+ </doc>
+
+ <rule name="blank-destination">
+ <doc>
+ The server MUST accept a blank destination to mean the default exchange.
+ </doc>
+ </rule>
+
+ <exception name="nonexistent-exchange" error-code="not-found">
+ <doc>
+ If the destination refers to an exchange that does not exist, the peer MUST raise a
+ session exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="more" type="bit" label="indicates that this message has more content"/>
+
+ <field name="fragment-offset" type="uint64" label="the offset of payload within the message"/>
+
+ <field name="headers" type="map" label="message headers">
+ <doc type="picture" title="Standard Entries">
+ "delivery-properties" -> delivery-properties
+ "message-properties" -> message-properties
+ "application-headers" -> map
+ </doc>
+ </field>
+
+ <field name="payload" type="vbin32" label="message data"/>
+ </command>
+
+ <!-- - Command: message.accept - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="accept" code="0x2" label="reject a message">
+ <doc>
+ Accepts the message. Once a transfer is accepted, the command-id may no longer be referenced
+ from other commands.
+ </doc>
+
+ <rule name="acquisition">
+ <doc>
+ The recipient MUST have acquired a message in order to accept it.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+ <implement role="client" handle="MUST" />
+
+ <field name="transfers" type="session.commands" required="true">
+ <doc>
+ Identifies the messages previously transferred that should be accepted.
+ </doc>
+ </field>
+ </command>
+
+ <!-- - Command: message.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="reject" code="0x3" label="reject a message">
+ <doc>
+ Indicates that the message transfers are unprocessable in some way. A server may reject a
+ message if it is unroutable. A client may reject a message if it is invalid. A message may
+ be rejected for other reasons as well. Once a transfer is rejected, the command-id may no
+ longer be referenced from other commands.
+ </doc>
+
+ <rule name="alternate-exchange">
+ <doc>
+ When a client rejects a message, the server MUST deliver that message to the
+ alternate-exchange on the queue from which it was delivered. If no alternate-exchange is
+ defined for that queue the broker MAY discard the message.
+ </doc>
+ </rule>
+
+ <rule name="acquisition">
+ <doc>
+ The recipient MUST have acquired a message in order to reject it. If the message is not
+ acquired any reject MUST be ignored.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+ <implement role="client" handle="MUST" />
+
+ <field name="transfers" type="session.commands" required="true">
+ <doc>
+ Identifies the messages previously transferred that should be rejected.
+ </doc>
+ </field>
+ <field name="code" type="reject-code" required="true">
+ <doc>
+ Code describing the reason for rejection.
+ </doc>
+ </field>
+ <field name="text" type="str8" label="informational text for message reject">
+ <doc>
+ Text describing the reason for rejection.
+ </doc>
+ </field>
+ </command>
+
+ <!-- - Command: message.release - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="release" code="0x4" label="release a message">
+ <doc>
+ Release previously transferred messages. When acquired messages are released, they become
+ available for acquisition by any subscriber. Once a transfer is released, the command-id may
+ no longer be referenced from other commands.
+ </doc>
+
+ <rule name="ordering">
+ <doc>
+ Acquired messages that have been released MAY subsequently be delivered out of order.
+ Implementations SHOULD ensure that released messages keep their position with respect to
+ undelivered messages of the same priority.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+ <implement role="client" handle="MAY" />
+
+ <field name="transfers" type="session.commands" required="true">
+ <doc>
+ Indicates the messages to be released.
+ </doc>
+ </field>
+ <field name="set-redelivered" type="bit" label="mark the released messages as redelivered">
+ <doc>
+ By setting set-redelivered to true, any acquired messages released to a queue with this
+ command will be marked as redelivered on their next transfer from that queue. If this flag
+ is not set, then an acquired message will retain its original redelivered status on the
+ queue. Messages that are not acquired are unaffected by the value of this flag.
+ </doc>
+ </field>
+ </command>
+
+ <!-- - Command: message.acquire - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="acquire" code="0x5" label="acquire messages for consumption">
+ <doc>
+ Acquires previously transferred messages for consumption. The acquired ids (if any) are
+ sent via message.acquired.
+ </doc>
+
+ <rule name="one-to-one">
+ <doc>
+ Each acquire MUST produce exactly one message.acquired even if it is empty.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="transfers" type="session.commands" required="true">
+ <doc>
+ Indicates the messages to be acquired.
+ </doc>
+ </field>
+
+ <result>
+ <struct name="acquired" size="4" code="0x4" pack="2" label="indicates acquired messages">
+ <doc>
+ Identifies a set of previously transferred messages that have now been acquired.
+ </doc>
+
+ <field name="transfers" type="session.commands" required="true">
+ <doc>
+ Indicates the acquired messages.
+ </doc>
+ </field>
+ </struct>
+ </result>
+ </command>
+
+ </class>
+
+ <!-- == Class: route ========================================================================= -->
+
+ <class name="route" code="0xff" label="flow control routes">
+
+ <role name="server" implement="MUST" />
+ <role name="client" implement="MUST" />
+
+ <domain name="address" type="str16" label="source or destination for a message">
+ <doc>
+ Specifies the source or destination to which the message is to be transferred to or from.
+ </doc>
+ </domain>
+
+ <domain name="flow-mode" type="uint8" label="the flow-mode for allocating flow credit">
+ <enum>
+ <choice name="credit" value="0">
+ <doc>
+ Credit based flow control.
+ </doc>
+ </choice>
+
+ <choice name="window" value="1">
+ <doc>
+ Window based flow control.
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+ <command name="open" code="0xfe" label="open a destination for transfer">
+ <implement role="server" handle="MUST" />
+
+ <field name="name" type="str8" label="the name of the route" required="true" />
+
+ <field name="address" type="address" required="true">
+ <exception name="destination-not-found" error-code="not-found">
+ <doc>If the destination does not exist, the recipient MUST close the session.</doc>
+ </exception>
+ </field>
+
+ <field name="durable" type="bit" label="indicates that the route is durable"/>
+
+ <field name="read" type="bit" label="requests that messages be sent from the address"/>
+
+ <field name="write" type="bit" label="indicates that messages will be sent to the address"/>
+
+ <field name="resume-id" type="message.message-id">
+ <doc>
+ If present, indicates that the sender can resume transfer of the given message-id.
+ </doc>
+ </field>
+ </command>
+
+ <command name="close" code="0xff" label="notify of destination closure">
+ <!-- XXX
+ <doc>
+ This command cancels a subscription. This does not affect already delivered messages, but
+ it does mean the server will not send any more messages for that subscription. The client
+ may receive an arbitrary number of messages in between sending the cancel command and
+ receiving notification that the cancel command is complete.
+ </doc>
+ -->
+
+ <field name="name" type="str8" required="true"/>
+ <field name="read" type="bit" label="close for read"/>
+ <field name="write" type="bit" label="close for write"/>
+ </command>
+
+ <!-- - Command: route.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="start" code="0x7" label="start a queue subscription">
+ <doc>
+ This command asks the server to start a "subscription", which is a request for messages from
+ a specific queue. Subscriptions last as long as the session they were created on, or until
+ the client cancels them.
+ </doc>
+
+ <rule name="simultaneous-subscriptions">
+ <doc>
+ The server SHOULD support at least 16 subscriptions per queue, and ideally, impose no
+ limit except as defined by available resources.
+ </doc>
+ <doc type="scenario">
+ Create a queue and create subscriptions on that queue until the server closes the
+ connection. Verify that the number of subscriptions created was at least sixteen and
+ report the total number.
+ </doc>
+ </rule>
+
+ <rule name="default-flow-mode">
+ <doc> The default flow mode for new subscriptions is window-mode. </doc>
+ </rule>
+
+ <exception name="queue-deletion" error-code="resource-deleted">
+ <doc>
+ If the queue for this subscription is deleted, any subscribing sessions MUST be closed.
+ This exception may occur at any time after the subscription has been completed.
+ </doc>
+ </exception>
+
+ <exception name="queue-not-found" error-code="not-found">
+ <doc>
+ If the queue for this subscription does not exist, then the subscribing session MUST be
+ closed.
+ </doc>
+ </exception>
+
+ <rule name="initial-credit">
+ <doc>
+ Immediately after a subscription is created, the initial byte and message credit for that
+ destination is zero.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST"/>
+
+<!-- XXX rolled into destination
+ <field name="queue" type="queue.name" required="true">
+ <doc>
+ Specifies the name of the subscribed queue.
+ </doc>
+ </field>
+-->
+
+ <field name="name" type="str8" label="the route name">
+ <doc> The client specified name for the subscription. This is used as the destination for
+ all messages transferred from this subscription. The destination is scoped to the session.
+ </doc>
+
+ <exception name="unique-subscriber-destination" error-code="not-allowed">
+ <doc>
+ The client MUST NOT specify a destination that refers to an existing subscription on the
+ same session.
+ </doc>
+ <doc type="scenario">
+ Attempt to create two subscriptions on the same session with the same non-empty
+ destination.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="handle" type="uint64" label="route handle"/>
+
+ <field name="accept-mode" type="message.accept-mode" required="true">
+ <doc>
+ The accept-mode to use for messages transferred from this subscription.
+ </doc>
+ </field>
+
+ <field name="acquire-mode" type="message.acquire-mode" required="true">
+ <doc>
+ The acquire-mode to use for messages transferred from this subscription.
+ </doc>
+ </field>
+
+ <field name="exclusive" type="bit" label="request exclusive access">
+ <doc>
+ Request an exclusive subscription. This prevents other subscribers from subscribing to the
+ queue.
+ </doc>
+
+ <exception name="in-use" error-code="resource-locked">
+ <doc>
+ The server MUST NOT grant an exclusive subscription to a queue that already has
+ subscribers.
+ </doc>
+ <doc type="scenario">
+ Open two connections to a server, and in one connection create a shared (non-exclusive)
+ queue and then subscribe to the queue. In the second connection attempt to subscribe to
+ the same queue using the exclusive option.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="resume-id" type="message.message-id">
+ <doc>
+ Requests that the sender resume the given message-id if it is still available.
+ </doc>
+ </field>
+
+ <field name="resume-offset" type="uint64">
+ <doc>
+ Indicates the amount of data already transferred.
+ </doc>
+ </field>
+
+ <field name="flow-mode" type="flow-mode" label="set the flow control mode" required="true">
+ <doc>
+ The new flow control mode.
+ </doc>
+
+ <doc>
+ Sets the mode of flow control used for a given destination to either window or credit
+ based flow control.
+
+ With credit based flow control, the sender of messages continually maintains its current
+ credit balance with the recipient. The credit balance consists of two values, a message
+ count, and a byte count. Whenever message data is sent, both counts must be decremented.
+ If either value reaches zero, the flow of message data must stop. Additional credit is
+ received via the message.flow command.
+
+ The sender MUST NOT send partial commands. This means that if there is not enough byte
+ credit available to send a complete command, the sender must either wait or use message
+ fragmentation (multiple message.transfer commands) to send the first part of the message
+ data in a complete command.
+
+ Window based flow control is identical to credit based flow control, however message
+ transfer completion implicitly grants a single unit of message credit, and the size of the
+ message in byte credits for each completed message transfer. Completion of the transfer
+ command with session.completed is the only way credit is implicitly updated;
+ message.accept, message.release, message.reject, tx.commit and tx.rollback have no effect
+ on the outstanding credit balances.
+ </doc>
+
+ <rule name="byte-accounting">
+ <doc>
+ The byte count is decremented by the payload size of each transmitted frame with segment
+ type header or body appearing within a message.transfer command. Note that the payload
+ size is the frame size less the frame header size.
+ </doc>
+ </rule>
+
+ <rule name="mode-switching">
+ <doc>
+ Mode switching may only occur if both the byte and message credit balance are zero.
+ There are three ways for a recipient of messages to be sure that the sender's credit
+ balances are zero:
+
+ 1) The recipient may send a message.stop command to the sender. When the recipient
+ receives notification of completion for the message.stop command, it knows that the
+ sender's credit is zero.
+
+ 2) The recipient may perform the same steps described in (1) with the message.fetch
+ command substituted for the message.stop command.
+
+ 3) Immediately after a subscription is created with message.subscribe, the credit for
+ that destination is zero.
+ </doc>
+ </rule>
+
+ <rule name="default-flow-mode">
+ <doc>
+ Prior to receiving an explicit set-flow-mode command, a peer MUST consider the flow-mode
+ to be window.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="initial-message-credit" type="uint32">
+ <doc>
+ If the value is not set then this indicates an infinite amount of credit.
+ </doc>
+ </field>
+
+ <field name="initial-byte-credit" type="uint32">
+ <doc>
+ If the value is not set then this indicates an infinite amount of credit.
+ </doc>
+ </field>
+
+ <field name="arguments" type="map" label="arguments for vendor extensions">
+ <doc>
+ The syntax and semantics of these arguments depends on the providers implementation.
+ </doc>
+ </field>
+ </command>
+
+ <!-- - Command: route.stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="stop" code="0x8" label="stop the sending of messages">
+ <doc>
+ On receipt of this command, a producer of messages MUST set his credit to zero for the
+ given destination. When notifying of completion, credit MUST be zero and no further
+ messages will be sent until such a time as further credit is received.
+ </doc>
+
+ <rule name="post-cancel-transfer-resolution">
+ <doc>
+ Canceling a subscription MUST NOT affect pending transfers. A transfer made prior to
+ canceling transfers to the destination MUST be able to be accepted, released, acquired, or
+ rejected after the subscription is canceled.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="handle" type="uint64" required="true">
+ <exception name="subscription-not-found" error-code="not-found">
+ <doc>
+ If the subscription specified by the destination is not found, the server MUST close the
+ session.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: route.flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="flow" code="0xa" label="control message flow">
+ <doc>
+ This command controls the flow of message data to a given destination. It is used by the
+ recipient of messages to dynamically match the incoming rate of message flow to its
+ processing or forwarding capacity. Upon receipt of this command, the sender must add "value"
+ number of the specified messages and bytes to the available credit balances for the
+ specified destination. If a value is unset it indicates an infinite amount of credit. This
+ disables any limit for the given unit until the credit balance is zeroed with message.stop
+ or message.fetch.
+ </doc>
+
+ <!-- throws no-such-destination -->
+
+ <implement role="server" handle="MUST" />
+ <implement role="client" handle="MUST" />
+
+ <field name="destination" type="uint64"/>
+ <field name="messages" type="uint32">
+ <doc>
+ If the value is not set then this indicates an infinite amount of credit.
+ </doc>
+ </field>
+ <field name="bytes" type="uint32">
+ <doc>
+ If the value is not set then this indicates an infinite amount of credit.
+ </doc>
+ </field>
+ </command>
+
+ <!-- - Command: route.fetch - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="fetch" code="0xb" label="force the sending of available messages">
+ <doc>
+ Forces the sender to exhaust his credit supply. The sender's credit will always be zero when
+ this command completes. The command completes when immediately available message data has
+ been transferred, or when the credit supply is exhausted.
+ </doc>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="destination" type="uint64"/>
+ </command>
+
+ </class>
+
+ <!-- == Class: tx ============================================================================ -->
+
+ <class name="tx" code="0x5" label="work with standard transactions">
+ <doc>
+ Standard transactions provide so-called "1.5 phase commit". We can ensure that work is never
+ lost, but there is a chance of confirmations being lost, so that messages may be resent.
+ Applications that use standard transactions must be able to detect and ignore duplicate
+ messages.
+ </doc>
+
+ <doc type="grammar">
+ tx = C:SELECT
+ / C:COMMIT
+ / C:ROLLBACK
+ </doc>
+
+ <!-- XXX: this isn't really a rule, as stated there is no way for
+ a client library to implement this -->
+ <rule name="duplicate-tracking">
+ <doc>
+ An client using standard transactions SHOULD be able to track all messages received within a
+ reasonable period, and thus detect and reject duplicates of the same message. It SHOULD NOT
+ pass these to the application layer.
+ </doc>
+ </rule>
+
+ <role name="server" implement="SHOULD" />
+
+ <!-- - Command: tx.select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="select" code="0x1" label="select standard transaction mode">
+ <doc>
+ This command sets the session to use standard transactions. The client must use this command
+ exactly once on a session before using the Commit or Rollback commands.
+ </doc>
+
+ <exception name="exactly-once" error-code="illegal-state">
+ <doc>
+ A client MUST NOT select standard transactions on a session that is already transactional.
+ </doc>
+ </exception>
+
+ <exception name="no-dtx" error-code="illegal-state">
+ <doc>
+ A client MUST NOT select standard transactions on a session that is already enlisted in a
+ distributed transaction.
+ </doc>
+ </exception>
+
+ <exception name="explicit-accepts" error-code="not-allowed">
+ <doc>
+ On a session on which tx.select has been issued, a client MUST NOT issue a
+ message.subscribe command with the accept-mode property set to any value other than
+ explicit. Similarly a tx.select MUST NOT be issued on a session on which a there is a non
+ cancelled subscriber with accept-mode of none.
+ </doc>
+ </exception>
+
+ <implement role="server" handle="MUST" />
+ </command>
+
+ <!-- - Command: tx.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="commit" code="0x2" label="commit the current transaction">
+ <doc>
+ This command commits all messages published and accepted in the current transaction. A
+ new transaction starts immediately after a commit.
+ </doc>
+ <doc>
+ In more detail, the commit acts on all messages which have been transferred from the Client
+ to the Server, and on all acceptances of messages sent from Server to Client. Since the
+ commit acts on commands sent in the same direction as the commit command itself, there is no
+ ambiguity on the scope of the commands being committed. Further, the commit will not be
+ completed until all preceding commands which it affects have been completed.
+ </doc>
+ <doc>
+ Since transactions act on explicit accept commands, the only valid accept-mode for message
+ subscribers is explicit. For transferring messages from Client to Server (publishing) all
+ accept-modes are permitted.
+ </doc>
+
+ <exception name="select-required" error-code="illegal-state">
+ <doc>
+ A client MUST NOT issue tx.commit on a session that has not been selected for standard
+ transactions with tx.select.
+ </doc>
+ </exception>
+
+
+
+ <implement role="server" handle="MUST" />
+ </command>
+
+ <!-- - Command: tx.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="rollback" code="0x3" label="abandon the current transaction">
+ <doc>
+ This command abandons the current transaction. In particular the transfers from Client to
+ Server (publishes) and accepts of transfers from Server to Client which occurred in the
+ current transaction are discarded. A new transaction starts immediately after a rollback.
+ </doc>
+ <doc>
+ In more detail, when a rollback is issued, any the effects of transfers which occurred from
+ Client to Server are discarded. The Server will issue completion notification for all such
+ transfers prior to the completion of the rollback. Similarly the effects of any
+ message.accept issued from Client to Server prior to the issuance of the tx.rollback will be
+ discarded; and notification of completion for all such commands will be issued before the
+ issuance of the completion for the rollback.
+ </doc>
+ <doc>
+ After the completion of the rollback, the client will still hold the messages which it has
+ not yet accepted (including those for which accepts were previously issued within the
+ transaction); i.e. the messages remain "acquired". If the Client wishes to release those
+ messages back to the Server, then appropriate message.release commands must be issued.
+ </doc>
+
+ <exception name="select-required" error-code="illegal-state">
+ <doc>
+ A client MUST NOT issue tx.rollback on a session that has not been selected for standard
+ transactions with tx.select.
+ </doc>
+ </exception>
+
+ <implement role="server" handle="MUST" />
+ </command>
+
+ </class>
+
+ <!-- == Class: dtx =========================================================================== -->
+
+ <class name="dtx" code="0x6" label="Demarcates dtx branches">
+ <doc>
+ This provides the X-Open XA distributed transaction protocol support. It allows a session
+ to be selected for use with distributed transactions, the transactional boundaries for work on
+ that session to be demarcated and allows the transaction manager to coordinate transaction
+ outcomes.
+ </doc>
+
+ <doc type="grammar">
+ dtx-demarcation = C:SELECT *demarcation
+ demarcation = C:START C:END
+ </doc>
+
+ <doc type="grammar">
+ dtx-coordination = *coordination
+ coordination = command
+ / outcome
+ / recovery
+ command = C:SET-TIMEOUT
+ / C:GET-TIMEOUT
+ outcome = one-phase-commit
+ / one-phase-rollback
+ / two-phase-commit
+ / two-phase-rollback
+ one-phase-commit = C:COMMIT
+ one-phase-rollback = C:ROLLBACK
+ two-phase-commit = C:PREPARE C:COMMIT
+ two-phase-rollback = C:PREPARE C:ROLLBACK
+ recovery = C:RECOVER *recovery-outcome
+ recovery-outcome = one-phase-commit
+ / one-phase-rollback
+ / C:FORGET
+
+ </doc>
+
+ <rule name="transactionality">
+ <doc>
+ Enabling XA transaction support on a session requires that the server MUST manage
+ transactions demarcated by start-end blocks. That is to say that on this XA-enabled session,
+ work undergone within transactional blocks is performed on behalf a transaction branch
+ whereas work performed outside of transactional blocks is NOT transactional.
+ </doc>
+ </rule>
+
+ <role name="server" implement="MAY" />
+ <role name="client" implement="MAY" />
+
+ <!-- XA domains -->
+
+ <domain name="xa-status" type="uint16" label="XA return codes">
+ <enum>
+ <choice name="xa-ok" value="0">
+ <doc>
+ Normal execution completion (no error).
+ </doc>
+ </choice>
+
+ <choice name="xa-rbrollback" value="1">
+ <doc>
+ The rollback was caused for an unspecified reason.
+ </doc>
+ </choice>
+
+ <choice name="xa-rbtimeout" value="2">
+ <doc>
+ A transaction branch took too long.
+ </doc>
+ </choice>
+
+ <choice name="xa-heurhaz" value="3">
+ <doc>
+ The transaction branch may have been heuristically completed.
+ </doc>
+ </choice>
+
+ <choice name="xa-heurcom" value="4">
+ <doc>
+ The transaction branch has been heuristically committed.
+ </doc>
+ </choice>
+
+ <choice name="xa-heurrb" value="5">
+ <doc>
+ The transaction branch has been heuristically rolled back.
+ </doc>
+ </choice>
+
+ <choice name="xa-heurmix" value="6">
+ <doc>
+ The transaction branch has been heuristically committed and rolled back.
+ </doc>
+ </choice>
+
+ <choice name="xa-rdonly" value="7">
+ <doc>
+ The transaction branch was read-only and has been committed.
+ </doc>
+ </choice>
+ </enum>
+ </domain>
+
+ <struct name="xa-result" size="4" code="0x1" pack="2">
+ <field name="status" type="xa-status" required="true"/>
+ </struct>
+
+ <!-- Struct for xid -->
+
+ <struct name="xid" size="2" pack="2" label="dtx branch identifier">
+ <doc>
+ An xid uniquely identifies a transaction branch.
+ </doc>
+
+ <field name="format" type="uint32" label="implementation specific format code"
+ required="true"/>
+ <field name="global-id" type="vbin8" label="global transaction id" required="true"/>
+ <field name="branch-id" type="vbin8" label="branch qualifier" required="true"/>
+ </struct>
+
+ <!-- - Command: dtx.select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="select" code="0x1" label="Select dtx mode">
+ <doc>
+ This command sets the session to use distributed transactions. The client must use this
+ command at least once on a session before using XA demarcation operations.
+ </doc>
+
+ <implement role="server" handle="MAY" />
+ </command>
+
+ <!-- - Command: dtx.start - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="start" code="0x2" label="Start a dtx branch">
+ <doc>
+ This command is called when messages should be produced and consumed on behalf a transaction
+ branch identified by xid.
+ </doc>
+
+ <exception name="illegal-state" error-code="illegal-state">
+ <doc>
+ If the command is invoked in an improper context (see class grammar) then the server MUST
+ send a session exception.
+ </doc>
+ </exception>
+
+ <exception name="already-known" error-code="not-allowed">
+ <doc>
+ If neither join nor resume is specified is specified and the transaction branch specified
+ by xid has previously been seen then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="join-and-resume" error-code="not-allowed">
+ <doc>
+ If join and resume are specified then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch to be started.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-allowed">
+ <doc>
+ If xid is already known by the broker then the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="join" type="bit" label="Join with existing xid flag">
+ <doc>
+ Indicate whether this is joining an already associated xid. Indicate that the start
+ applies to joining a transaction previously seen.
+ </doc>
+
+ <exception name="unsupported" error-code="not-implemented">
+ <doc>
+ If the broker does not support join the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="resume" type="bit" label="Resume flag">
+ <doc>
+ Indicate that the start applies to resuming a suspended transaction branch specified.
+ </doc>
+ </field>
+
+ <result type="xa-result">
+ <doc>
+ This confirms to the client that the transaction branch is started or specify the error
+ condition.
+
+ The value of this field may be one of the following constants:
+
+ xa-ok: Normal execution.
+
+ xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
+ reason.
+
+ xa-rbtimeout: The work represented by this transaction branch took too long.
+ </doc>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="end" code="0x3" label="End a dtx branch">
+ <doc>
+ This command is called when the work done on behalf a transaction branch finishes or needs
+ to be suspended.
+ </doc>
+
+ <exception name="illegal-state" error-code="illegal-state">
+ <doc>
+ If the command is invoked in an improper context (see class grammar) then the server MUST
+ raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="suspend-and-fail" error-code="not-allowed">
+ <doc>
+ If suspend and fail are specified then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <rule name="success">
+ <doc>
+ If neither fail nor suspend are specified then the portion of work has completed
+ successfully.
+ </doc>
+ </rule>
+
+ <rule name="session-closed">
+ <doc>
+ When a session is closed then the currently associated transaction branches MUST be marked
+ rollback-only.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch to be ended.
+ </doc>
+
+ <exception name="not-associated" error-code="illegal-state">
+ <doc>
+ The session MUST be currently associated with the given xid (through an earlier start
+ call with the same xid).
+ </doc>
+ </exception>
+ </field>
+
+ <field name="fail" type="bit" label="Failure flag">
+ <doc>
+ If set, indicates that this portion of work has failed; otherwise this portion of work has
+ completed successfully.
+ </doc>
+
+ <rule name="failure">
+ <doc>
+ An implementation MAY elect to roll a transaction back if this failure notification is
+ received. Should an implementation elect to implement this behavior, and this bit is
+ set, then then the transaction branch SHOULD be marked as rollback-only and the end
+ result SHOULD have the xa-rbrollback status set.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="suspend" type="bit" label="Temporary suspension flag">
+ <doc>
+ Indicates that the transaction branch is temporarily suspended in an incomplete state.
+ </doc>
+
+ <rule name="resume">
+ <doc>
+ The transaction context is in a suspended state and must be resumed via the start
+ command with resume specified.
+ </doc>
+ </rule>
+
+ </field>
+
+ <result type="xa-result">
+ <doc>
+ This command confirms to the client that the transaction branch is ended or specify the
+ error condition.
+
+ The value of this field may be one of the following constants:
+
+ xa-ok: Normal execution.
+
+ xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
+ reason. If an implementation chooses to implement rollback-on-failure behavior, then
+ this value should be selected if the dtx.end.fail bit was set.
+
+ xa-rbtimeout: The work represented by this transaction branch took too long.
+ </doc>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="commit" code="0x4" label="Commit work on dtx branch">
+ <doc>
+ Commit the work done on behalf a transaction branch. This command commits the work
+ associated with xid. Any produced messages are made available and any consumed messages are
+ discarded.
+ </doc>
+
+ <exception name="illegal-state" error-code="illegal-state">
+ <doc>
+ If the command is invoked in an improper context (see class grammar) then the server MUST
+ raise an exception.
+ </doc>
+ </exception>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch to be committed.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-found">
+ <doc>
+ If xid is unknown (the transaction branch has not been started or has already been
+ ended) then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="not-disassociated" error-code="illegal-state">
+ <doc>
+ If this command is called when xid is still associated with a session then the server
+ MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="one-phase" type="bit" label="One-phase optimization flag">
+ <doc>
+ Used to indicate whether one-phase or two-phase commit is used.
+ </doc>
+
+ <exception name="one-phase" error-code="illegal-state">
+ <doc>
+ The one-phase bit MUST be set if a commit is sent without a preceding prepare.
+ </doc>
+ </exception>
+
+ <exception name="two-phase" error-code="illegal-state">
+ <doc>
+ The one-phase bit MUST NOT be set if the commit has been preceded by prepare.
+ </doc>
+ </exception>
+ </field>
+
+ <result type="xa-result">
+ <doc>
+ This confirms to the client that the transaction branch is committed or specify the
+ error condition.
+
+ The value of this field may be one of the following constants:
+
+ xa-ok: Normal execution
+
+ xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction
+ branch may have been heuristically completed.
+
+ xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified
+ transaction branch was committed.
+
+ xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified
+ transaction branch was rolled back.
+
+ xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified
+ transaction branch was partially committed and partially rolled back.
+
+ xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
+ reason.
+
+ xa-rbtimeout: The work represented by this transaction branch took too long.
+ </doc>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.forget - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="forget" code="0x5" label="Discard dtx branch">
+ <doc>
+ This command is called to forget about a heuristically completed transaction branch.
+ </doc>
+
+ <exception name="illegal-state" error-code="illegal-state">
+ <doc>
+ If the command is invoked in an improper context (see class grammar) then the server MUST
+ raise an exception.
+ </doc>
+ </exception>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch to be forgotten.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-found">
+ <doc>
+ If xid is unknown (the transaction branch has not been started or has already been
+ ended) then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="not-disassociated" error-code="illegal-state">
+ <doc>
+ If this command is called when xid is still associated with a session then the server
+ MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: dtx.get-timeout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="get-timeout" code="0x6" label="Obtain dtx timeout in seconds">
+ <doc>
+ This command obtains the current transaction timeout value in seconds. If set-timeout was
+ not used prior to invoking this command, the return value is the default timeout; otherwise,
+ the value used in the previous set-timeout call is returned.
+ </doc>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch for getting the timeout.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-found">
+ <doc>
+ If xid is unknown (the transaction branch has not been started or has already been
+ ended) then the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <result>
+ <struct name="get-timeout-result" size="4" code="0x2" pack="2">
+ <doc> Returns the value of the timeout last specified through set-timeout. </doc>
+
+ <field name="timeout" type="uint32" label="The current transaction timeout value"
+ required="true">
+ <doc> The current transaction timeout value in seconds. </doc>
+ </field>
+ </struct>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.prepare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="prepare" code="0x7" label="Prepare a dtx branch">
+ <doc>
+ This command prepares for commitment any message produced or consumed on behalf of xid.
+ </doc>
+
+ <exception name="illegal-state" error-code="illegal-state">
+ <doc>
+ If the command is invoked in an improper context (see class grammar) then the server MUST
+ raise an exception.
+ </doc>
+ </exception>
+
+ <rule name="obligation-1">
+ <doc>
+ Once this command successfully returns it is guaranteed that the transaction branch may be
+ either committed or rolled back regardless of failures.
+ </doc>
+ </rule>
+
+ <rule name="obligation-2">
+ <doc>
+ The knowledge of xid cannot be erased before commit or rollback complete the branch.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch that can be prepared.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-found">
+ <doc>
+ If xid is unknown (the transaction branch has not been started or has already been
+ ended) then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="not-disassociated" error-code="illegal-state">
+ <doc>
+ If this command is called when xid is still associated with a session then the server
+ MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <result type="xa-result">
+ <doc>
+ This command confirms to the client that the transaction branch is prepared or specify the
+ error condition.
+
+ The value of this field may be one of the following constants:
+
+ xa-ok: Normal execution.
+
+ xa-rdonly: The transaction branch was read-only and has been committed.
+
+ xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
+ reason.
+
+ xa-rbtimeout: The work represented by this transaction branch took too long.
+ </doc>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.recover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="recover" code="0x8" label="Get prepared or completed xids">
+ <doc>
+ This command is called to obtain a list of transaction branches that are in a prepared or
+ heuristically completed state.
+ </doc>
+
+ <implement role="server" handle="MAY" />
+
+ <result>
+ <struct name="recover-result" size="4" code="0x3" pack="2">
+ <doc>
+ Returns to the client a table with single item that is a sequence of transaction xids
+ that are in a prepared or heuristically completed state.
+ </doc>
+
+ <field name="in-doubt" type="array" label="array of xids to be recovered" required="true">
+ <doc> Array containing the xids to be recovered (xids that are in a prepared or
+ heuristically completed state). </doc>
+
+ </field>
+ </struct>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="rollback" code="0x9" label="Rollback a dtx branch">
+ <doc>
+ This command rolls back the work associated with xid. Any produced messages are discarded
+ and any consumed messages are re-enqueued.
+ </doc>
+
+ <exception name="illegal-state" error-code="illegal-state">
+ <doc>
+ If the command is invoked in an improper context (see class grammar) then the server MUST
+ raise an exception.
+ </doc>
+ </exception>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch that can be rolled back.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-found">
+ <doc>
+ If xid is unknown (the transaction branch has not been started or has already been
+ ended) then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="not-disassociated" error-code="illegal-state">
+ <doc>
+ If this command is called when xid is still associated with a session then the server
+ MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <result type="xa-result">
+ <doc>
+ This command confirms to the client that the transaction branch is rolled back or specify
+ the error condition.
+
+ The value of this field may be one of the following constants:
+
+ xa-ok: Normal execution
+
+ xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction
+ branch may have been heuristically completed.
+
+ xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified
+ transaction branch was committed.
+
+ xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified
+ transaction branch was rolled back.
+
+ xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified
+ transaction branch was partially committed and partially rolled back.
+
+ xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified
+ reason.
+
+ xa-rbtimeout: The work represented by this transaction branch took too long.
+ </doc>
+ </result>
+ </command>
+
+ <!-- - Command: dtx.set-timeout - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="set-timeout" code="0xa" label="Set dtx timeout value">
+ <doc>
+ Sets the specified transaction branch timeout value in seconds.
+ </doc>
+
+ <rule name="effective">
+ <doc>
+ Once set, this timeout value is effective until this command is reinvoked with a different
+ value.
+ </doc>
+ </rule>
+
+ <rule name="reset">
+ <doc>
+ A value of zero resets the timeout value to the default value.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MAY" />
+
+ <field name="xid" type="xid" label="Transaction xid" required="true">
+ <doc>
+ Specifies the xid of the transaction branch for setting the timeout.
+ </doc>
+
+ <exception name="unknown-xid" error-code="not-found">
+ <doc>
+ If xid is unknown (the transaction branch has not been started or has already been
+ ended) then the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ </field>
+
+ <field name="timeout" type="uint32" label="Dtx timeout in seconds" required="true">
+ <doc>
+ The transaction timeout value in seconds.
+ </doc>
+ </field>
+ </command>
+
+ </class>
+
+ <!-- == Class: exchange ====================================================================== -->
+
+ <class name="exchange" code="0x7" label="work with exchanges">
+ <doc>
+ Exchanges match and distribute messages across queues. Exchanges can be configured in the
+ server or created at runtime.
+ </doc>
+
+ <doc type="grammar">
+ exchange = C:DECLARE
+ / C:DELETE
+ / C:QUERY
+ </doc>
+
+ <rule name="required-types">
+ <doc>
+ The server MUST implement these standard exchange types: fanout, direct.
+ </doc>
+ <doc type="scenario">
+ Client attempts to declare an exchange with each of these standard types.
+ </doc>
+ </rule>
+
+ <rule name="recommended-types">
+ <doc>
+ The server SHOULD implement these standard exchange types: topic, headers.
+ </doc>
+ <doc type="scenario">
+ Client attempts to declare an exchange with each of these standard types.
+ </doc>
+ </rule>
+
+ <rule name="required-instances">
+ <doc>
+ The server MUST, in each virtual host, pre-declare an exchange instance for each standard
+ exchange type that it implements, where the name of the exchange instance, if defined, is
+ "amq." followed by the exchange type name.
+
+ The server MUST, in each virtual host, pre-declare at least two direct exchange instances:
+ one named "amq.direct", the other with no public name that serves as a default exchange for
+ publish commands (such as message.transfer).
+ </doc>
+ <doc type="scenario">
+ Client creates a temporary queue and attempts to bind to each required exchange instance
+ ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" if those types are defined).
+ </doc>
+ </rule>
+
+ <rule name="default-exchange">
+ <doc>
+ The server MUST pre-declare a direct exchange with no public name to act as the default
+ exchange for content publish commands (such as message.transfer) and for default queue
+ bindings.
+ </doc>
+ <doc type="scenario">
+ Client checks that the default exchange is active by publishing a message with a suitable
+ routing key but without specifying the exchange name, then ensuring that the message arrives
+ in the queue correctly.
+ </doc>
+ </rule>
+
+ <rule name="default-access">
+ <doc>
+ The default exchange MUST NOT be accessible to the client except by specifying an empty
+ exchange name in a content publish command (such as message.transfer). That is, the server
+ must not let clients explicitly bind, unbind, delete, or make any other reference to this
+ exchange.
+ </doc>
+ </rule>
+
+ <rule name="extensions">
+ <doc>
+ The server MAY implement other exchange types as wanted.
+ </doc>
+ </rule>
+
+ <role name="server" implement="MUST" />
+ <role name="client" implement="MUST" />
+
+ <domain name="name" type="str8" label="exchange name">
+ <doc>
+ The exchange name is a client-selected string that identifies the exchange for publish
+ commands. Exchange names may consist of any mixture of digits, letters, and underscores.
+ Exchange names are scoped by the virtual host.
+ </doc>
+ </domain>
+
+ <!-- - Command: exchange.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="declare" code="0x1" label="verify exchange exists, create if needed">
+ <doc>
+ This command creates an exchange if it does not already exist, and if the exchange exists,
+ verifies that it is of the correct and expected class.
+ </doc>
+
+ <rule name="minimum">
+ <doc>
+ The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose
+ no limit except as defined by available resources.
+ </doc>
+ <doc type="scenario">
+ The client creates as many exchanges as it can until the server reports an error; the
+ number of exchanges successfully created must be at least sixteen.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="exchange" type="name" required="true">
+ <exception name="reserved-names" error-code="not-allowed">
+ <doc>
+ Exchange names starting with "amq." are reserved for pre-declared and standardized
+ exchanges. The client MUST NOT attempt to create an exchange starting with "amq.".
+ </doc>
+ </exception>
+
+ <exception name="exchange-name-required" error-code="invalid-argument">
+ <doc>
+ The name of the exchange MUST NOT be a blank or empty string.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="type" type="str8" label="exchange type" required="true">
+ <doc>
+ Each exchange belongs to one of a set of exchange types implemented by the server. The
+ exchange types define the functionality of the exchange - i.e. how messages are routed
+ through it. It is not valid or meaningful to attempt to change the type of an existing
+ exchange.
+ </doc>
+
+ <exception name="typed" error-code="not-allowed">
+ <doc>
+ Exchanges cannot be redeclared with different types. The client MUST NOT attempt to
+ redeclare an existing exchange with a different type than used in the original
+ exchange.declare command.
+ </doc>
+ </exception>
+
+ <exception name="exchange-type-not-found" error-code="not-found">
+ <doc>
+ If the client attempts to create an exchange which the server does not recognize, an
+ exception MUST be sent.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="alternate-exchange" type="name" label= "exchange name for unroutable messages">
+ <doc>
+ In the event that a message cannot be routed, this is the name of the exchange to which
+ the message will be sent. Messages transferred using message.transfer will be routed to
+ the alternate-exchange only if they are sent with the "none" accept-mode, and the
+ discard-unroutable delivery property is set to false, and there is no queue to route to
+ for the given message according to the bindings on this exchange.
+ </doc>
+
+ <rule name="empty-name">
+ <doc>
+ If alternate-exchange is not set (its name is an empty string), unroutable messages
+ that would be sent to the alternate-exchange MUST be dropped silently.
+ </doc>
+ </rule>
+
+ <exception name="pre-existing-exchange" error-code="not-allowed">
+ <doc>
+ If the alternate-exchange is not empty and if the exchange already exists with a
+ different alternate-exchange, then the declaration MUST result in an exception.
+ </doc>
+ </exception>
+
+ <rule name="double-failure">
+ <doc>
+ A message which is being routed to a alternate exchange, MUST NOT be re-routed to a
+ secondary alternate exchange if it fails to route in the primary alternate exchange.
+ After such a failure, the message MUST be dropped. This prevents looping.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="passive" type="bit" label="do not create exchange">
+ <doc>
+ If set, the server will not create the exchange. The client can use this to check whether
+ an exchange exists without modifying the server state.
+ </doc>
+ <exception name="not-found" error-code="not-found">
+ <doc>
+ If set, and the exchange does not already exist, the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="durable" type="bit" label="request a durable exchange">
+ <doc>
+ If set when creating a new exchange, the exchange will be marked as durable. Durable
+ exchanges remain active when a server restarts. Non-durable exchanges (transient
+ exchanges) are purged if/when a server restarts.
+ </doc>
+
+ <rule name="support">
+ <doc>
+ The server MUST support both durable and transient exchanges.
+ </doc>
+ </rule>
+
+ <rule name="sticky">
+ <doc>
+ The server MUST ignore the durable field if the exchange already exists.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="auto-delete" type="bit" label="auto-delete when unused">
+ <doc>
+ If set, the exchange is deleted automatically when there remain no bindings between the
+ exchange and any queue. Such an exchange will not be automatically deleted until at least
+ one binding has been made to prevent the immediate deletion of the exchange upon creation.
+ </doc>
+ <rule name="sticky">
+ <doc>
+ The server MUST ignore the auto-delete field if the exchange already exists.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="arguments" type="map" label="arguments for declaration">
+ <doc>
+ A set of arguments for the declaration. The syntax and semantics of these arguments
+ depends on the server implementation. This field is ignored if passive is 1.
+ </doc>
+
+ <exception name="unknown-argument" error-code="not-implemented">
+ <doc>
+ If the arguments field contains arguments which are not understood by the server,
+ it MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: exchange.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="delete" code="0x2" label="delete an exchange">
+ <doc>
+ This command deletes an exchange. When an exchange is deleted all queue bindings on the
+ exchange are cancelled.
+ </doc>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="exchange" type="name" required="true">
+ <exception name="exists" error-code="not-found">
+ <doc>
+ The client MUST NOT attempt to delete an exchange that does not exist.
+ </doc>
+ </exception>
+
+ <exception name="exchange-name-required" error-code="invalid-argument">
+ <doc>
+ The name of the exchange MUST NOT be a missing or empty string.
+ </doc>
+ </exception>
+
+ <exception name="used-as-alternate" error-code="not-allowed">
+ <doc>
+ An exchange MUST NOT be deleted if it is in use as an alternate-exchange by a queue or
+ by another exchange.
+ </doc>
+ </exception>
+
+ </field>
+
+ <field name="if-unused" type="bit" label="delete only if unused">
+ <doc>
+ If set, the server will only delete the exchange if it has no queue bindings. If the
+ exchange has queue bindings the server does not delete it but raises an exception
+ instead.
+ </doc>
+ <exception name="exchange-in-use" error-code="precondition-failed">
+ <doc>
+ If the exchange has queue bindings, and the if-unused flag is set, the server MUST NOT
+ delete the exchange, but MUST raise and exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: exchange.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="query" code="0x3" label="request information about an exchange">
+ <doc>
+ This command is used to request information on a particular exchange.
+ </doc>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="name" type="str8" label="the exchange name">
+ <doc>
+ The name of the exchange for which information is requested. If not specified explicitly
+ the default exchange is implied.
+ </doc>
+ </field>
+
+ <result>
+ <struct name="exchange-query-result" size="4" code="0x1" pack="2">
+ <doc>
+ This is sent in response to a query request and conveys information on a particular
+ exchange.
+ </doc>
+
+ <field name="type" type="str8" label="indicate the exchange type">
+ <doc>
+ The type of the exchange. Will be empty if the exchange is not found.
+ </doc>
+ </field>
+
+ <field name="durable" type="bit" label="indicate the durability">
+ <doc>
+ The durability of the exchange, i.e. if set the exchange is durable. Will not be set
+ if the exchange is not found.
+ </doc>
+ </field>
+
+ <field name="not-found" type="bit" label="indicate an unknown exchange">
+ <doc>
+ If set, the exchange for which information was requested is not known.
+ </doc>
+ </field>
+
+ <field name="arguments" type="map" label="other unspecified exchange properties">
+ <doc>
+ A set of properties of the exchange whose syntax and semantics depends on the server
+ implementation. Will be empty if the exchange is not found.
+ </doc>
+ </field>
+ </struct>
+ </result>
+ </command>
+
+ <!-- - Command: exchange.bind - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="bind" code="0x4" label="bind queue to an exchange">
+ <doc> This command binds a queue to an exchange. Until a queue is bound it will not receive
+ any messages. In a classic messaging model, store-and-forward queues are bound to a direct
+ exchange and subscription queues are bound to a topic exchange. </doc>
+
+ <rule name="duplicates">
+ <doc>
+ A server MUST ignore duplicate bindings - that is, two or more bind commands with the
+ same exchange, queue, and binding-key - without treating these as an error. The value of
+ the arguments used for the binding MUST NOT be altered by subsequent binding requests.
+ </doc>
+ <doc type="scenario">
+ A client binds a named queue to an exchange. The client then repeats the bind (with
+ identical exchange, queue, and binding-key). The second binding should use a different
+ value for the arguments field.
+ </doc>
+ </rule>
+
+ <rule name="durable-exchange">
+ <doc> Bindings between durable queues and durable exchanges are automatically durable and
+ the server MUST restore such bindings after a server restart. </doc>
+ <doc type="scenario"> A server creates a named durable queue and binds it to a durable
+ exchange. The server is restarted. The client then attempts to use the queue/exchange
+ combination. </doc>
+ </rule>
+
+ <rule name="binding-count">
+ <doc> The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit
+ except as defined by available resources. </doc>
+ <doc type="scenario"> A client creates a named queue and attempts to bind it to 4 different
+ exchanges. </doc>
+ </rule>
+
+ <rule name="multiple-bindings">
+ <doc> Where more than one binding exists between a particular exchange instance and a
+ particular queue instance any given message published to that exchange should be delivered
+ to that queue at most once, regardless of how many distinct bindings match. </doc>
+ <doc type="scenario"> A client creates a named queue and binds it to the same topic exchange
+ at least three times using intersecting binding-keys (for example, "animals.*",
+ "animals.dogs.*", "animal.dogs.chihuahua"). Verify that a message matching all the
+ bindings (using previous example, routing key = "animal.dogs.chihuahua") is delivered once
+ only. </doc>
+ </rule>
+
+ <implement role="server" handle="MUST"/>
+
+ <field name="queue" type="queue.name" required="true">
+ <doc> Specifies the name of the queue to bind. </doc>
+
+ <exception name="empty-queue" error-code="invalid-argument">
+ <doc> A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. empty
+ queue name) to an exchange. </doc>
+ <doc type="scenario"> A client attempts to bind with an unnamed (empty) queue name to an
+ exchange. </doc>
+ </exception>
+
+ <exception name="queue-existence" error-code="not-found">
+ <doc> A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously
+ declared) to an exchange. </doc>
+ <doc type="scenario"> A client attempts to bind an undeclared queue name to an exchange.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="exchange" type="name" label="name of the exchange to bind to" required="true">
+ <exception name="exchange-existence" error-code="not-found">
+ <doc> A client MUST NOT be allowed to bind a queue to a non-existent exchange. </doc>
+ <doc type="scenario"> A client attempts to bind a named queue to a undeclared exchange.
+ </doc>
+ </exception>
+
+ <exception name="exchange-name-required" error-code="invalid-argument">
+ <doc> The name of the exchange MUST NOT be a blank or empty string. </doc>
+ </exception>
+ </field>
+
+ <field name="binding-key" type="str8"
+ label="identifies a binding between a given exchange and queue" required="true">
+ <doc> The binding-key uniquely identifies a binding between a given (exchange, queue) pair.
+ Depending on the exchange configuration, the binding key may be matched against the
+ message routing key in order to make routing decisions. The match algorithm depends on the
+ exchange type. Some exchange types may ignore the binding key when making routing
+ decisions. Refer to the specific exchange type documentation. The meaning of an empty
+ binding key depends on the exchange implementation. </doc>
+ </field>
+
+ <field name="arguments" type="map" label="arguments for binding">
+ <doc> A set of arguments for the binding. The syntax and semantics of these arguments
+ depends on the exchange class. </doc>
+
+ <exception name="unknown-argument" error-code="not-implemented">
+ <doc> If the arguments field contains arguments which are not understood by the server, it
+ MUST raise an exception. </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: exchange.unbind - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="unbind" code="0x5" label="unbind a queue from an exchange">
+ <doc>
+ This command unbinds a queue from an exchange.
+ </doc>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="queue" type="queue.name" required="true">
+ <doc>
+ Specifies the name of the queue to unbind.
+ </doc>
+ <exception name="non-existent-queue" error-code="not-found">
+ <doc>
+ If the queue does not exist the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="exchange" type="name" required="true">
+ <doc>
+ The name of the exchange to unbind from.
+ </doc>
+
+ <exception name="non-existent-exchange" error-code="not-found">
+ <doc>
+ If the exchange does not exist the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="exchange-name-required" error-code="invalid-argument">
+ <doc>
+ The name of the exchange MUST NOT be a blank or empty string.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="binding-key" type="str8" label="the key of the binding" required="true">
+ <doc>
+ Specifies the binding-key of the binding to unbind.
+ </doc>
+
+ <exception name="non-existent-binding-key" error-code="not-found">
+ <doc>
+ If there is no matching binding-key the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: exchange.bound - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="bound" code="0x6" label="request information about bindings to an exchange">
+ <doc>
+ This command is used to request information on the bindings to a particular exchange.
+ </doc>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="exchange" type="str8" label="the exchange name">
+ <doc>
+ The name of the exchange for which binding information is being requested. If not
+ specified explicitly the default exchange is implied.
+ </doc>
+ </field>
+
+ <field name="queue" type="str8" label="a queue name" required="true">
+ <doc>
+ If populated then determine whether the given queue is bound to the exchange.
+ </doc>
+ </field>
+
+ <field name="binding-key" type="str8" label="a binding-key">
+ <doc>
+ If populated defines the binding-key of the binding of interest, if not populated the
+ request will ignore the binding-key on bindings when searching for a match.
+ </doc>
+ </field>
+
+ <field name="arguments" type="map" label="a set of binding arguments">
+ <doc>
+ If populated defines the arguments of the binding of interest if not populated the request
+ will ignore the arguments on bindings when searching for a match
+ </doc>
+ </field>
+
+ <result>
+ <struct name="exchange-bound-result" size="4" code="0x2" pack="2">
+ <field name="exchange-not-found" type="bit" label="indicate an unknown exchange">
+ <doc>
+ If set, the exchange for which information was requested is not known.
+ </doc>
+ </field>
+
+ <field name="queue-not-found" type="bit" label="indicate an unknown queue">
+ <doc>
+ If set, the queue specified is not known.
+ </doc>
+ </field>
+
+ <field name="queue-not-matched" type="bit" label="indicate no matching queue">
+ <doc>
+ A bit which if set indicates that no binding was found from the specified exchange to
+ the specified queue.
+ </doc>
+ </field>
+
+ <field name="key-not-matched" type="bit" label="indicate no matching binding-key">
+ <doc>
+ A bit which if set indicates that no binding was found from the specified exchange
+ with the specified binding-key.
+ </doc>
+ </field>
+
+ <field name="args-not-matched" type="bit" label="indicate no matching arguments">
+ <doc>
+ A bit which if set indicates that no binding was found from the specified exchange
+ with the specified arguments.
+ </doc>
+ </field>
+ </struct>
+ </result>
+ </command>
+
+ </class>
+
+ <!-- == Class: queue ========================================================================= -->
+
+ <class name="queue" code="0x8" label="work with queues">
+ <doc>
+ Queues store and forward messages. Queues can be configured in the server or created at
+ runtime. Queues must be attached to at least one exchange in order to receive messages from
+ publishers.
+ </doc>
+
+ <doc type="grammar">
+ queue = C:DECLARE
+ / C:BIND
+ / C:PURGE
+ / C:DELETE
+ / C:QUERY
+ / C:UNBIND
+ </doc>
+
+ <rule name="any-content">
+ <doc>
+ A server MUST allow any content class to be sent to any queue, in any mix, and queue and
+ deliver these content classes independently. Note that all commands that fetch content off
+ queues are specific to a given content class.
+ </doc>
+ <doc type="scenario">
+ Client creates an exchange of each standard type and several queues that it binds to each
+ exchange. It must then successfully send each of the standard content types to each of the
+ available queues.
+ </doc>
+ </rule>
+
+ <role name="server" implement="MUST" />
+ <role name="client" implement="MUST" />
+
+ <domain name="name" type="str8" label="queue name">
+ <doc>
+ The queue name identifies the queue within the virtual host. Queue names must have a length
+ of between 1 and 255 characters inclusive, must start with a digit, letter or underscores
+ ('_') character, and must be otherwise encoded in UTF-8.
+ </doc>
+ </domain>
+
+ <!-- - Command: queue.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="declare" code="0x1" label="declare queue">
+ <doc>
+ This command creates or checks a queue. When creating a new queue the client can specify
+ various properties that control the durability of the queue and its contents, and the level
+ of sharing for the queue.
+ </doc>
+
+ <rule name="default-binding">
+ <doc>
+ The server MUST create a default binding for a newly-created queue to the default
+ exchange, which is an exchange of type 'direct' and use the queue name as the binding-key.
+ </doc>
+ <doc type="scenario">
+ Client creates a new queue, and then without explicitly binding it to an exchange,
+ attempts to send a message through the default exchange binding, i.e. publish a message to
+ the empty exchange, with the queue name as binding-key.
+ </doc>
+ </rule>
+
+ <rule name="minimum-queues">
+ <doc>
+ The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no
+ limit except as defined by available resources.
+ </doc>
+ <doc type="scenario">
+ Client attempts to create as many queues as it can until the server reports an error. The
+ resulting count must at least be 256.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="queue" type="name" required="true">
+ <exception name="reserved-prefix" error-code="not-allowed">
+ <doc>
+ Queue names starting with "amq." are reserved for pre-declared and standardized server
+ queues. A client MUST NOT attempt to declare a queue with a name that starts with "amq."
+ and the passive option set to zero.
+ </doc>
+ <doc type="scenario">
+ A client attempts to create a queue with a name starting with "amq." and with the
+ passive option set to zero.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="alternate-exchange" type="exchange.name"
+ label= "exchange name for messages with exceptions">
+ <doc>
+ The alternate-exchange field specifies how messages on this queue should be treated when
+ they are rejected by a subscriber, or when they are orphaned by queue deletion. When
+ present, rejected or orphaned messages MUST be routed to the alternate-exchange. In all
+ cases the messages MUST be removed from the queue.
+ </doc>
+
+ <exception name="pre-existing-exchange" error-code="not-allowed">
+ <doc>
+ If the alternate-exchange is not empty and if the queue already exists with a different
+ alternate-exchange, then the declaration MUST result in an exception.
+ </doc>
+ </exception>
+
+ <exception name="unknown-exchange" error-code="not-found">
+ <doc>
+ if the alternate-exchange does not match the name of any existing exchange on the
+ server, then an exception must be raised.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="passive" type="bit" label="do not create queue">
+ <doc>
+ If set, the server will not create the queue. This field allows the client to assert the
+ presence of a queue without modifying the server state.
+ </doc>
+
+ <exception name="passive" error-code="not-found">
+ <doc>
+ The client MAY ask the server to assert that a queue exists without creating the queue
+ if not. If the queue does not exist, the server treats this as a failure.
+ </doc>
+ <doc type="scenario">
+ Client declares an existing queue with the passive option and expects the command to
+ succeed. Client then attempts to declare a non-existent queue with the passive option,
+ and the server must close the session with the correct exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="durable" type="bit" label="request a durable queue">
+ <doc>
+ If set when creating a new queue, the queue will be marked as durable. Durable queues
+ remain active when a server restarts. Non-durable queues (transient queues) are purged
+ if/when a server restarts. Note that durable queues do not necessarily hold persistent
+ messages, although it does not make sense to send persistent messages to a transient
+ queue.
+ </doc>
+
+ <rule name="persistence">
+ <doc>
+ The queue definition MUST survive the server losing all transient memory, e.g. a
+ machine restart.
+ </doc>
+ <doc type="scenario">
+ Client creates a durable queue; server is then restarted. Client then attempts to send
+ message to the queue. The message should be successfully delivered.
+ </doc>
+ </rule>
+
+ <rule name="types">
+ <doc>
+ The server MUST support both durable and transient queues.
+ </doc>
+ <doc type="scenario">
+ A client creates two named queues, one durable and one transient.
+ </doc>
+ </rule>
+
+ <rule name="pre-existence">
+ <doc>
+ The server MUST ignore the durable field if the queue already exists.
+ </doc>
+ <doc type="scenario">
+ A client creates two named queues, one durable and one transient. The client then
+ attempts to declare the two queues using the same names again, but reversing the value
+ of the durable flag in each case. Verify that the queues still exist with the original
+ durable flag values.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="exclusive" type="bit" label="request an exclusive queue">
+ <doc>
+ Exclusive queues can only be used from one session at a time. Once a session
+ declares an exclusive queue, that queue cannot be used by any other session until the
+ declaring session closes.
+ </doc>
+
+ <rule name="types">
+ <doc>
+ The server MUST support both exclusive (private) and non-exclusive (shared) queues.
+ </doc>
+ <doc type="scenario">
+ A client creates two named queues, one exclusive and one non-exclusive.
+ </doc>
+ </rule>
+
+ <exception name="in-use" error-code="resource-locked">
+ <doc>
+ If the server receives a declare, bind, consume or get request for a queue that has been
+ declared as exclusive by an existing client session, it MUST raise an exception.
+ </doc>
+ <doc type="scenario">
+ A client declares an exclusive named queue. A second client on a different session
+ attempts to declare a queue of the same name.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="auto-delete" type="bit" label="auto-delete queue when unused">
+ <doc>
+ If this field is set and the exclusive field is also set, then the queue MUST be deleted
+ when the session closes.
+
+ If this field is set and the exclusive field is not set the queue is deleted when all
+ the consumers have finished using it. Last consumer can be cancelled either explicitly
+ or because its session is closed. If there was no consumer ever on the queue, it won't
+ be deleted.
+ </doc>
+
+ <rule name="pre-existence">
+ <doc>
+ The server MUST ignore the auto-delete field if the queue already exists.
+ </doc>
+ <doc type="scenario">
+ A client creates two named queues, one as auto-delete and one explicit-delete. The
+ client then attempts to declare the two queues using the same names again, but reversing
+ the value of the auto-delete field in each case. Verify that the queues still exist with
+ the original auto-delete flag values.
+ </doc>
+ </rule>
+ </field>
+
+ <field name="arguments" type="map" label="arguments for declaration">
+ <doc>
+ A set of arguments for the declaration. The syntax and semantics of these arguments
+ depends on the server implementation. This field is ignored if passive is 1.
+ </doc>
+
+ <exception name="unknown-argument" error-code="not-implemented">
+ <doc>
+ If the arguments field contains arguments which are not understood by the server,
+ it MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: queue.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="delete" code="0x2" label="delete a queue">
+ <doc>
+ This command deletes a queue. When a queue is deleted any pending messages are sent to the
+ alternate-exchange if defined, or discarded if it is not.
+ </doc>
+
+
+ <implement role="server" handle="MUST" />
+
+ <field name="queue" type="name" required="true">
+ <doc>
+ Specifies the name of the queue to delete.
+ </doc>
+
+ <exception name="empty-name" error-code="invalid-argument">
+ <doc>
+ If the queue name in this command is empty, the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="queue-exists" error-code="not-found">
+ <doc>
+ The queue must exist. If the client attempts to delete a non-existing queue the server
+ MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="if-unused" type="bit" label="delete only if unused">
+ <doc>
+ If set, the server will only delete the queue if it has no consumers. If the queue has
+ consumers the server does does not delete it but raises an exception instead.
+ </doc>
+
+ <exception name="if-unused-flag" error-code="precondition-failed">
+ <doc>
+ The server MUST respect the if-unused flag when deleting a queue.
+ </doc>
+ </exception>
+ </field>
+
+ <field name="if-empty" type="bit" label="delete only if empty">
+ <doc>
+ If set, the server will only delete the queue if it has no messages.
+ </doc>
+ <exception name="not-empty" error-code="precondition-failed">
+ <doc>
+ If the queue is not empty the server MUST raise an exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: queue.purge - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="purge" code="0x3" label="purge a queue">
+ <doc>
+ This command removes all messages from a queue. It does not cancel subscribers. Purged
+ messages are deleted without any formal "undo" mechanism.
+ </doc>
+
+ <rule name="empty">
+ <doc>
+ A call to purge MUST result in an empty queue.
+ </doc>
+ </rule>
+
+ <rule name="pending-messages">
+ <doc>
+ The server MUST NOT purge messages that have already been sent to a client but not yet
+ accepted.
+ </doc>
+ </rule>
+
+ <rule name="purge-recovery">
+ <doc>
+ The server MAY implement a purge queue or log that allows system administrators to recover
+ accidentally-purged messages. The server SHOULD NOT keep purged messages in the same
+ storage spaces as the live messages since the volumes of purged messages may get very
+ large.
+ </doc>
+ </rule>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="queue" type="name" required="true">
+ <doc>
+ Specifies the name of the queue to purge.
+ </doc>
+
+ <exception name="empty-name" error-code="invalid-argument">
+ <doc>
+ If the the queue name in this command is empty, the server MUST raise an exception.
+ </doc>
+ </exception>
+
+ <exception name="queue-exists" error-code="not-found">
+ <doc>
+ The queue MUST exist. Attempting to purge a non-existing queue MUST cause an exception.
+ </doc>
+ </exception>
+ </field>
+ </command>
+
+ <!-- - Command: queue.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
+
+ <command name="query" code="0x4" label="request information about a queue">
+ <doc>
+ This command requests information about a queue.
+ </doc>
+
+ <implement role="server" handle="MUST" />
+
+ <field name="queue" type="name" label="the queried queue" required="true"/>
+
+ <result>
+ <struct name="queue-query-result" size="4" code="0x1" pack="2">
+ <doc>
+ This is sent in response to queue.query, and conveys the requested information about a
+ queue. If no queue with the specified name exists then none of the fields within the
+ returned result struct will be populated.
+ </doc>
+
+ <field name="queue" type="name" required="true">
+ <doc>
+ Reports the name of the queue.
+ </doc>
+ </field>
+
+ <field name="alternate-exchange" type="exchange.name" />
+
+ <field name="durable" type="bit" />
+
+ <field name="exclusive" type="bit" />
+
+ <field name="auto-delete" type="bit" />
+
+ <field name="arguments" type="map" />
+
+ <field name="message-count" type="uint32" label="number of messages in queue"
+ required="true">
+ <doc> Reports the number of messages in the queue. </doc>
+ </field>
+
+ <field name="subscriber-count" type="uint32" label="number of subscribers"
+ required="true">
+ <doc>
+ Reports the number of subscribers for the queue.
+ </doc>
+ </field>
+ </struct>
+ </result>
+ </command>
+
+ </class>
+
+</amqp>
View Lorry Controller Status