diff options
| author | Rafael H. Schloming <rhs@apache.org> | 2013-05-09 16:22:12 +0000 |
|---|---|---|
| committer | Rafael H. Schloming <rhs@apache.org> | 2013-05-09 16:22:12 +0000 |
| commit | ec44e236b72061407ed1c6c7177893d4def0f820 (patch) | |
| tree | 4895b0c5fb105d277d6b7f987a7ed4079eecef87 | |
| parent | d3c805dc3ad329ed34434ebbf681e7e0946ee492 (diff) | |
| download | qpid-python-ec44e236b72061407ed1c6c7177893d4def0f820.tar.gz | |
QPID-4798: merged changes from trunk to 0.22 branch
git-svn-id: https://svn.apache.org/repos/asf/qpid/branches/0.22@1480717 13f79535-47bb-0310-9956-ffa450edef68
30 files changed, 10230 insertions, 45760 deletions
diff --git a/qpid/cpp/configure.ac b/qpid/cpp/configure.ac index 1523af81af..2ced4b7577 100644 --- a/qpid/cpp/configure.ac +++ b/qpid/cpp/configure.ac @@ -247,7 +247,7 @@ fi AM_CONDITIONAL([HAVE_PERL_DEVEL], [test -n "$PERL" && test -n "$SWIG" && test -n "$PERL_INC"]) specdir=`pwd`/$srcdir/../specs -AMQP_FINAL_XML=$specdir/amqp.0-10-qpid-errata.xml +AMQP_FINAL_XML=$specdir/amqp.0-10-qpid-errata.stripped.xml AC_SUBST(AMQP_FINAL_XML) AM_CONDITIONAL([GENERATE], [test -f $AMQP_FINAL_XML]) test -f $AMQP_FINAL_XML -a -z "$RUBY" && AC_MSG_ERROR([Missing ruby installation (try "yum install ruby").]) diff --git a/qpid/cpp/rubygen/0-10/exceptions.rb b/qpid/cpp/rubygen/0-10/exceptions.rb index 02e3a5d547..fed8fdac5b 100755 --- a/qpid/cpp/rubygen/0-10/exceptions.rb +++ b/qpid/cpp/rubygen/0-10/exceptions.rb @@ -32,7 +32,7 @@ class GenExceptions < CppGen enum.choices.each { |c| name=c.name.typename+suffix+"Exception" genl - doxygen_comment { genl c.doc } + doxygen_comment { genl c.doc } if c.doc struct(name, "public #{base}") { genl "#{name}(const std::string& msg=std::string())" genl " : #{base}(#{ns}::#{c.name.shout}, msg) {}" diff --git a/qpid/cpp/rubygen/framing.0-10/Session.rb b/qpid/cpp/rubygen/framing.0-10/Session.rb index e800df9b2e..28165448ed 100755 --- a/qpid/cpp/rubygen/framing.0-10/Session.rb +++ b/qpid/cpp/rubygen/framing.0-10/Session.rb @@ -34,6 +34,7 @@ class CppGen # Generates a doxygen comment for AmqpMethod m. def doxygen(m) + return unless m.doc doxygen_comment { genl m.doc genl @@ -143,7 +144,8 @@ class SessionNoKeywordGen < CppGen namespace(@namespace) { doxygen_comment { genl "AMQP #{@amqp.version} #{sync_adjective} session API." - genl @amqp.class_("session").doc + d = @amqp.class_("session").doc + genl d if d # FIXME aconway 2008-05-23: additional doc on sync/async use. } cpp_class(@classname, "public #{@version_base}") { diff --git a/qpid/cpp/rubygen/framing.0-10/constants.rb b/qpid/cpp/rubygen/framing.0-10/constants.rb index 85bfb96ac0..589d94e23d 100755 --- a/qpid/cpp/rubygen/framing.0-10/constants.rb +++ b/qpid/cpp/rubygen/framing.0-10/constants.rb @@ -135,7 +135,7 @@ EOS name=c.name.caps+"Exception" value="#{package}::#{enum.parent.name.shout}_#{c.name.shout}" genl - doxygen_comment { genl c.doc } + doxygen_comment { genl c.doc } if c.doc struct(c.name.caps+"Exception", base) { genl "std::string getPrefix() const { return \"#{c.name}\"; }" genl "#{c.name.caps}Exception(const std::string& msg=std::string()) : #{base}(#{value}, \"\"+msg) {}" diff --git a/qpid/cpp/src/CMakeLists.txt b/qpid/cpp/src/CMakeLists.txt index d69452f68c..2a3cfcf96b 100644 --- a/qpid/cpp/src/CMakeLists.txt +++ b/qpid/cpp/src/CMakeLists.txt @@ -175,7 +175,7 @@ inherit_value ("winver_LEGAL_COPYRIGHT" "") # present, and if any sources have changed, forcing a re-gen of source code. set(AMQP_SPEC_DIR ${qpid-cpp_SOURCE_DIR}/../specs) -set(AMQP_SPEC ${AMQP_SPEC_DIR}/amqp.0-10-qpid-errata.xml) +set(AMQP_SPEC ${AMQP_SPEC_DIR}/amqp.0-10-qpid-errata.stripped.xml) if (EXISTS ${AMQP_SPEC}) include(FindRuby) include(FindPythonInterp) diff --git a/qpid/cpp/src/tests/legacystore/system_test.sh b/qpid/cpp/src/tests/legacystore/system_test.sh index 4cccc5ac8d..dbf8902cff 100644 --- a/qpid/cpp/src/tests/legacystore/system_test.sh +++ b/qpid/cpp/src/tests/legacystore/system_test.sh @@ -28,7 +28,7 @@ if ! test -d "$QPID_DIR" ; then fi STORE_LIB=../lib/.libs/msgstore.so -xml_spec=$QPID_DIR/specs/amqp.0-10-qpid-errata.xml +xml_spec=$QPID_DIR/specs/amqp.0-10-qpid-errata.stripped.xml test -f $xml_spec || error "$xml_spec not found: invalid \$QPID_DIR ?" export PYTHONPATH=$QPID_DIR/python:$QPID_DIR/extras/qmf/src/py:$QPID_DIR/tools/src/py diff --git a/qpid/java/common/build.xml b/qpid/java/common/build.xml index e599c840db..1316017909 100644 --- a/qpid/java/common/build.xml +++ b/qpid/java/common/build.xml @@ -28,15 +28,15 @@ <property name="framing.generated.dir" location="${module.precompiled}/${generated.package}" /> <property name="qpidbuildversion.java" location="${module.precompiled}/org/apache/qpid/QpidBuildVersion.java" /> <property name="xml.spec.dir" location="${project.root}/../specs" /> - <property name="xml.spec.deps" value="amqp.0-8.xml amqp.0-9.xml amqp0-9-1.stripped.xml" /> - <property name="xml.spec.list" value='"${xml.spec.dir}/amqp.0-8.xml" "${xml.spec.dir}/amqp.0-9.xml" "${xml.spec.dir}/amqp0-9-1.stripped.xml"' /> + <property name="xml.spec.deps" value="amqp0-8-qpid.stripped.xml amqp0-9-qpid.stripped.xml amqp0-9-1.stripped.xml" /> + <property name="xml.spec.list" value='"${xml.spec.dir}/amqp0-8-qpid.stripped.xml" "${xml.spec.dir}/amqp0-9-qpid.stripped.xml" "${xml.spec.dir}/amqp0-9-1.stripped.xml"' /> <property name="gentools.timestamp" location="${framing.generated.dir}/gentools.timestamp" /> <property name="jython.timestamp" location="${framing.generated.dir}/jython.timestamp" /> <property name="selector.output.dir" value="${module.precompiled}/org/apache/qpid/filter/selector"/> <target name="check_jython_deps"> <uptodate property="jython.notRequired" targetfile="${jython.timestamp}"> - <srcfiles dir="${xml.spec.dir}" includes="amqp.0-10-qpid-errata.xml" /> + <srcfiles dir="${xml.spec.dir}" includes="amqp.0-10-qpid-errata.stripped.xml" /> </uptodate> </target> @@ -45,7 +45,7 @@ <args> <arg value="${basedir}/codegen"/> <arg value="${module.precompiled}"/> - <arg value="${xml.spec.dir}/amqp.0-10-qpid-errata.xml"/> + <arg value="${xml.spec.dir}/amqp.0-10-qpid-errata.stripped.xml"/> <arg value="${basedir}"/> </args> </jython> diff --git a/qpid/python/qpid/connection08.py b/qpid/python/qpid/connection08.py index 0045e122ea..e4762ff974 100644 --- a/qpid/python/qpid/connection08.py +++ b/qpid/python/qpid/connection08.py @@ -151,6 +151,12 @@ class Connection: def read_0_9(self): return self.read_8_0() + def write_0_91(self, frame): + self.write_8_0(frame) + + def read_0_91(self): + return self.read_8_0() + def write_0_10(self, frame): c = self.codec flags = 0 diff --git a/qpid/python/qpid/specs/amqp-0-10-qpid-errata-stripped.xml b/qpid/python/qpid/specs/amqp-0-10-qpid-errata-stripped.xml new file mode 100644 index 0000000000..83ddf709e9 --- /dev/null +++ b/qpid/python/qpid/specs/amqp-0-10-qpid-errata-stripped.xml @@ -0,0 +1,1203 @@ +<?xml version="1.0"?> + +<!-- +(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. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="0" xmlns="http://www.amqp.org/schema/amqp.xsd" port="5672" minor="10"> + <type name="bin8" code="0x00" fixed-width="1"/> + <type name="int8" code="0x01" fixed-width="1"/> + <type name="uint8" code="0x02" fixed-width="1"/> + <type name="char" code="0x04" fixed-width="1"/> + <type name="boolean" code="0x08" fixed-width="1"/> + <type name="bin16" code="0x10" fixed-width="2"/> + <type name="int16" code="0x11" fixed-width="2"/> + <type name="uint16" code="0x12" fixed-width="2"/> + <type name="bin32" code="0x20" fixed-width="4"/> + <type name="int32" code="0x21" fixed-width="4"/> + <type name="uint32" code="0x22" fixed-width="4"/> + <type name="float" code="0x23" fixed-width="4"/> + <type name="char-utf32" code="0x27" fixed-width="4"/> + <type name="sequence-no" fixed-width="4"/> + <type name="bin64" code="0x30" fixed-width="8"/> + <type name="int64" code="0x31" fixed-width="8"/> + <type name="uint64" code="0x32" fixed-width="8"/> + <type name="double" code="0x33" fixed-width="8"/> + <type name="datetime" code="0x38" fixed-width="8"/> + <type name="bin128" code="0x40" fixed-width="16"/> + <type name="uuid" code="0x48" fixed-width="16"/> + <type name="bin256" code="0x50" fixed-width="32"/> + <type name="bin512" code="0x60" fixed-width="64"/> + <type name="bin1024" code="0x70" fixed-width="128"/> + <type name="vbin8" code="0x80" variable-width="1"/> + <type name="str8-latin" code="0x84" variable-width="1"/> + <type name="str8" code="0x85" variable-width="1"/> + <type name="str8-utf16" code="0x86" variable-width="1"/> + <type name="vbin16" code="0x90" variable-width="2"/> + <type name="str16-latin" code="0x94" variable-width="2"/> + <type name="str16" code="0x95" variable-width="2"/> + <type name="str16-utf16" code="0x96" variable-width="2"/> + <type name="byte-ranges" variable-width="2"/> + <type name="sequence-set" variable-width="2"/> + <type name="vbin32" code="0xa0" variable-width="4"/> + <type name="map" code="0xa8" variable-width="4"/> + <type name="list" code="0xa9" variable-width="4"/> + <type name="array" code="0xaa" variable-width="4"/> + <type name="struct32" code="0xab" variable-width="4"/> + <type name="bin40" code="0xc0" fixed-width="5"/> + <type name="dec32" code="0xc8" fixed-width="5"/> + <type name="bin72" code="0xd0" fixed-width="9"/> + <type name="dec64" code="0xd8" fixed-width="9"/> + <type name="void" code="0xf0" fixed-width="0"/> + <type name="bit" code="0xf1" fixed-width="0"/> + <constant name="MIN-MAX-FRAME-SIZE" value="4096"/> + <domain name="segment-type" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + <choice name="header" value="2"/> + <choice name="body" value="3"/> + </enum> + </domain> + <domain name="track" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + </enum> + </domain> + <domain name="str16-array" type="array"/> + <class name="connection" code="0x1"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="close-code" type="uint16"> + <enum> + <choice name="normal" value="200"/> + <choice name="connection-forced" value="320"/> + <choice name="invalid-path" value="402"/> + <choice name="framing-error" value="501"/> + </enum> + </domain> + <domain name="amqp-host-url" type="str16"/> + <domain name="amqp-host-array" type="array"/> + <control name="start" code="0x1"> + <rule name="protocol-name"/> + <rule name="client-support"/> + <implement role="client" handle="MUST"/> + <response name="start-ok"/> + <field name="server-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanisms" type="str16-array" required="true"/> + <field name="locales" type="str16-array" required="true"> + <rule name="required-support"/> + </field> + </control> + <control name="start-ok" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="client-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanism" type="str8" required="true"> + <rule name="security"/> + <rule name="validity"/> + </field> + <field name="response" type="vbin32" required="true"/> + <field name="locale" type="str8" required="true"/> + </control> + <control name="secure" code="0x3"> + <implement role="client" handle="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="vbin32" required="true"/> + </control> + <control name="secure-ok" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="response" type="vbin32" required="true"/> + </control> + <control name="tune" code="0x5"> + <implement role="client" handle="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" type="uint16"/> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + </field> + <field name="heartbeat-min" type="uint16"/> + <field name="heartbeat-max" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="tune-ok" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="channel-max" type="uint16" required="true"> + <rule name="upper-limit"/> + <rule name="available-channels"/> + </field> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + <rule name="upper-limit"/> + <rule name="max-frame-size"/> + </field> + <field name="heartbeat" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="open" code="0x7"> + <implement role="server" handle="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" type="str8" required="true"> + <rule name="separation"/> + <rule name="security"/> + </field> + <field name="capabilities" type="str16-array"/> + <field name="insist" type="bit"> + <rule name="behavior"/> + </field> + </control> + <control name="open-ok" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="redirect" code="0x9"> + <rule name="usage"/> + <implement role="client" handle="MUST"/> + <field name="host" type="amqp-host-url" required="true"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="heartbeat" code="0xa"> + <implement role="client" handle="MAY"/> + <implement role="server" handle="MAY"/> + </control> + <control name="close" code="0xb"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <response name="close-ok"/> + <field name="reply-code" type="close-code" required="true"/> + <field name="reply-text" type="str8"/> + </control> + <control name="close-ok" code="0xc"> + <rule name="reporting"/> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + </control> + </class> + <class name="session" code="0x2"> + <rule name="attachment"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <role name="sender" implement="MUST"/> + <role name="receiver" implement="MUST"/> + <domain name="name" type="vbin16"/> + <domain name="detach-code" type="uint8"> + <enum> + <choice name="normal" value="0"/> + <choice name="session-busy" value="1"/> + <choice name="transport-busy" value="2"/> + <choice name="not-attached" value="3"/> + <choice name="unknown-ids" value="4"/> + </enum> + </domain> + <domain name="commands" type="sequence-set"/> + <struct name="header" size="1" pack="1"> + <field name="sync" type="bit"/> + </struct> + <struct name="command-fragment" size="0" pack="0"> + <field name="command-id" type="sequence-no" required="true"/> + <field name="byte-ranges" type="byte-ranges" required="true"/> + </struct> + <domain name="command-fragments" type="array"/> + <control name="attach" code="0x1"> + <rule name="one-transport-per-session"/> + <rule name="one-session-per-transport"/> + <rule name="idempotence"/> + <rule name="scoping"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <response name="attached"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + <field name="force" type="bit"/> + </control> + <control name="attached" code="0x2"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detach" code="0x3"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detached" code="0x4"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + <field name="code" type="detach-code" required="true"/> + </control> + <control name="request-timeout" code="0x5"> + <rule name="maximum-granted-timeout"/> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <response name="timeout"/> + <field name="timeout" type="uint32"/> + </control> + <control name="timeout" code="0x6"> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <field name="timeout" type="uint32"/> + </control> + <control name="command-point" code="0x7"> + <rule name="newly-attached-transports"/> + <rule name="zero-offset"/> + <rule name="nonzero-offset"/> + <implement role="receiver" handle="MUST"/> + <field name="command-id" type="sequence-no" required="true"/> + <field name="command-offset" type="uint64" required="true"/> + </control> + <control name="expected" code="0x8"> + <rule name="include-next-command"/> + <rule name="commands-empty-means-new-session"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands" required="true"/> + <field name="fragments" type="command-fragments"/> + </control> + <control name="confirmed" code="0x9"> + <rule name="durability"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="exclude-known-complete"/> + </field> + <field name="fragments" type="command-fragments"/> + </control> + <control name="completed" code="0xa"> + <rule name="known-completed-reply"/> + <rule name="delayed-reply"/> + <rule name="merged-reply"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="completed-implies-confirmed"/> + <rule name="exclude-known-complete"/> + </field> + <field name="timely-reply" type="bit"/> + </control> + <control name="known-completed" code="0xb"> + <rule name="stateless"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="known-completed-implies-known-confirmed"/> + </field> + </control> + <control name="flush" code="0xc"> + <implement role="receiver" handle="MUST"/> + <field name="expected" type="bit"/> + <field name="confirmed" type="bit"/> + <field name="completed" type="bit"/> + </control> + <control name="gap" code="0xd"> + <rule name="gap-confirmation-and-completion"/> + <rule name="aborted-commands"/> + <rule name="completed-or-confirmed-commands"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"/> + </control> + </class> + <class name="execution" code="0x3"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="error-code" type="uint16"> + <enum> + <choice name="unauthorized-access" value="403"/> + <choice name="not-found" value="404"/> + <choice name="resource-locked" value="405"/> + <choice name="precondition-failed" value="406"/> + <choice name="resource-deleted" value="408"/> + <choice name="illegal-state" value="409"/> + <choice name="command-invalid" value="503"/> + <choice name="resource-limit-exceeded" value="506"/> + <choice name="not-allowed" value="530"/> + <choice name="illegal-argument" value="531"/> + <choice name="not-implemented" value="540"/> + <choice name="internal-error" value="541"/> + <choice name="invalid-argument" value="542"/> + </enum> + </domain> + <command name="sync" code="0x1"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + </command> + <command name="result" code="0x2"> + <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> + <command name="exception" code="0x3"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <field name="error-code" type="error-code" required="true"/> + <field name="command-id" type="sequence-no"/> + <field name="class-code" type="uint8"/> + <field name="command-code" type="uint8"/> + <field name="field-index" type="uint8"/> + <field name="description" type="str16"/> + <field name="error-info" type="map"/> + </command> + </class> + <class name="message" code="0x4"> + <rule name="persistent-message"/> + <rule name="no-persistent-message-discard"/> + <rule name="throttling"/> + <rule name="non-persistent-message-overflow"/> + <rule name="non-persistent-message-discard"/> + <rule name="min-priority-levels"/> + <rule name="priority-level-implementation"/> + <rule name="priority-delivery"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="destination" type="str8"/> + <domain name="accept-mode" type="uint8"> + <enum> + <choice name="explicit" value="0"/> + <choice name="none" value="1"/> + </enum> + </domain> + <domain name="acquire-mode" type="uint8"> + <enum> + <choice name="pre-acquired" value="0"/> + <choice name="not-acquired" value="1"/> + </enum> + </domain> + <domain name="reject-code" type="uint16"> + <enum> + <choice name="unspecified" value="0"/> + <choice name="unroutable" value="1"/> + <choice name="immediate" value="2"/> + </enum> + </domain> + <domain name="resume-id" type="str16"/> + <domain name="delivery-mode" type="uint8"> + <enum> + <choice name="non-persistent" value="1"/> + <choice name="persistent" value="2"/> + </enum> + </domain> + <domain name="delivery-priority" type="uint8"> + <enum> + <choice name="lowest" value="0"/> + <choice name="lower" value="1"/> + <choice name="low" value="2"/> + <choice name="below-average" value="3"/> + <choice name="medium" value="4"/> + <choice name="above-average" value="5"/> + <choice name="high" value="6"/> + <choice name="higher" value="7"/> + <choice name="very-high" value="8"/> + <choice name="highest" value="9"/> + </enum> + </domain> + <struct name="delivery-properties" code="0x1" size="4" pack="2"> + <field name="discard-unroutable" type="bit"/> + <field name="immediate" type="bit"/> + <field name="redelivered" type="bit"> + <rule name="implementation"/> + <rule name="hinting"/> + </field> + <field name="priority" type="delivery-priority" required="true"/> + <field name="delivery-mode" type="delivery-mode" required="true"/> + <field name="ttl" type="uint64"> + <rule name="ttl-decrement"/> + </field> + <field name="timestamp" type="datetime"/> + <field name="expiration" type="datetime"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + </struct> + <struct name="fragment-properties" code="0x2" size="4" pack="2"> + <field name="first" type="bit" default="1"/> + <field name="last" type="bit" default="1"/> + <field name="fragment-size" type="uint64"/> + </struct> + <struct name="reply-to" size="2" pack="2"> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + </struct> + <struct name="message-properties" code="0x3" size="4" pack="2"> + <field name="content-length" type="uint64"/> + <field name="message-id" type="uuid"> + <rule name="unique"/> + <rule name="immutable"/> + </field> + <field name="correlation-id" type="vbin16"/> + <field name="reply-to" type="reply-to"/> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="user-id" type="vbin16"> + <rule name="authentication"/> + </field> + <field name="app-id" type="vbin16"/> + <field name="application-headers" type="map"/> + </struct> + <domain name="flow-mode" type="uint8"> + <enum> + <choice name="credit" value="0"/> + <choice name="window" value="1"/> + </enum> + </domain> + <domain name="credit-unit" type="uint8"> + <enum> + <choice name="message" value="0"/> + <choice name="byte" value="1"/> + </enum> + </domain> + <command name="transfer" code="0x1"> + <rule name="transactional-publish"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <rule name="blank-destination"/> + <exception name="nonexistent-exchange" error-code="not-found"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <segments> + <header> + <entry type="delivery-properties"/> + <entry type="fragment-properties"/> + <entry type="message-properties"/> + </header> + <body/> + </segments> + </command> + <command name="accept" code="0x2"> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + </command> + <command name="reject" code="0x3"> + <rule name="alternate-exchange"/> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="code" type="reject-code" required="true"/> + <field name="text" type="str8"/> + </command> + <command name="release" code="0x4"> + <rule name="ordering"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="set-redelivered" type="bit"/> + </command> + <command name="acquire" code="0x5"> + <rule name="one-to-one"/> + <implement role="server" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <result> + <struct name="acquired" code="0x4" size="4" pack="2"> + <field name="transfers" type="session.commands" required="true"/> + </struct> + </result> + </command> + <command name="resume" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <exception name="destination-not-found" error-code="not-found"/> + </field> + <field name="resume-id" type="resume-id" required="true"> + <rule name="unknown-resume-id"/> + </field> + <result> + <struct name="message-resume-result" code="0x5" size="4" pack="2"> + <field name="offset" type="uint64"/> + </struct> + </result> + </command> + <command name="subscribe" code="0x7"> + <rule name="simultaneous-subscriptions"/> + <rule name="default-flow-mode"/> + <exception name="queue-deletion" error-code="resource-deleted"/> + <exception name="queue-not-found" error-code="not-found"/> + <rule name="initial-credit"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"/> + <field name="destination" type="destination"> + <exception name="unique-subscriber-destination" error-code="not-allowed"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + <field name="arguments" type="map"/> + </command> + <command name="cancel" code="0x8"> + <rule name="post-cancel-transfer-resolution"/> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination" required="true"> + <exception name="subscription-not-found" error-code="not-found"/> + </field> + </command> + <command name="set-flow-mode" code="0x9"> + <rule name="byte-accounting"/> + <rule name="mode-switching"/> + <rule name="default-flow-mode"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="flow-mode" type="flow-mode" required="true"/> + </command> + <command name="flow" code="0xa"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="unit" type="credit-unit" required="true"/> + <field name="value" type="uint32"/> + </command> + <command name="flush" code="0xb"> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + <command name="stop" code="0xc"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + </class> + <class name="tx" code="0x5"> + <rule name="duplicate-tracking"/> + <role name="server" implement="SHOULD"/> + <command name="select" code="0x1"> + <exception name="exactly-once" error-code="illegal-state"/> + <exception name="no-dtx" error-code="illegal-state"/> + <exception name="explicit-accepts" error-code="not-allowed"/> + <implement role="server" handle="MUST"/> + </command> + <command name="commit" code="0x2"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + <command name="rollback" code="0x3"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + </class> + <class name="dtx" code="0x6"> + <rule name="transactionality"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <domain name="xa-status" type="uint16"> + <enum> + <choice name="xa-ok" value="0"/> + <choice name="xa-rbrollback" value="1"/> + <choice name="xa-rbtimeout" value="2"/> + <choice name="xa-heurhaz" value="3"/> + <choice name="xa-heurcom" value="4"/> + <choice name="xa-heurrb" value="5"/> + <choice name="xa-heurmix" value="6"/> + <choice name="xa-rdonly" value="7"/> + </enum> + </domain> + <struct name="xa-result" code="0x1" size="4" pack="2"> + <field name="status" type="xa-status" required="true"/> + </struct> + <struct name="xid" code="0x4" size="4" pack="2"> + <field name="format" type="uint32" required="true"/> + <field name="global-id" type="vbin8" required="true"/> + <field name="branch-id" type="vbin8" required="true"/> + </struct> + <command name="select" code="0x1"> + <implement role="server" handle="MAY"/> + </command> + <command name="start" code="0x2"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="already-known" error-code="not-allowed"/> + <exception name="join-and-resume" error-code="not-allowed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-allowed"/> + </field> + <field name="join" type="bit"> + <exception name="unsupported" error-code="not-implemented"/> + </field> + <field name="resume" type="bit"/> + <result type="xa-result"/> + </command> + <command name="end" code="0x3"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="suspend-and-fail" error-code="not-allowed"/> + <rule name="success"/> + <rule name="session-closed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="not-associated" error-code="illegal-state"/> + </field> + <field name="fail" type="bit"> + <rule name="failure"/> + </field> + <field name="suspend" type="bit"> + <rule name="resume"/> + </field> + <result type="xa-result"/> + </command> + <command name="commit" code="0x4"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <field name="one-phase" type="bit"> + <exception name="one-phase" error-code="illegal-state"/> + <exception name="two-phase" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="forget" code="0x5"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + </command> + <command name="get-timeout" code="0x6"> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <result> + <struct name="get-timeout-result" code="0x2" size="4" pack="2"> + <field name="timeout" type="uint32" required="true"/> + </struct> + </result> + </command> + <command name="prepare" code="0x7"> + <exception name="illegal-state" error-code="illegal-state"/> + <rule name="obligation-1"/> + <rule name="obligation-2"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="recover" code="0x8"> + <implement role="server" handle="MAY"/> + <result> + <struct name="recover-result" code="0x3" size="4" pack="2"> + <field name="in-doubt" type="array" required="true"/> + </struct> + </result> + </command> + <command name="rollback" code="0x9"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="set-timeout" code="0xa"> + <rule name="effective"/> + <rule name="reset"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <field name="timeout" type="uint32" required="true"/> + </command> + </class> + <class name="exchange" code="0x7"> + <rule name="required-types"/> + <rule name="recommended-types"/> + <rule name="required-instances"/> + <rule name="default-exchange"/> + <rule name="default-access"/> + <rule name="extensions"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="minimum"/> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="reserved-names" error-code="not-allowed"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="type" type="str8" required="true"> + <exception name="typed" error-code="not-allowed"/> + <exception name="exchange-type-not-found" error-code="not-found"/> + </field> + <field name="alternate-exchange" type="name"> + <rule name="empty-name"/> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <rule name="double-failure"/> + </field> + <field name="passive" type="bit"> + <exception name="not-found" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="support"/> + <rule name="sticky"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="sticky"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="exists" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + <exception name="used-as-alternate" error-code="not-allowed"/> + </field> + <field name="if-unused" type="bit"> + <exception name="exchange-in-use" error-code="precondition-failed"/> + </field> + </command> + <command name="query" code="0x3"> + <implement role="server" handle="MUST"/> + <field name="name" type="str8"/> + <result> + <struct name="exchange-query-result" code="0x1" size="4" pack="2"> + <field name="type" type="str8"/> + <field name="durable" type="bit"/> + <field name="not-found" type="bit"/> + <field name="arguments" type="map"/> + </struct> + </result> + </command> + <command name="bind" code="0x4"> + <rule name="duplicates"/> + <rule name="durable-exchange"/> + <rule name="binding-count"/> + <rule name="multiple-bindings"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="empty-queue" error-code="invalid-argument"/> + <exception name="queue-existence" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="exchange-existence" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"/> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="unbind" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="non-existent-queue" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="non-existent-exchange" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"> + <exception name="non-existent-binding-key" error-code="not-found"/> + </field> + </command> + <command name="bound" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="str8"/> + <field name="queue" type="str8" required="true"/> + <field name="binding-key" type="str8"/> + <field name="arguments" type="map"/> + <result> + <struct name="exchange-bound-result" code="0x2" size="4" pack="2"> + <field name="exchange-not-found" type="bit"/> + <field name="queue-not-found" type="bit"/> + <field name="queue-not-matched" type="bit"/> + <field name="key-not-matched" type="bit"/> + <field name="args-not-matched" type="bit"/> + </struct> + </result> + </command> + </class> + <class name="queue" code="0x8"> + <rule name="any-content"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="default-binding"/> + <rule name="minimum-queues"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="reserved-prefix" error-code="not-allowed"/> + </field> + <field name="alternate-exchange" type="exchange.name"> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <exception name="unknown-exchange" error-code="not-found"/> + </field> + <field name="passive" type="bit"> + <exception name="passive" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="persistence"/> + <rule name="types"/> + <rule name="pre-existence"/> + </field> + <field name="exclusive" type="bit"> + <rule name="types"/> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="pre-existence"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + <field name="if-unused" type="bit"> + <exception name="if-unused-flag" error-code="precondition-failed"/> + </field> + <field name="if-empty" type="bit"> + <exception name="not-empty" error-code="precondition-failed"/> + </field> + </command> + <command name="purge" code="0x3"> + <rule name="empty"/> + <rule name="pending-messages"/> + <rule name="purge-recovery"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + </command> + <command name="query" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"/> + <result> + <struct name="queue-query-result" code="0x1" size="4" pack="2"> + <field name="queue" type="name" required="true"/> + <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" required="true"/> + <field name="subscriber-count" type="uint32" required="true"/> + </struct> + </result> + </command> + </class> + <class name="file" code="0x9"> + <rule name="reliable-storage"/> + <rule name="no-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="file-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="reply-to" type="str8"/> + <field name="message-id" type="str8"/> + <field name="filename" type="str8"/> + <field name="timestamp" type="datetime"/> + <field name="cluster-id" type="str8"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"> + <rule name="prefetch-discretion"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="no-ack" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="open" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="open-ok"/> + <field name="identifier" type="str8"/> + <field name="content-size" type="uint64"> + <rule name="content-size"/> + </field> + </command> + <command name="open-ok" code="0x7"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="stage"/> + <field name="staged-size" type="uint64"> + <rule name="behavior"/> + <rule name="staging"/> + </field> + </command> + <command name="stage" code="0x8"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="publish" code="0x9"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <field name="identifier" type="str8"/> + </command> + <command name="return" code="0xa"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0xb"> + <rule name="redelivery-tracking"/> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="non-zero"/> + </field> + <field name="redelivered" type="bit"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="identifier" type="str8"/> + </command> + <command name="ack" code="0xc"> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="multiple" type="bit"> + <rule name="validation"/> + </field> + </command> + <command name="reject" code="0xd"> + <rule name="server-interpretation"/> + <rule name="not-selection"/> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="requeue" type="bit"> + <rule name="requeue-strategy"/> + </field> + </command> + </class> + <class name="stream" code="0xa"> + <rule name="overflow-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="stream-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="timestamp" type="datetime"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"/> + <field name="consume-rate" type="uint32"> + <rule name="ignore-prefetch"/> + <rule name="drop-by-priority"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <rule name="priority-based-delivery"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="publish" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="return" code="0x7"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="exchange" type="exchange.name"/> + <field name="queue" type="queue.name" required="true"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + </class> +</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-10-qpid-errata.xml b/qpid/python/qpid/specs/amqp-0-10-qpid-errata.xml deleted file mode 100644 index d0d9486fef..0000000000 --- a/qpid/python/qpid/specs/amqp-0-10-qpid-errata.xml +++ /dev/null @@ -1,6654 +0,0 @@ -<?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-0-10.dtd"> - -<amqp xmlns="http://www.amqp.org/schema/amqp.xsd" - major="0" minor="10" port="5672"> - - <!-- - ====================== == 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> - - <!-- - 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="byte-ranges" variable-width="2" label="byte ranges within a 64-bit payload"> - <doc> - The byte-ranges type encodes up to 65535 octets worth of non-overlapping, non-touching, - ascending byte ranges within a 64-bit sequence of bytes. Each range is represented as an - inclusive lower and upper bound that identifies all the byte offsets included within a given - range. - </doc> - - <doc> - The number of octets of data is first encoded as a 16-bit unsigned integral value in network - byte order. This is then followed by the encoded representation of the ranges included in the - set. These MUST be encoded in ascending order, and any two ranges included in a given set MUST - NOT include overlapping or touching byte offsets. - </doc> - - <doc> - Each range is encoded as a pair of 64-bit unsigned integral values in network byte order - respectively representing the lower and upper bounds for that range. Note that because each - range is exactly 16 octets, the size in octets of the encoded ranges will always be 16 times - the number of ranges in the set. - </doc> - - <doc type="picture" title="Wire Format"> - +----= size OCTETs =----+ - | | - 2 OCTETs | 16 OCTETs | - +----------+-----+-----------+-----+ - | size | .../| range |\... | - +----------+---/ +-----------+ \---+ - uint16 / / \ \ - / / \ \ - / 8 OCTETs 8 OCTETs \ - +-----------+-----------+ - | lower | upper | - +-----------+-----------+ - uint64 uint64 - </doc> - - <doc type="bnf"> - byte-ranges = size *range - size = uint16 - range = lower upper - lower = uint64 - upper = uint64 - </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> - - <!-- Tracks --> - - <domain name="track" type="uint8" label="Valid values for transport level tracks"> - <doc> Tracks are defined in <xref ref="specification.transport.channels_and_tracks"/>. The - track domain defines the valid values that may used for the track indicator within the frame - header</doc> - <enum> - <choice name="control" value="0"> - <doc> - The track used for all controls. All controls defined in this specification MUST be sent - on track 0. - </doc> - </choice> - <choice name="command" value="1"> - <doc> - The track used for all commands. All commands defined in this specification MUST be sent - on track 1. - </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 a client to establish a network connection to a - server, and for both peers to operate the connection thereafter. - </doc> - - <doc type="grammar"> - connection = open-connection - *use-connection - close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <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="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> - - <!-- - Control: connection.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="start" code="0x1" label="start connection negotiation"> - <doc> - This control starts the connection negotiation process by telling the client the supported - security mechanisms and locales from which the client can choose. - </doc> - - <rule name="protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, it MUST close - the socket connection without sending any response 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> - - <implement role="client" handle="MUST" /> - - <response name="start-ok" /> - - <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> - - <field name="mechanisms" type="str16-array" label="available security mechanisms" - required="true"> - <doc> - A list of the security mechanisms that the server supports. - </doc> - </field> - - <field name="locales" type="str16-array" label="available message locales" required="true"> - <doc> - A list of the message locales that the server supports. The locale defines the language in - which the server will send reply texts. - </doc> - - <rule name="required-support"> - <doc> - The server MUST support at least the en_US locale. - </doc> - <doc type="scenario"> - Client connects to server and inspects the locales field. It checks for the presence of - the required locale(s). - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="start-ok" code="0x2" label="select security mechanism and locale"> - <doc> - This control selects a SASL security mechanism. - </doc> - - <implement role="server" handle="MUST" /> - - <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="mechanism" type="str8" label="selected security mechanism" required="true"> - <doc> - A single security mechanisms selected by the client, which must be one of those specified - by the server. - </doc> - - <rule name="security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it can handle - from the list provided by the server. - </doc> - </rule> - - <rule name="validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms proposed by the - server in the Start control, the server MUST close the connection without sending any - further data. - </doc> - <doc type="scenario"> - Client connects to server and sends an invalid security mechanism. The server must - respond by closing the connection (a socket close, with no connection close - negotiation). - </doc> - </rule> - </field> - - <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> - - <field name="locale" type="str8" label="selected message locale" required="true"> - <doc> - A single message locale selected by the client, which must be one of those specified by - the server. - </doc> - </field> - </control> - - <!-- - Control: connection.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="secure" code="0x3" label="security mechanism challenge"> - <doc> - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This control challenges the - client to provide more information. - </doc> - - <implement role="client" handle="MUST" /> - - <response name="secure-ok" /> - - <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.secure-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="secure-ok" 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.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="tune" code="0x5" label="propose connection tuning parameters"> - <doc> - This control proposes a set of connection configuration values to the client. The client can - accept and/or adjust these. - </doc> - - <implement role="client" handle="MUST" /> - - <response name="tune-ok" /> - - <field name="channel-max" type="uint16" label="proposed maximum channels"> - <doc> - The maximum total number of channels that the server allows per connection. If this is not - set it means that the server does not impose a fixed limit, but the number of allowed - channels may be limited by available server resources. - </doc> - </field> - - <field name="max-frame-size" type="uint16" label="proposed maximum frame size"> - <doc> - The largest frame size that the server proposes for the connection. The client can - negotiate a lower value. If this is not set means that the server does not impose any - specific limit but may reject very large frames if it cannot allocate resources for them. - </doc> - - <rule name="minimum"> - <doc> - Until the max-frame-size has been negotiated, both peers MUST accept frames of up to - MIN-MAX-FRAME-SIZE octets large, and the minimum negotiated value for max-frame-size is - also MIN-MAX-FRAME-SIZE. - </doc> - <doc type="scenario"> - Client connects to server and sends a large properties field, creating a frame of - MIN-MAX-FRAME-SIZE octets. The server must accept this frame. - </doc> - </rule> - </field> - - <field name="heartbeat-min" type="uint16" label="the minimum supported heartbeat delay"> - <doc> - The minimum delay, in seconds, of the connection heartbeat supported by the server. If - this is not set it means the server does not support sending heartbeats. - </doc> - </field> - - <field name="heartbeat-max" type="uint16" label="the maximum supported heartbeat delay"> - <doc> - The maximum delay, in seconds, of the connection heartbeat supported by the server. If - this is not set it means the server has no maximum. - </doc> - - <rule name="permitted-range"> - <doc> - The heartbeat-max value must be greater than or equal to the value supplied in the - heartbeat-min field. - </doc> - </rule> - - <rule name="no-heartbeat-min"> - <doc> - If no heartbeat-min is supplied, then the heartbeat-max field MUST remain empty. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.tune-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="tune-ok" code="0x6" label="negotiate connection tuning parameters"> - <doc> - This control sends the client's connection tuning parameters to the server. Certain fields - are negotiated, others provide capability information. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="channel-max" type="uint16" label="negotiated maximum channels" required="true"> - <doc> - The maximum total number of channels that the client will use per connection. - </doc> - - <rule name="upper-limit"> - <doc> - If the client specifies a channel max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementers. - </doc> - - </rule> - - <rule name="available-channels"> - <doc> - If the client agrees to a channel-max of N channels, then the channels available for - communication between client and server are precisely the channels numbered 0 to (N-1). - </doc> - </rule> - </field> - - <field name="max-frame-size" type="uint16" label="negotiated maximum frame size"> - <doc> - The largest frame size that the client and server will use for the connection. If it is - not set means that the client does not impose any specific limit but may reject very large - frames if it cannot allocate resources for them. Note that the max-frame-size limit - applies principally to content frames, where large contents can be broken into frames of - arbitrary size. - </doc> - - <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, and the minimum negotiated value for max-frame-size is - also MIN-MAX-FRAME-SIZE. - </doc> - </rule> - - <rule name="upper-limit"> - <doc> - If the client specifies a max-frame-size that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementers. - </doc> - </rule> - - <rule name="max-frame-size"> - <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="heartbeat" type="uint16" label="negotiated heartbeat delay"> - <doc> - The delay, in seconds, of the connection heartbeat chosen by the client. If it is not set - it means the client does not want a heartbeat. - </doc> - - <rule name="permitted-range"> - <doc> - The chosen heartbeat MUST be in the range supplied by the heartbeat-min and - heartbeat-max fields of connection.tune. - </doc> - </rule> - - <rule name="no-heartbeat-min"> - <doc> - The heartbeat field MUST NOT be set if the heartbeat-min field of connection.tune was - not set by the server. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open" code="0x7" label="open connection to 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" /> - - <response name="open-ok" /> - <response name="redirect" /> - - <field name="virtual-host" type="str8" label="virtual host name" required="true"> - <doc> - The name of the virtual host to work with. - </doc> - - <rule name="separation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full separation of - exchanges, queues, and all associated entities per virtual host. An application, - connected to a specific virtual host, MUST NOT be able to access resources of another - virtual host. - </doc> - </rule> - - <rule name="security"> - <doc> - The server SHOULD verify that the client has permission to access the specified virtual - host. - </doc> - </rule> - </field> - - <field name="capabilities" type="str16-array" label="required capabilities"> - <doc> - The client can specify zero or more capability names. The server can use this to determine - how to process the client's connection request. - </doc> - </field> - - <field name="insist" type="bit" label="insist on connecting to server"> - <doc> - In a configuration with multiple collaborating servers, the server may respond to a - connection.open control with a Connection.Redirect. The insist option tells the server - that the client is insisting on a connection to the specified server. - </doc> - <rule name="behavior"> - <doc> - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect control. If it cannot accept the client's connection request it - should respond by closing the connection with a suitable reply code. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open-ok" code="0x8" label="signal that connection is ready"> - <doc> - This control signals to the client that the connection is ready for use. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="known-hosts" type="amqp-host-array" label="alternate hosts which may be used in - the case of failure"> - <doc> - Specifies an array of equivalent or alternative hosts that the server knows about, which - will normally include the current server itself. Each entry in the array will be in the - form of an IP address or DNS name, optionally followed by a colon and a port number. - Clients can cache this information and use it when reconnecting to a server after a - failure. This field may be empty. - </doc> - </field> - </control> - - <!-- - Control: connection.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="redirect" code="0x9" label="redirects client to other server"> - <doc> - This control redirects the client to another server, based on the requested virtual host - and/or capabilities. - </doc> - - <rule name="usage"> - <doc> - When getting the connection.redirect control, the client SHOULD reconnect to the host - specified, and if that host is not present, to any of the hosts specified in the - known-hosts list. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - - <field name="host" type="amqp-host-url" label="server to connect to" required="true"> - <doc> - Specifies the server to connect to. - </doc> - </field> - - <field name="known-hosts" type="amqp-host-array" label="alternate hosts to try in case of - failure"> - <doc> - An array of equivalent or alternative hosts that the server knows about. - </doc> - </field> - </control> - - <!-- - Control: connection.heartbeat - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="heartbeat" code="0xa" 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> - <implement role="client" handle="MAY" /> - <implement role="server" handle="MAY" /> - </control> - - <!-- - Control: connection.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="close" code="0xb" 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" /> - - <response name="close-ok" /> - - <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> - - <!-- - Control: connection.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="close-ok" code="0xc" label="confirm a connection close"> - <doc> - This control confirms a connection.close control and tells the recipient that it is safe to - release resources for the connection and close the socket. - </doc> - - <rule name="reporting"> - <doc> - A peer that detects a socket closure without having received a Close-Ok handshake control - SHOULD log the error. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - <implement role="server" handle="MUST" /> - </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> - 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="header" size="1" pack="1"> - <doc> - The session header appears on commands after the class and command id, but prior to command - arguments. - </doc> - - <field name="sync" type="bit" label="request notification of completion"> - <doc> - Request notification of completion for this command. - </doc> - </field> - </struct> - - <struct name="command-fragment" size="0" pack="0" label="byte-ranges within a set of commands"> - - <field name="command-id" type="sequence-no" required="true"> - - </field> - <field name="byte-ranges" type="byte-ranges" required="true"> - - </field> - </struct> - - <domain name="command-fragments" type="array" label="an array of values of type - command-fragment"/> - - <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="MAY" /> - - <response name="attached"/> - <response name="detached"/> - - <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> - </control> - - <control name="attached" code="0x2" label="confirm attachment to the named session"> - <doc> - Confirms successful attachment of the transport to the named session. - </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 session now attached to the current transport. - </doc> - </field> - </control> - - <control name="detach" code="0x3" label="detach from the named session"> - <doc> - Detaches the current transport from the named session. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="detached"/> - - <field name="name" type="name" label="the session name" required="true"> - <doc> - Identifies the session to detach. - </doc> - </field> - </control> - - <control name="detached" code="0x4" label="confirm detachment from the named session"> - <doc> - Confirms detachment of the current transport from the named session. - </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> - </control> - - <!-- - Execution state is the set of confirmed, and completed incoming commands, as well as the set - of outgoing in-doubt commands held for replay. - --> - - <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> - - <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"/> - <field name="command-offset" type="uint64" label="the byte offset within the command" - required="true"/> - </control> - - <control name="expected" code="0x8" label="informs the peer of expected commands"> - <doc> - This control is sent by the receiver of commands and handled by the sender of commands. It - informs the sender of what commands and command fragments are expected at the receiver. - This control is only sent in response to a flush control with the expected flag set. The - expected control is never sent spontaneously. - </doc> - - <rule name="include-next-command"> - <doc> - The set of expected commands MUST include the next command after the highest seen command. - </doc> - </rule> - - <rule name="commands-empty-means-new-session"> - <doc> - The set of expected commands MUST have zero elements if and only if the sender holds no - execution state for the session (i.e. it is a new session). - </doc> - </rule> - - <rule name="no-overlaps"> - <doc> - If a command-id appears in the commands field, it MUST NOT appear in the fragments field. - </doc> - </rule> - - <rule name="minimal-fragments"> - <doc> - When choice is permitted, a command MUST appear in the commands field rather than the - fragments field. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="expected commands" required="true"/> - <field name="fragments" type="command-fragments" label="expected fragments" /> - </control> - - <control name="confirmed" code="0x9" label="notifies of confirmed commands"> - <doc> - This control is sent by the receiver of commands and handled by the sender of commands. This - sends the set of commands that will definitely be completed by this peer to the sender. This - excludes commands known by the receiver to be considered confirmed or complete at the - sender. - </doc> - <doc> - This control must be sent if the partner requests the set of confirmed commands using the - session.flush control with the confirmed flag set. - </doc> - <doc> - This control may be sent spontaneously. One reason for separating confirmation from - completion is for large persistent messages, where the receipt (and storage to a durable - store) of part of the message will result in less data needing to be replayed in the case of - transport failure during transmission. - </doc> - <doc> - A simple implementation of an AMQP client or server may be implemented to take no action on - receipt of session.confirmed controls, and take action only when receiving - session.completed controls. - </doc> - <doc> - A simple implementation of an AMQP client or server may be implemented such that it never - spontaneously sends session.confirmed and that when requested for the set of confirmed - commands (via the session.flush control) it responds with the same set of commands as it - would to when the set of completed commands was requested (trivially all completed commands - are confirmed). - </doc> - - <rule name="durability"> - <doc> - If a command has durable implications, it MUST NOT be confirmed until the fact of the - command has been recorded on durable media. - </doc> - </rule> - - <rule name="no-overlaps"> - <doc> - If a command-id appears in the commands field, it MUST NOT appear in the fragments field. - </doc> - </rule> - - <rule name="minimal-fragments"> - <doc> - When choice is permitted, a command MUST appear in the commands field rather than the - fragments field. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="entirely confirmed commands"> - <rule name="exclude-known-complete"> - <doc> - Command-ids included in prior known-complete replies MUST be excluded from the set of - all confirmed commands. - </doc> - </rule> - </field> - <field name="fragments" type="command-fragments" label="partially confirmed commands"/> - </control> - - <control name="completed" code="0xa" label="notifies of command completion"> - <doc> - This control is sent by the receiver of commands, and handled by the sender of commands. It - informs the sender of all commands completed by the receiver. This excludes commands known - by the receiver to be considered complete at the sender. - </doc> - - <rule name="known-completed-reply"> - <doc> - The sender MUST eventually reply with a known-completed set that covers the completed ids. - </doc> - </rule> - - <rule name="delayed-reply"> - <doc> - The known-complete reply MAY be delayed at the senders discretion if the timely-reply - field is not set. - </doc> - </rule> - - <rule name="merged-reply"> - <doc> - Multiple replies may be merged by sending a single known-completed that includes the union - of the merged command-id sets. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="completed commands"> - <doc> - The ids of all completed commands. This excludes commands known by the receiver to be - considered complete at the sender. - </doc> - - <rule name="completed-implies-confirmed"> - <doc> - The sender MUST consider any completed commands to also be confirmed. - </doc> - </rule> - - <rule name="exclude-known-complete"> - <doc> - Command-ids included in prior known-complete replies MUST be excluded from the set of - all completed commands. - </doc> - </rule> - </field> - <field name="timely-reply" type="bit"> - <doc> - If set, the sender is no longer free to delay the known-completed reply. - </doc> - </field> - </control> - - <control name="known-completed" code="0xb" label="Inform peer of which commands are known to be - completed"> - <doc> - This control is sent by the sender of commands, and handled by the receiver of commands. It - is sent in reply to one or more completed controls from the receiver. It informs the - receiver that commands are known to be completed by the sender. - </doc> - - <rule name="stateless"> - <doc> - The sender need not keep state to generate this reply. It is sufficient to reply to any - completed control with an exact echo of the completed ids. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="commands" type="commands" label="commands known to be complete"> - <doc> - The set of completed commands for one or more session.completed controls. - </doc> - - <rule name="known-completed-implies-known-confirmed"> - <doc> - The receiver MUST treat any of the specified commands to be considered by the sender as - confirmed as well as completed. - </doc> - </rule> - </field> - </control> - - <control name="flush" code="0xc" label="requests a session.completed"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. It - requests that the receiver produce the indicated command sets. The receiver should issue the - indicated sets at the earliest possible opportunity. - </doc> - - <implement role="receiver" handle="MUST" /> - - <field name="expected" type="bit" label="request notification of expected commands"/> - <field name="confirmed" type="bit" label="request notification of confirmed commands"/> - <field name="completed" type="bit" label="request notification of completed commands"/> - </control> - - <control name="gap" code="0xd" label="indicates missing segments in the stream"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. It - sends command ranges for which there will be no further data forthcoming. The receiver - should proceed with the next available commands that arrive after the gap. - </doc> - - <rule name="gap-confirmation-and-completion"> - <doc> - The command-ids covered by a session.gap MUST be added to the completed and confirmed sets - by the receiver. - </doc> - </rule> - - <rule name="aborted-commands"> - <doc> - If a session.gap covers a partially received command, the receiving peer MUST treat the - command as aborted. - </doc> - </rule> - - <rule name="completed-or-confirmed-commands"> - <doc> - If a session.gap covers a completed or confirmed command, the receiving peer MUST continue - to treat the command as completed or confirmed. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="commands" type="commands"> - <doc> - The set of command-ids that are contained in this gap. - </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="0x1" 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="0x2" 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> - - <!-- - Command: execution.exception - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="exception" code="0x3" 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> - - <implement role="client" handle="MUST"/> - <implement role="server" handle="MUST"/> - - <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"/> - - </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="destination" type="str8" label="destination for a message"> - <doc> - Specifies the destination to which the message is to be transferred. - </doc> - </domain> - - <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> - <choice name="immediate" value="2"> - <doc> - The rejected message had the immediate flag set to true, but at the time of the transfer - at least one of the queues to which it was to be routed did not have any subscriber able - to take the message. - </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="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="immediate" type="bit" label="Consider message unroutable if it cannot be - processed immediately"> - <doc> - If the immediate flag is set to true on a message transferred to a Server, then the - message should be considered unroutable (and not delivered to any queues) if, for any - queue that it is to be routed to according to the standard routing behavior, there is not - a subscription on that queue able to receive the message. The treatment of unroutable - messages is dependent on the value of the discard-unroutable flag. - </doc> - <doc> - The immediate flag is ignored on transferred to a Client. - </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 when a resume-id is specified. If no resume-id is - specified then this value should be ignored. - </doc> - </field> - </struct> - - <struct name="fragment-properties" size="4" code="0x2" pack="2"> - <doc> - These properties permit the transfer of message fragments. These may be used in conjunction - with byte level flow control to limit the rate at which large messages are received. Only - the first fragment carries the delivery-properties and message-properties. - - Syntactically each fragment appears as a complete message to the lower layers of the - protocol, however the model layer is required to treat all the fragments as a single - message. For example all fragments must be delivered to the same client. In pre-acquired - mode, no message fragments can be delivered by the broker until the entire message has been - received. - </doc> - - <field name="first" type="bit" default="1"> - <doc>True if this fragment contains the start of the message, false otherwise.</doc> - </field> - - <field name="last" type="bit" default="1"> - <doc>True if this fragment contains the end of the message, false otherwise.</doc> - </field> - - <field name="fragment-size" type="uint64"> - <doc>This field may optionally contain the size of the fragment.</doc> - </field> - </struct> - - <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="uuid" 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="reply-to" label="destination to reply to"> - <doc> - The destination of any message that is sent in reply to this message. - </doc> - </field> - - <field name="content-type" 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> - - <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> - - <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> - - <domain name="credit-unit" type="uint8" label="specifies the unit of credit balance"> - <enum> - <choice name="message" value="0"> - <doc>Indicates a value specified in messages.</doc> - </choice> - <choice name="byte" value="1"> - <doc>Indicates a value specified in bytes.</doc> - </choice> - </enum> - </domain> - - <!-- - 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="destination" type="destination" label="message destination"> - <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="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> - - <segments> - <header> - <entry type="delivery-properties"/> - <entry type="fragment-properties"/> - <entry type="message-properties"/> - </header> - <body/> - </segments> - </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> - - <!-- - Command: message.resume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="resume" code="0x6" label="resume an interrupted message transfer"> - <doc> - This command resumes an interrupted transfer. The recipient should return the amount of - partially transferred data associated with the given resume-id, or zero if there is no data - at all. If a non-zero result is returned, the recipient should expect to receive message - fragment(s) containing the remainder of the interrupted message. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"> - <doc> - The destination to which the remaining message fragments are transferred. - </doc> - - <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="resume-id" type="resume-id" required="true"> - <doc> - The name of the transfer being resumed. - </doc> - - <rule name="unknown-resume-id"> - <doc>If the resume-id is not known, the recipient MUST return an offset of zero.</doc> - </rule> - </field> - - <result> - <struct name="message-resume-result" size="4" code="0x5" pack="2"> - <field name="offset" type="uint64"> - <doc> - Indicates the amount of data already transferred. - </doc> - </field> - </struct> - </result> - </command> - - <!-- - Command: message.subscribe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="subscribe" 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"/> - - <field name="queue" type="queue.name" required="true"> - <doc> Specifies the name of the subscribed queue. </doc> - </field> - - <field name="destination" type="destination" label="incoming message destination"> - <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="accept-mode" type="accept-mode" required="true"> - <doc> The accept-mode to use for messages transferred from this subscription. </doc> - </field> - - <field name="acquire-mode" type="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="resume-id"> - <doc> Requests that the broker use the supplied resume-id when transferring messages for - this subscription. </doc> - </field> - - <field name="resume-ttl" type="uint64"> - <doc> Requested duration in milliseconds for the broker use as resume-ttl when transferring - messages for this subscription. </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: message.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x8" label="end a queue subscription"> - <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> - - <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="destination" type="destination" 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: message.set-flow-mode - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="set-flow-mode" code="0x9" label="set the flow control mode"> - <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 assemblies. This means that if there is not enough byte - credit available to send a complete message, the sender must either wait or use message - fragmentation (see the fragment-properties header struct) to send the first part of the - message data in a complete assembly. - - 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.flush - 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> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - <field name="flow-mode" type="flow-mode" required="true"> - <doc> - The new flow control mode. - </doc> - </field> - </command> - - <!-- - Command: message.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 unit to the available credit balance for the specified destination. - A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for - the given unit until the credit balance is zeroed with message.stop or message.flush. - </doc> - - <!-- throws no-such-destination --> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - <field name="unit" type="credit-unit" required="true"> - <doc> - The unit of value. - </doc> - </field> - <field name="value" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - </command> - - <!-- - Command: message.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="flush" 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="destination"/> - </command> - - <!-- - Command: message.stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stop" code="0xc" 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> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - </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="4" code="0x4" 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> - - <!-- == Class: file ========================================================================== --> - - <class name="file" code="0x9" label="work with file content"> - <doc> - The file class provides commands that support reliable file transfer. File messages have a - specific set of properties that are required for interoperability with file transfer - applications. File messages and acknowledgements are subject to session transactions. Note - that the file class does not provide message browsing commands; these are not compatible with - the staging model. Applications that need browsable file transfer should use Message content - and the Message class. - </doc> - - <doc type="grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - </doc> - - <rule name="reliable-storage"> - <doc> - The server MUST make a best-effort to hold file messages on a reliable storage mechanism. - </doc> - </rule> - - <rule name="no-discard"> - <doc> - The server MUST NOT discard a file message in case of a queue overflow. The server MUST use - the Session.Flow command to slow or stop a file message publisher when necessary. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for file messages, where priorities 0-4 - and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST support both automatic and explicit acknowledgements on file content. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- These are the properties for a File content --> - <struct name="file-properties" size="4" code="0x1" pack="2"> - <field name="content-type" type="str8" label="MIME content type" /> - <field name="content-encoding" type="str8" label="MIME content encoding" /> - <field name="headers" type="map" label="message header field table" /> - <field name="priority" type="uint8" label="message priority, 0 to 9" /> - <field name="reply-to" type="str8" label="destination to reply to" /> - <field name="message-id" type="str8" label="application message identifier" /> - <field name="filename" type="str8" label="message filename" /> - <field name="timestamp" type="datetime" label="message timestamp" /> - <!-- This field is deprecated pending review --> - <field name="cluster-id" type="str8" label="intra-cluster routing identifier" /> - </struct> - - <domain name="return-code" type="uint16" label="return code from server"> - <doc> - The return code. The AMQP return codes are defined by this enum. - </doc> - <enum> - <choice name="content-too-large" value="311"> - <doc> - The client attempted to transfer content larger than the server could accept. - </doc> - </choice> - - <choice name="no-route" value="312"> - <doc> - The exchange cannot route a message, most likely due to an invalid routing key. Only - when the mandatory flag is set. - </doc> - </choice> - - <choice name="no-consumers" value="313"> - <doc> - The exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: file.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos" code="0x1" label="specify quality of service"> - <doc> - This command requests a specific quality of service. The QoS can be specified for the - current session or for all sessions on the connection. The particular properties and - semantics of a qos command always depend on the content class semantics. Though the qos - command could in principle apply to both peers, it is currently meaningful only for the - server. - </doc> - - <implement role="server" handle="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" type="uint32" label="pre-fetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Pre-fetching gives a performance improvement. This field - specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other pre-fetch limits may still apply. The prefetch-size is ignored if - the no-ack option is set. - </doc> - </field> - - <field name="prefetch-count" type="uint16" label="pre-fetch window in messages"> - <doc> - Specifies a pre-fetch window in terms of whole messages. This is compatible with some file - API implementations. This field may be used in combination with the prefetch-size field; a - message will only be sent in advance if both pre-fetch windows (and those at the session - and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name="prefetch-discretion"> - <doc> - The server MAY send less data in advance than allowed by the client's specified - pre-fetch windows but it MUST NOT send more. - </doc> - </rule> - </field> - - <field name="global" type="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </command> - - <!-- - Command: file.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos-ok" code="0x2" label="confirm the requested qos"> - <doc> - This command tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <implement role="client" handle="MUST" /> - </command> - - <!-- - Command: file.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume" code="0x3" label="start a queue consumer"> - <doc> - This command asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the session they were created on, - or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <response name="consume-ok" /> - - <field name="queue" type="queue.name"> - <doc> - Specifies the name of the queue to consume from. - </doc> - - <exception name="queue-exists-if-empty" error-code="not-allowed"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="consumer-tag" type="str8"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. - </doc> - - <exception name="not-existing-consumer" error-code="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-empty-consumer-tag" error-code="not-allowed"> - <doc> - The client MUST NOT specify a tag that is empty or blank. - </doc> - <doc type="scenario"> - Attempt to create a consumers with an empty tag. - </doc> - </exception> - </field> - - <field name="no-local" type="bit"> - <doc>If the no-local field is set the server will not send messages to the connection that - published them.</doc> - </field> - - <field name="no-ack" type="bit" label="no acknowledgement needed"> - <doc> - If this field is set the server does not expect acknowledgements for messages. That is, - when a message is delivered to the client the server automatically and silently - acknowledges it on behalf of the client. This functionality increases performance but at - the cost of reliability. Messages can get lost if a client dies before it can deliver them - to the application. - </doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise an exception. - </doc> - </exception> - </field> - - <field name="nowait" type="bit" label="do not send a reply command"> - <doc> - If set, the server will not respond to the command. The client should not wait for a reply - command. If the server could not complete the command it will raise an exception. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </command> - - <command name="consume-ok" code="0x4" label="confirm a new consumer"> - <doc> - This command provides the client with a consumer tag which it MUST use in commands that work - with the consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </command> - - <!-- - Command: file.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x5" label="end a queue consumer"> - <doc> - This command cancels a consumer. This does not affect already delivered messages, but it - does mean the server will not send any more messages for that consumer. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - the identifier of the consumer to be cancelled. - </doc> - </field> - </command> - - <!-- - Command: file.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="open" code="0x6" label="request to start staging"> - <doc> - This command requests permission to start staging a message. Staging means sending the - message into a temporary area at the recipient end and then delivering the message by - referring to this temporary area. Staging is how the protocol handles partial file transfers - - if a message is partially staged and the connection breaks, the next time the sender - starts to stage it, it can restart from where it left off. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="open-ok" /> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier. This is an arbitrary string chosen by the sender. For - staging to work correctly the sender must use the same staging identifier when staging the - same message a second time after recovery from a failure. A good choice for the staging - identifier would be the SHA1 hash of the message properties data (including the original - filename, revised time, etc.). - </doc> - </field> - - <field name="content-size" type="uint64" label="message content size"> - <doc> - The size of the content in octets. The recipient may use this information to allocate or - check available space in advance, to avoid "disk full" errors during staging of very large - messages. - </doc> - - <rule name="content-size"> - <doc> - The sender MUST accurately fill the content-size field. Zero-length content is - permitted. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="open-ok" code="0x7" label="confirm staging ready"> - <doc> - This command confirms that the recipient is ready to accept staged data. If the message was - already partially-staged at a previous time the recipient will report the number of octets - already staged. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="stage" /> - - <field name="staged-size" type="uint64" label="already staged amount"> - <doc> - The amount of previously-staged content in octets. For a new message this will be zero. - </doc> - - <rule name="behavior"> - <doc> - The sender MUST start sending data from this octet offset in the message, counting from - zero. - </doc> - </rule> - - <rule name="staging"> - <doc> - The recipient MAY decide how long to hold partially-staged content and MAY implement - staging by always discarding partially-staged content. However if it uses the file - content type it MUST support the staging commands. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.stage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stage" code="0x8" label="stage message content"> - <doc> - This command stages the message, sending the message content to the recipient from the octet - offset specified in the Open-Ok command. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <segments> - <header required="true"> - <entry type="file-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: file.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="publish" code="0x9" label="publish a message"> - <doc> - This command publishes a staged file message to a specific exchange. The file message will - be routed to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise an exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <exception name="refusal" error-code="not-implemented"> - <doc> - The exchange MAY refuse file content in which case it MUST send an exception. - </doc> - </exception> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" type="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return command. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" type="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return command. If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier of the message to publish. The message must have been - staged. Note that a client can send the Publish command asynchronously without waiting for - staging to finish. - </doc> - </field> - </command> - - <!-- - Command: file.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="return" code="0xa" label="return a failed message"> - <doc> - This command returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="reply-code" type="return-code" /> - - <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> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="file-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: file.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="deliver" code="0xb" label="notify the client of a consumer message"> - <doc> - This command delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the consume command, - then the server responds with Deliver commands as and when messages arrive for that - consumer. - </doc> - - <rule name="redelivery-tracking"> - <doc> - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be non-processable (possibly - causing client applications to abort), and move the message to a dead letter queue. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - - <field name="delivery-tag" type="uint64" > - <doc> - The server-assigned and session-specific delivery tag - </doc> - - <rule name="non-zero"> - <doc> - The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, - meaning "all messages so far received". - </doc> - </rule> - </field> - - <field name="redelivered" type="bit" label="Indicate possible duplicate delivery"> - <doc> - This boolean flag indicates that the message may have been previously delivered to this - or another client. - </doc> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier of the message to deliver. The message must have been - staged. Note that a server can send the Deliver command asynchronously without waiting for - staging to finish. - </doc> - </field> - </command> - - <!-- - Command: file.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="ack" code="0xc" label="acknowledge one or more messages"> - <doc> - This command acknowledges one or more messages delivered via the Deliver command. The client - can ask to confirm a single message or a set of messages up to and including a specific - message. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="delivery-tag" type="uint64" > - <doc> - The identifier of the message being acknowledged - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then acknowledge it on - another. - </doc> - </rule> - </field> - - <field name="multiple" type="bit" label="acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages with a single command. If set to zero, the delivery tag - refers to a single message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding messages. - </doc> - - <rule name="validation"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered message, - and raise an exception if this is not the case. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="reject" code="0xd" label="reject an incoming message"> - <doc> - This command allows a client to reject a message. It can be used to return untreatable - messages to their original queue. Note that file content is staged before delivery, so the - client will not use this command to interrupt delivery of a large message. - </doc> - - <rule name="server-interpretation"> - <doc> - The server SHOULD interpret this command as meaning that the client is unable to process - the message at this time. - </doc> - </rule> - - <rule name="not-selection"> - <doc> - A client MUST NOT use this command as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="delivery-tag" type="uint64"> - <doc> - the identifier of the message to be rejected - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then reject it on another. - </doc> - </rule> - </field> - - <field name="requeue" type="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - </doc> - - <rule name="requeue-strategy"> - <doc> - The server MUST NOT deliver the message to the same client within the context of the - current session. The recommended strategy is to attempt to deliver the message to an - alternative consumer, and if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold the message on the queue - and redeliver it to the same client at a later stage. - </doc> - </rule> - </field> - </command> - - </class> - - <!-- == Class: stream ======================================================================== --> - - <class name="stream" code="0xa" label="work with streaming content"> - <doc> - The stream class provides commands that support multimedia streaming. The stream class uses - the following semantics: one message is one packet of data; delivery is unacknowledged and - unreliable; the consumer can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favor of high priority messages. - </doc> - - <doc type="grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - </doc> - - <rule name="overflow-discard"> - <doc> - The server SHOULD discard stream messages on a priority basis if the queue size exceeds some - configured limit. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for stream messages, where priorities - 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST implement automatic acknowledgements on stream content. That is, as soon as - a message is delivered to a client via a Deliver command, the server must remove it from the - queue. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- These are the properties for a Stream content --> - <struct name="stream-properties" size="4" code="0x1" pack="2"> - <field name="content-type" type="str8" label="MIME content type" /> - <field name="content-encoding" type="str8" label="MIME content encoding" /> - <field name="headers" type="map" label="message header field table" /> - <field name="priority" type="uint8" label="message priority, 0 to 9" /> - <field name="timestamp" type="datetime" label="message timestamp" /> - </struct> - - <domain name="return-code" type="uint16" label="return code from server"> - <doc> - The return code. The AMQP return codes are defined by this enum. - </doc> - <enum> - <choice name="content-too-large" value="311"> - <doc> - The client attempted to transfer content larger than the server could accept. - </doc> - </choice> - - <choice name="no-route" value="312"> - <doc> - The exchange cannot route a message, most likely due to an invalid routing key. Only - when the mandatory flag is set. - </doc> - </choice> - - <choice name="no-consumers" value="313"> - <doc> - The exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: stream.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos" code="0x1" label="specify quality of service"> - <doc> - This command requests a specific quality of service. The QoS can be specified for the - current session or for all sessions on the connection. The particular properties and - semantics of a qos command always depend on the content class semantics. Though the qos - command could in principle apply to both peers, it is currently meaningful only for the - server. - </doc> - - <implement role="server" handle="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" type="uint32" label="pre-fetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Pre-fetching gives a performance improvement. This field - specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other pre-fetch limits may still apply. - </doc> - </field> - - <field name="prefetch-count" type="uint16" label="pre-fetch window in messages"> - <doc> - Specifies a pre-fetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - pre-fetch windows (and those at the session and connection level) allow it. - </doc> - </field> - - <field name="consume-rate" type="uint32" label="transfer rate in octets/second"> - <doc> - Specifies a desired transfer rate in octets per second. This is usually determined by the - application that uses the streaming data. A value of zero means "no limit", i.e. as - rapidly as possible. - </doc> - - <rule name="ignore-prefetch"> - <doc> - The server MAY ignore the pre-fetch values and consume rates, depending on the type of - stream and the ability of the server to queue and/or reply it. - </doc> - </rule> - - <rule name="drop-by-priority"> - <doc> - The server MAY drop low-priority messages in favor of high-priority messages. - </doc> - </rule> - </field> - - <field name="global" type="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </command> - - <!-- - Command: stream.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos-ok" code="0x2" label="confirm the requested qos"> - <doc> - This command tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <implement role="client" handle="MUST" /> - </command> - - <!-- - Command: stream.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume" code="0x3" label="start a queue consumer"> - <doc> - This command asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the session they were created on, - or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <rule name="priority-based-delivery"> - <doc> - Streaming applications SHOULD use different sessions to select different streaming - resolutions. AMQP makes no provision for filtering and/or transforming streams except on - the basis of priority-based selective delivery of individual messages. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <response name="consume-ok" /> - - <field name="queue" type="queue.name"> - <doc> - Specifies the name of the queue to consume from. - </doc> - - <exception name="queue-exists-if-empty" error-code="not-allowed"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="consumer-tag" type="str8"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. - </doc> - - <exception name="not-existing-consumer" error-code="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-empty-consumer-tag" error-code="not-allowed"> - <doc> - The client MUST NOT specify a tag that is empty or blank. - </doc> - <doc type="scenario"> - Attempt to create a consumers with an empty tag. - </doc> - </exception> - </field> - - <field name="no-local" type="bit"> - <doc>If the no-local field is set the server will not send messages to the connection that - published them.</doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise an exception with return code 405 - (resource locked). - </doc> - </exception> - </field> - - <field name="nowait" type="bit" label="do not send a reply command"> - <doc> - If set, the server will not respond to the command. The client should not wait for a reply - command. If the server could not complete the command it will raise an exception. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </command> - - <!-- - Command: stream.consume-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume-ok" code="0x4" label="confirm a new consumer"> - <doc> - This command provides the client with a consumer tag which it may use in commands that work - with the consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </command> - - <!-- - Command: stream.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x5" label="end a queue consumer"> - <doc> - This command cancels a consumer. Since message delivery is asynchronous the client may - continue to receive messages for a short while after cancelling a consumer. It may process - or discard these as appropriate. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - </command> - - <!-- - Command: stream.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="publish" code="0x6" label="publish a message"> - <doc> - This command publishes a message to a specific exchange. The message will be routed to - queues as defined by the exchange configuration and distributed to any active consumers as - appropriate. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise an exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <exception name="refusal" error-code="not-implemented"> - <doc> - The exchange MAY refuse stream content in which case it MUST respond with an exception. - </doc> - </exception> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" type="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return command. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" type="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return command. If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: stream.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="return" code="0x7" label="return a failed message"> - <doc> - This command returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="reply-code" type="return-code" /> - - <field name="reply-text" type="str8" label="The localized reply text."> - <doc> - The localized reply text. This text can be logged as an aid to resolving issues. - </doc> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: stream.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="deliver" code="0x8" label="notify the client of a consumer message"> - <doc> - This command delivers a message to the client, via a consumer. In the asynchronous message - delivery model, the client starts a consumer using the Consume command, then the server - responds with Deliver commands as and when messages arrive for that consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - - <field name="delivery-tag" type="uint64"> - <doc> - The server-assigned and session-specific delivery tag - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then acknowledge it on - another. - </doc> - </rule> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="queue" type="queue.name" required="true"> - <doc> - Specifies the name of the queue that the message came from. Note that a single session can - start many consumers on different queues. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - </class> - -</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-10-stripped.xml b/qpid/python/qpid/specs/amqp-0-10-stripped.xml new file mode 100644 index 0000000000..1c53608138 --- /dev/null +++ b/qpid/python/qpid/specs/amqp-0-10-stripped.xml @@ -0,0 +1,1200 @@ +<?xml version="1.0"?> + +<!-- +(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. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="0" xmlns="http://www.amqp.org/schema/amqp.xsd" port="5672" minor="10"> + <type name="bin8" code="0x00" fixed-width="1"/> + <type name="int8" code="0x01" fixed-width="1"/> + <type name="uint8" code="0x02" fixed-width="1"/> + <type name="char" code="0x04" fixed-width="1"/> + <type name="boolean" code="0x08" fixed-width="1"/> + <type name="bin16" code="0x10" fixed-width="2"/> + <type name="int16" code="0x11" fixed-width="2"/> + <type name="uint16" code="0x12" fixed-width="2"/> + <type name="bin32" code="0x20" fixed-width="4"/> + <type name="int32" code="0x21" fixed-width="4"/> + <type name="uint32" code="0x22" fixed-width="4"/> + <type name="float" code="0x23" fixed-width="4"/> + <type name="char-utf32" code="0x27" fixed-width="4"/> + <type name="sequence-no" fixed-width="4"/> + <type name="bin64" code="0x30" fixed-width="8"/> + <type name="int64" code="0x31" fixed-width="8"/> + <type name="uint64" code="0x32" fixed-width="8"/> + <type name="double" code="0x33" fixed-width="8"/> + <type name="datetime" code="0x38" fixed-width="8"/> + <type name="bin128" code="0x40" fixed-width="16"/> + <type name="uuid" code="0x48" fixed-width="16"/> + <type name="bin256" code="0x50" fixed-width="32"/> + <type name="bin512" code="0x60" fixed-width="64"/> + <type name="bin1024" code="0x70" fixed-width="128"/> + <type name="vbin8" code="0x80" variable-width="1"/> + <type name="str8-latin" code="0x84" variable-width="1"/> + <type name="str8" code="0x85" variable-width="1"/> + <type name="str8-utf16" code="0x86" variable-width="1"/> + <type name="vbin16" code="0x90" variable-width="2"/> + <type name="str16-latin" code="0x94" variable-width="2"/> + <type name="str16" code="0x95" variable-width="2"/> + <type name="str16-utf16" code="0x96" variable-width="2"/> + <type name="byte-ranges" variable-width="2"/> + <type name="sequence-set" variable-width="2"/> + <type name="vbin32" code="0xa0" variable-width="4"/> + <type name="map" code="0xa8" variable-width="4"/> + <type name="list" code="0xa9" variable-width="4"/> + <type name="array" code="0xaa" variable-width="4"/> + <type name="struct32" code="0xab" variable-width="4"/> + <type name="bin40" code="0xc0" fixed-width="5"/> + <type name="dec32" code="0xc8" fixed-width="5"/> + <type name="bin72" code="0xd0" fixed-width="9"/> + <type name="dec64" code="0xd8" fixed-width="9"/> + <type name="void" code="0xf0" fixed-width="0"/> + <type name="bit" code="0xf1" fixed-width="0"/> + <constant name="MIN-MAX-FRAME-SIZE" value="4096"/> + <domain name="segment-type" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + <choice name="header" value="2"/> + <choice name="body" value="3"/> + </enum> + </domain> + <domain name="track" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + </enum> + </domain> + <domain name="str16-array" type="array"/> + <class name="connection" code="0x1"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="close-code" type="uint16"> + <enum> + <choice name="normal" value="200"/> + <choice name="connection-forced" value="320"/> + <choice name="invalid-path" value="402"/> + <choice name="framing-error" value="501"/> + </enum> + </domain> + <domain name="amqp-host-url" type="str16"/> + <domain name="amqp-host-array" type="array"/> + <control name="start" code="0x1"> + <rule name="protocol-name"/> + <rule name="client-support"/> + <implement role="client" handle="MUST"/> + <response name="start-ok"/> + <field name="server-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanisms" type="str16-array" required="true"/> + <field name="locales" type="str16-array" required="true"> + <rule name="required-support"/> + </field> + </control> + <control name="start-ok" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="client-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanism" type="str8" required="true"> + <rule name="security"/> + <rule name="validity"/> + </field> + <field name="response" type="vbin32" required="true"/> + <field name="locale" type="str8" required="true"/> + </control> + <control name="secure" code="0x3"> + <implement role="client" handle="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="vbin32" required="true"/> + </control> + <control name="secure-ok" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="response" type="vbin32" required="true"/> + </control> + <control name="tune" code="0x5"> + <implement role="client" handle="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" type="uint16"/> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + </field> + <field name="heartbeat-min" type="uint16"/> + <field name="heartbeat-max" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="tune-ok" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="channel-max" type="uint16" required="true"> + <rule name="upper-limit"/> + <rule name="available-channels"/> + </field> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + <rule name="upper-limit"/> + <rule name="max-frame-size"/> + </field> + <field name="heartbeat" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="open" code="0x7"> + <implement role="server" handle="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" type="str8" required="true"> + <rule name="separation"/> + <rule name="security"/> + </field> + <field name="capabilities" type="str16-array"/> + <field name="insist" type="bit"> + <rule name="behavior"/> + </field> + </control> + <control name="open-ok" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="redirect" code="0x9"> + <rule name="usage"/> + <implement role="client" handle="MUST"/> + <field name="host" type="amqp-host-url" required="true"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="heartbeat" code="0xa"/> + <control name="close" code="0xb"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <response name="close-ok"/> + <field name="reply-code" type="close-code" required="true"/> + <field name="reply-text" type="str8"/> + </control> + <control name="close-ok" code="0xc"> + <rule name="reporting"/> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + </control> + </class> + <class name="session" code="0x2"> + <rule name="attachment"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <role name="sender" implement="MUST"/> + <role name="receiver" implement="MUST"/> + <domain name="name" type="vbin16"/> + <domain name="detach-code" type="uint8"> + <enum> + <choice name="normal" value="0"/> + <choice name="session-busy" value="1"/> + <choice name="transport-busy" value="2"/> + <choice name="not-attached" value="3"/> + <choice name="unknown-ids" value="4"/> + </enum> + </domain> + <domain name="commands" type="sequence-set"/> + <struct name="header" size="1" pack="1"> + <field name="sync" type="bit"/> + </struct> + <struct name="command-fragment" size="0" pack="0"> + <field name="command-id" type="sequence-no" required="true"/> + <field name="byte-ranges" type="byte-ranges" required="true"/> + </struct> + <domain name="command-fragments" type="array"/> + <control name="attach" code="0x1"> + <rule name="one-transport-per-session"/> + <rule name="one-session-per-transport"/> + <rule name="idempotence"/> + <rule name="scoping"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <response name="attached"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + <field name="force" type="bit"/> + </control> + <control name="attached" code="0x2"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detach" code="0x3"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detached" code="0x4"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + <field name="code" type="detach-code" required="true"/> + </control> + <control name="request-timeout" code="0x5"> + <rule name="maximum-granted-timeout"/> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <response name="timeout"/> + <field name="timeout" type="uint32"/> + </control> + <control name="timeout" code="0x6"> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <field name="timeout" type="uint32"/> + </control> + <control name="command-point" code="0x7"> + <rule name="newly-attached-transports"/> + <rule name="zero-offset"/> + <rule name="nonzero-offset"/> + <implement role="receiver" handle="MUST"/> + <field name="command-id" type="sequence-no" required="true"/> + <field name="command-offset" type="uint64" required="true"/> + </control> + <control name="expected" code="0x8"> + <rule name="include-next-command"/> + <rule name="commands-empty-means-new-session"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands" required="true"/> + <field name="fragments" type="command-fragments"/> + </control> + <control name="confirmed" code="0x9"> + <rule name="durability"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="exclude-known-complete"/> + </field> + <field name="fragments" type="command-fragments"/> + </control> + <control name="completed" code="0xa"> + <rule name="known-completed-reply"/> + <rule name="delayed-reply"/> + <rule name="merged-reply"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="completed-implies-confirmed"/> + <rule name="exclude-known-complete"/> + </field> + <field name="timely-reply" type="bit"/> + </control> + <control name="known-completed" code="0xb"> + <rule name="stateless"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="known-completed-implies-known-confirmed"/> + </field> + </control> + <control name="flush" code="0xc"> + <implement role="receiver" handle="MUST"/> + <field name="expected" type="bit"/> + <field name="confirmed" type="bit"/> + <field name="completed" type="bit"/> + </control> + <control name="gap" code="0xd"> + <rule name="gap-confirmation-and-completion"/> + <rule name="aborted-commands"/> + <rule name="completed-or-confirmed-commands"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"/> + </control> + </class> + <class name="execution" code="0x3"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="error-code" type="uint16"> + <enum> + <choice name="unauthorized-access" value="403"/> + <choice name="not-found" value="404"/> + <choice name="resource-locked" value="405"/> + <choice name="precondition-failed" value="406"/> + <choice name="resource-deleted" value="408"/> + <choice name="illegal-state" value="409"/> + <choice name="command-invalid" value="503"/> + <choice name="resource-limit-exceeded" value="506"/> + <choice name="not-allowed" value="530"/> + <choice name="illegal-argument" value="531"/> + <choice name="not-implemented" value="540"/> + <choice name="internal-error" value="541"/> + <choice name="invalid-argument" value="542"/> + </enum> + </domain> + <command name="sync" code="0x1"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + </command> + <command name="result" code="0x2"> + <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> + <command name="exception" code="0x3"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <field name="error-code" type="error-code" required="true"/> + <field name="command-id" type="sequence-no"/> + <field name="class-code" type="uint8"/> + <field name="command-code" type="uint8"/> + <field name="field-index" type="uint8"/> + <field name="description" type="str16"/> + <field name="error-info" type="map"/> + </command> + </class> + <class name="message" code="0x4"> + <rule name="persistent-message"/> + <rule name="no-persistent-message-discard"/> + <rule name="throttling"/> + <rule name="non-persistent-message-overflow"/> + <rule name="non-persistent-message-discard"/> + <rule name="min-priority-levels"/> + <rule name="priority-level-implementation"/> + <rule name="priority-delivery"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="destination" type="str8"/> + <domain name="accept-mode" type="uint8"> + <enum> + <choice name="explicit" value="0"/> + <choice name="none" value="1"/> + </enum> + </domain> + <domain name="acquire-mode" type="uint8"> + <enum> + <choice name="pre-acquired" value="0"/> + <choice name="not-acquired" value="1"/> + </enum> + </domain> + <domain name="reject-code" type="uint16"> + <enum> + <choice name="unspecified" value="0"/> + <choice name="unroutable" value="1"/> + <choice name="immediate" value="2"/> + </enum> + </domain> + <domain name="resume-id" type="str16"/> + <domain name="delivery-mode" type="uint8"> + <enum> + <choice name="non-persistent" value="1"/> + <choice name="persistent" value="2"/> + </enum> + </domain> + <domain name="delivery-priority" type="uint8"> + <enum> + <choice name="lowest" value="0"/> + <choice name="lower" value="1"/> + <choice name="low" value="2"/> + <choice name="below-average" value="3"/> + <choice name="medium" value="4"/> + <choice name="above-average" value="5"/> + <choice name="high" value="6"/> + <choice name="higher" value="7"/> + <choice name="very-high" value="8"/> + <choice name="highest" value="9"/> + </enum> + </domain> + <struct name="delivery-properties" code="0x1" size="4" pack="2"> + <field name="discard-unroutable" type="bit"/> + <field name="immediate" type="bit"/> + <field name="redelivered" type="bit"> + <rule name="implementation"/> + <rule name="hinting"/> + </field> + <field name="priority" type="delivery-priority" required="true"/> + <field name="delivery-mode" type="delivery-mode" required="true"/> + <field name="ttl" type="uint64"> + <rule name="ttl-decrement"/> + </field> + <field name="timestamp" type="datetime"/> + <field name="expiration" type="datetime"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + </struct> + <struct name="fragment-properties" code="0x2" size="4" pack="2"> + <field name="first" type="bit" default="1"/> + <field name="last" type="bit" default="1"/> + <field name="fragment-size" type="uint64"/> + </struct> + <struct name="reply-to" size="2" pack="2"> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + </struct> + <struct name="message-properties" code="0x3" size="4" pack="2"> + <field name="content-length" type="uint64"/> + <field name="message-id" type="uuid"> + <rule name="unique"/> + <rule name="immutable"/> + </field> + <field name="correlation-id" type="vbin16"/> + <field name="reply-to" type="reply-to"/> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="user-id" type="vbin16"> + <rule name="authentication"/> + </field> + <field name="app-id" type="vbin16"/> + <field name="application-headers" type="map"/> + </struct> + <domain name="flow-mode" type="uint8"> + <enum> + <choice name="credit" value="0"/> + <choice name="window" value="1"/> + </enum> + </domain> + <domain name="credit-unit" type="uint8"> + <enum> + <choice name="message" value="0"/> + <choice name="byte" value="1"/> + </enum> + </domain> + <command name="transfer" code="0x1"> + <rule name="transactional-publish"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <rule name="blank-destination"/> + <exception name="nonexistent-exchange" error-code="not-found"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <segments> + <header> + <entry type="delivery-properties"/> + <entry type="fragment-properties"/> + <entry type="message-properties"/> + </header> + <body/> + </segments> + </command> + <command name="accept" code="0x2"> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + </command> + <command name="reject" code="0x3"> + <rule name="alternate-exchange"/> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="code" type="reject-code" required="true"/> + <field name="text" type="str8"/> + </command> + <command name="release" code="0x4"> + <rule name="ordering"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="set-redelivered" type="bit"/> + </command> + <command name="acquire" code="0x5"> + <rule name="one-to-one"/> + <implement role="server" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <result> + <struct name="acquired" code="0x4" size="4" pack="2"> + <field name="transfers" type="session.commands" required="true"/> + </struct> + </result> + </command> + <command name="resume" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <exception name="destination-not-found" error-code="not-found"/> + </field> + <field name="resume-id" type="resume-id" required="true"> + <rule name="unknown-resume-id"/> + </field> + <result> + <struct name="message-resume-result" code="0x5" size="4" pack="2"> + <field name="offset" type="uint64"/> + </struct> + </result> + </command> + <command name="subscribe" code="0x7"> + <rule name="simultaneous-subscriptions"/> + <rule name="default-flow-mode"/> + <exception name="queue-deletion" error-code="resource-deleted"/> + <exception name="queue-not-found" error-code="not-found"/> + <rule name="initial-credit"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"/> + <field name="destination" type="destination"> + <exception name="unique-subscriber-destination" error-code="not-allowed"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + <field name="arguments" type="map"/> + </command> + <command name="cancel" code="0x8"> + <rule name="post-cancel-transfer-resolution"/> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination" required="true"> + <exception name="subscription-not-found" error-code="not-found"/> + </field> + </command> + <command name="set-flow-mode" code="0x9"> + <rule name="byte-accounting"/> + <rule name="mode-switching"/> + <rule name="default-flow-mode"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="flow-mode" type="flow-mode" required="true"/> + </command> + <command name="flow" code="0xa"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="unit" type="credit-unit" required="true"/> + <field name="value" type="uint32"/> + </command> + <command name="flush" code="0xb"> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + <command name="stop" code="0xc"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + </class> + <class name="tx" code="0x5"> + <rule name="duplicate-tracking"/> + <role name="server" implement="SHOULD"/> + <command name="select" code="0x1"> + <exception name="exactly-once" error-code="illegal-state"/> + <exception name="no-dtx" error-code="illegal-state"/> + <exception name="explicit-accepts" error-code="not-allowed"/> + <implement role="server" handle="MUST"/> + </command> + <command name="commit" code="0x2"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + <command name="rollback" code="0x3"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + </class> + <class name="dtx" code="0x6"> + <rule name="transactionality"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <domain name="xa-status" type="uint16"> + <enum> + <choice name="xa-ok" value="0"/> + <choice name="xa-rbrollback" value="1"/> + <choice name="xa-rbtimeout" value="2"/> + <choice name="xa-heurhaz" value="3"/> + <choice name="xa-heurcom" value="4"/> + <choice name="xa-heurrb" value="5"/> + <choice name="xa-heurmix" value="6"/> + <choice name="xa-rdonly" value="7"/> + </enum> + </domain> + <struct name="xa-result" code="0x1" size="4" pack="2"> + <field name="status" type="xa-status" required="true"/> + </struct> + <struct name="xid" size="2" pack="2"> + <field name="format" type="uint32" required="true"/> + <field name="global-id" type="vbin8" required="true"/> + <field name="branch-id" type="vbin8" required="true"/> + </struct> + <command name="select" code="0x1"> + <implement role="server" handle="MAY"/> + </command> + <command name="start" code="0x2"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="already-known" error-code="not-allowed"/> + <exception name="join-and-resume" error-code="not-allowed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-allowed"/> + </field> + <field name="join" type="bit"> + <exception name="unsupported" error-code="not-implemented"/> + </field> + <field name="resume" type="bit"/> + <result type="xa-result"/> + </command> + <command name="end" code="0x3"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="suspend-and-fail" error-code="not-allowed"/> + <rule name="success"/> + <rule name="session-closed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="not-associated" error-code="illegal-state"/> + </field> + <field name="fail" type="bit"> + <rule name="failure"/> + </field> + <field name="suspend" type="bit"> + <rule name="resume"/> + </field> + <result type="xa-result"/> + </command> + <command name="commit" code="0x4"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <field name="one-phase" type="bit"> + <exception name="one-phase" error-code="illegal-state"/> + <exception name="two-phase" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="forget" code="0x5"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + </command> + <command name="get-timeout" code="0x6"> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <result> + <struct name="get-timeout-result" code="0x2" size="4" pack="2"> + <field name="timeout" type="uint32" required="true"/> + </struct> + </result> + </command> + <command name="prepare" code="0x7"> + <exception name="illegal-state" error-code="illegal-state"/> + <rule name="obligation-1"/> + <rule name="obligation-2"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="recover" code="0x8"> + <implement role="server" handle="MAY"/> + <result> + <struct name="recover-result" code="0x3" size="4" pack="2"> + <field name="in-doubt" type="array" required="true"/> + </struct> + </result> + </command> + <command name="rollback" code="0x9"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="set-timeout" code="0xa"> + <rule name="effective"/> + <rule name="reset"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <field name="timeout" type="uint32" required="true"/> + </command> + </class> + <class name="exchange" code="0x7"> + <rule name="required-types"/> + <rule name="recommended-types"/> + <rule name="required-instances"/> + <rule name="default-exchange"/> + <rule name="default-access"/> + <rule name="extensions"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="minimum"/> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="reserved-names" error-code="not-allowed"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="type" type="str8" required="true"> + <exception name="typed" error-code="not-allowed"/> + <exception name="exchange-type-not-found" error-code="not-found"/> + </field> + <field name="alternate-exchange" type="name"> + <rule name="empty-name"/> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <rule name="double-failure"/> + </field> + <field name="passive" type="bit"> + <exception name="not-found" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="support"/> + <rule name="sticky"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="sticky"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="exists" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + <exception name="used-as-alternate" error-code="not-allowed"/> + </field> + <field name="if-unused" type="bit"> + <exception name="exchange-in-use" error-code="precondition-failed"/> + </field> + </command> + <command name="query" code="0x3"> + <implement role="server" handle="MUST"/> + <field name="name" type="str8"/> + <result> + <struct name="exchange-query-result" code="0x1" size="4" pack="2"> + <field name="type" type="str8"/> + <field name="durable" type="bit"/> + <field name="not-found" type="bit"/> + <field name="arguments" type="map"/> + </struct> + </result> + </command> + <command name="bind" code="0x4"> + <rule name="duplicates"/> + <rule name="durable-exchange"/> + <rule name="binding-count"/> + <rule name="multiple-bindings"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="empty-queue" error-code="invalid-argument"/> + <exception name="queue-existence" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="exchange-existence" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"/> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="unbind" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="non-existent-queue" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="non-existent-exchange" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"> + <exception name="non-existent-binding-key" error-code="not-found"/> + </field> + </command> + <command name="bound" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="str8"/> + <field name="queue" type="str8" required="true"/> + <field name="binding-key" type="str8"/> + <field name="arguments" type="map"/> + <result> + <struct name="exchange-bound-result" code="0x2" size="4" pack="2"> + <field name="exchange-not-found" type="bit"/> + <field name="queue-not-found" type="bit"/> + <field name="queue-not-matched" type="bit"/> + <field name="key-not-matched" type="bit"/> + <field name="args-not-matched" type="bit"/> + </struct> + </result> + </command> + </class> + <class name="queue" code="0x8"> + <rule name="any-content"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="default-binding"/> + <rule name="minimum-queues"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="reserved-prefix" error-code="not-allowed"/> + </field> + <field name="alternate-exchange" type="exchange.name"> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <exception name="unknown-exchange" error-code="not-found"/> + </field> + <field name="passive" type="bit"> + <exception name="passive" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="persistence"/> + <rule name="types"/> + <rule name="pre-existence"/> + </field> + <field name="exclusive" type="bit"> + <rule name="types"/> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="pre-existence"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + <field name="if-unused" type="bit"> + <exception name="if-unused-flag" error-code="precondition-failed"/> + </field> + <field name="if-empty" type="bit"> + <exception name="not-empty" error-code="precondition-failed"/> + </field> + </command> + <command name="purge" code="0x3"> + <rule name="empty"/> + <rule name="pending-messages"/> + <rule name="purge-recovery"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + </command> + <command name="query" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"/> + <result> + <struct name="queue-query-result" code="0x1" size="4" pack="2"> + <field name="queue" type="name" required="true"/> + <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" required="true"/> + <field name="subscriber-count" type="uint32" required="true"/> + </struct> + </result> + </command> + </class> + <class name="file" code="0x9"> + <rule name="reliable-storage"/> + <rule name="no-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="file-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="reply-to" type="str8"/> + <field name="message-id" type="str8"/> + <field name="filename" type="str8"/> + <field name="timestamp" type="datetime"/> + <field name="cluster-id" type="str8"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"> + <rule name="prefetch-discretion"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="no-ack" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="open" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="open-ok"/> + <field name="identifier" type="str8"/> + <field name="content-size" type="uint64"> + <rule name="content-size"/> + </field> + </command> + <command name="open-ok" code="0x7"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="stage"/> + <field name="staged-size" type="uint64"> + <rule name="behavior"/> + <rule name="staging"/> + </field> + </command> + <command name="stage" code="0x8"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="publish" code="0x9"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <field name="identifier" type="str8"/> + </command> + <command name="return" code="0xa"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0xb"> + <rule name="redelivery-tracking"/> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="non-zero"/> + </field> + <field name="redelivered" type="bit"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="identifier" type="str8"/> + </command> + <command name="ack" code="0xc"> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="multiple" type="bit"> + <rule name="validation"/> + </field> + </command> + <command name="reject" code="0xd"> + <rule name="server-interpretation"/> + <rule name="not-selection"/> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="requeue" type="bit"> + <rule name="requeue-strategy"/> + </field> + </command> + </class> + <class name="stream" code="0xa"> + <rule name="overflow-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="stream-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="timestamp" type="datetime"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"/> + <field name="consume-rate" type="uint32"> + <rule name="ignore-prefetch"/> + <rule name="drop-by-priority"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <rule name="priority-based-delivery"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="publish" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="return" code="0x7"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="exchange" type="exchange.name"/> + <field name="queue" type="queue.name" required="true"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + </class> +</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-8-qpid-stripped.xml b/qpid/python/qpid/specs/amqp-0-8-qpid-stripped.xml new file mode 100644 index 0000000000..6975e17aa6 --- /dev/null +++ b/qpid/python/qpid/specs/amqp-0-8-qpid-stripped.xml @@ -0,0 +1,784 @@ +<?xml version="1.0"?> + +<!-- +(c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy +Technologies Inc., iMatix Corporation, IONA\ufffd Technologies, Red +Hat, Inc., TWIST Process Innovations, and 29West Inc. 2006. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="8" minor="0" port="5672"> + <constant name="frame method" value="1"/> + <constant name="frame header" value="2"/> + <constant name="frame body" value="3"/> + <constant name="frame oob method" value="4"/> + <constant name="frame oob header" value="5"/> + <constant name="frame oob body" value="6"/> + <constant name="frame trace" value="7"/> + <constant name="frame heartbeat" value="8"/> + <constant name="frame min size" value="4096"/> + <constant name="frame end" value="206"/> + <constant name="reply success" value="200"/> + <constant name="not delivered" value="310" class="soft error"/> + <constant name="content too large" value="311" class="soft error"/> + <constant name="connection forced" value="320" class="hard error"/> + <constant name="invalid path" value="402" class="hard error"/> + <constant name="access refused" value="403" class="soft error"/> + <constant name="not found" value="404" class="soft error"/> + <constant name="resource locked" value="405" class="soft error"/> + <constant name="frame error" value="501" class="hard error"/> + <constant name="syntax error" value="502" class="hard error"/> + <constant name="command invalid" value="503" class="hard error"/> + <constant name="channel error" value="504" class="hard error"/> + <constant name="resource error" value="506" class="hard error"/> + <constant name="not allowed" value="530" class="hard error"/> + <constant name="not implemented" value="540" class="hard error"/> + <constant name="internal error" value="541" class="hard error"/> + <domain name="access ticket" type="short"> + <assert check="ne" value="0"/> + </domain> + <domain name="class id" type="short"/> + <domain name="consumer tag" type="shortstr"/> + <domain name="delivery tag" type="longlong"/> + <domain name="exchange name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="known hosts" type="shortstr"/> + <domain name="method id" type="short"/> + <domain name="no ack" type="bit"/> + <domain name="no local" type="bit"/> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="syntax" rule="path"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer properties" type="table"/> + <domain name="queue name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="reply code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply text" type="shortstr"> + <assert check="notnull"/> + </domain> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version major" type="octet"/> + <field name="version minor" type="octet"/> + <field name="server properties" domain="peer properties"/> + <field name="mechanisms" type="longstr"> + <see name="security mechanisms"/> + <assert check="notnull"/> + </field> + <field name="locales" type="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client properties" domain="peer properties"/> + <field name="mechanism" type="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" type="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" type="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="longstr"> + <see name="security mechanisms"/> + </field> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" type="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel max" type="short"/> + <field name="frame max" type="long"/> + <field name="heartbeat" type="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel max" type="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel max"/> + </field> + <field name="frame max" type="long"/> + <field name="heartbeat" type="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual host" domain="path"> + <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> + </field> + <field name="capabilities" type="shortstr"/> + <field name="insist" type="bit"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known hosts" domain="known hosts"/> + </method> + <method name="redirect" synchronous="1" index="50"> + <chassis name="client" implement="MAY"/> + <field name="host" type="shortstr"> + <assert check="notnull"/> + </field> + <field name="known hosts" domain="known hosts"/> + </method> + <method name="close" synchronous="1" index="60"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="class id" domain="class id"/> + <!-- Qpid difference : correct the domain --> + <field name="method id" domain="method id"/> + </method> + <method name="close-ok" synchronous="1" index="61"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out of band" type="shortstr"> + <assert check="null"/> + </field> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" type="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" type="bit"/> + </method> + <method name="alert" index="30"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="details" type="table"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="class id" domain="class id"/> + <field name="method id" domain="method id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="access" handler="connection" index="30"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="request" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="request-ok"/> + <field name="realm" domain="path"/> + <field name="exclusive" type="bit"/> + <field name="passive" type="bit"/> + <field name="active" type="bit"/> + <field name="write" type="bit"/> + <field name="read" type="bit"/> + </method> + <method name="request-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="type" type="shortstr"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="passive" type="bit"/> + <field name="durable" type="bit"/> + <field name="auto delete" type="bit"/> + <field name="internal" type="bit"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"> + <assert check="notnull"/> + </field> + <field name="if unused" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <!-- Qpid specific addition --> + <method name="bound" synchronous="1" index="22"> + <chassis name="server" implement="SHOULD"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="queue" domain="queue name"/> + </method> + <method name="bound-ok" synchronous="1" index="23"> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <chassis name="client" implement="SHOULD"/> + </method> + <!-- End Qpid specific addition --> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </field> + <field name="passive" type="bit"/> + <field name="durable" type="bit"/> + <field name="exclusive" type="bit"/> + <field name="auto delete" type="bit"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue name"> + <assert check="notnull"/> + </field> + <field name="message count" type="long"/> + <field name="consumer count" type="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="nowait" type="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message count" type="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="if unused" type="bit"/> + <field name="if empty" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message count" type="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="delivery mode" type="octet"/> + <field name="priority" type="octet"/> + <field name="correlation id" type="shortstr"/> + <field name="reply to" type="shortstr"/> + <field name="expiration" type="shortstr"/> + <field name="message id" type="shortstr"/> + <field name="timestamp" type="timestamp"/> + <field name="type" type="shortstr"/> + <field name="user id" type="shortstr"/> + <field name="app id" type="shortstr"/> + <field name="cluster id" type="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="no ack" domain="no ack"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + <!-- Qpid specific addition : interop issue extra field --> + <field name="arguments" type="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="no ack" domain="no ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="message count" type="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster id" type="shortstr"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="multiple" type="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="requeue" type="bit"/> + </method> + <!-- Qpid specific modification : interop issue, added synchronous reply --> + <method name="recover" index="100"> + <chassis name="server" implement="MUST"/> + <field name="requeue" type="bit"/> + <response name="recover-ok"/> + </method> + <method name="recover-ok" synchronous="1" index="101"> + <chassis name="client" implement="MUST"/> + </method> + <!-- End Qpid specific modification --> + </class> + <class name="file" handler="channel" index="70"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="priority" type="octet"/> + <field name="reply to" type="shortstr"/> + <field name="message id" type="shortstr"/> + <field name="filename" type="shortstr"/> + <field name="timestamp" type="timestamp"/> + <field name="cluster id" type="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="no ack" domain="no ack"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="open" synchronous="1" index="40"> + <response name="open-ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="identifier" type="shortstr"/> + <field name="content size" type="longlong"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <response name="stage"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="staged size" type="longlong"/> + </method> + <method name="stage" content="1" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="publish" index="60"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + <field name="identifier" type="shortstr"/> + </method> + <method name="return" content="1" index="70"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" index="80"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="identifier" type="shortstr"/> + </method> + <method name="ack" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="multiple" type="bit"/> + </method> + <method name="reject" index="100"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="requeue" type="bit"/> + </method> + </class> + <class name="stream" handler="channel" index="80"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="priority" type="octet"/> + <field name="timestamp" type="timestamp"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="consume rate" type="long"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="exchange" domain="exchange name"/> + <field name="queue" domain="queue name"> + <assert check="notnull"/> + </field> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="dtx" handler="channel" index="100"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="start" synchronous="1" index="20"> + <chassis name="server" implement="MAY"/> + <response name="start-ok"/> + <field name="dtx identifier" type="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tunnel" handler="tunnel" index="110"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="headers" type="table"/> + <field name="proxy name" type="shortstr"/> + <field name="data name" type="shortstr"/> + <field name="durable" type="octet"/> + <field name="broadcast" type="octet"/> + <method name="request" content="1" index="10"> + <chassis name="server" implement="MUST"/> + <field name="meta data" type="table"/> + </method> + </class> + <class name="test" handler="channel" index="120"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="SHOULD"/> + <method name="integer" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="integer-ok"/> + <field name="integer 1" type="octet"/> + <field name="integer 2" type="short"/> + <field name="integer 3" type="long"/> + <field name="integer 4" type="longlong"/> + <field name="operation" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="integer-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="result" type="longlong"/> + </method> + <method name="string" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="string-ok"/> + <field name="string 1" type="shortstr"/> + <field name="string 2" type="longstr"/> + <field name="operation" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="string-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="result" type="longstr"/> + </method> + <method name="table" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="table-ok"/> + <field name="table" type="table"/> + <field name="integer op" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + <field name="string op" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="table-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="integer result" type="longlong"/> + <field name="string result" type="longstr"/> + </method> + <method name="content" synchronous="1" content="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="content-ok"/> + </method> + <method name="content-ok" synchronous="1" content="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="content checksum" type="long"/> + </method> + </class> +</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-8.xml b/qpid/python/qpid/specs/amqp-0-8.xml deleted file mode 100644 index 0463f45fa9..0000000000 --- a/qpid/python/qpid/specs/amqp-0-8.xml +++ /dev/null @@ -1,3998 +0,0 @@ -<?xml version="1.0"?> - -<!-- - Copyright Notice - ================ - (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., - iMatix Corporation, IONA\ufffd Technologies, Red Hat, Inc., - TWIST Process Innovations, and 29West Inc. 2006. All rights reserved. - - License - ======= - JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix - Corporation, IONA Technologies, Red Hat, Inc., TWIST Process Innovations, and - 29West Inc. (collectively, the "Authors") each hereby grants to you a worldwide, - perpetual, royalty-free, nontransferable, nonexclusive license to - (i) copy, display, distribute and implement the Advanced Messaging Queue Protocol - ("AMQP") Specification and (ii) the Licensed Claims that are held by - the Authors, all for the purpose of implementing the Advanced Messaging - Queue Protocol Specification. Your license and any rights under this - Agreement will terminate immediately without notice from - any Author if you bring any claim, suit, demand, or action related to - the Advanced Messaging Queue Protocol Specification against any Author. - Upon termination, you shall destroy all copies of the Advanced Messaging - Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or - patent application, throughout the world, excluding design patents and - design registrations, owned or controlled, or that can be sublicensed - without fee and in compliance with the requirements of this - Agreement, by an Author or its affiliates now or at any - future time and which would necessarily be infringed by implementation - of the Advanced Messaging Queue Protocol Specification. A claim is - necessarily infringed hereunder only when it is not possible to avoid - infringing it because there is no plausible non-infringing alternative - for implementing the required portions of the Advanced Messaging Queue - Protocol Specification. Notwithstanding the foregoing, Licensed Claims - shall not include any claims other than as set forth above even if - contained in the same patent as Licensed Claims; or that read solely - on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging - Queue Protocol Specification, or that, if licensed, would require a - payment of royalties by the licensor to unaffiliated third parties. - Moreover, Licensed Claims shall not include (i) any enabling technologies - that may be necessary to make or use any Licensed Product but are not - themselves expressly set forth in the Advanced Messaging Queue Protocol - Specification (e.g., semiconductor manufacturing technology, compiler - technology, object oriented technology, networking technology, operating - system technology, and the like); or (ii) the implementation of other - published standards developed elsewhere and merely referred to in the - body of the Advanced Messaging Queue Protocol Specification, or - (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced - Messaging Queue Protocol Specification. For purposes of this definition, - the Advanced Messaging Queue Protocol Specification shall be deemed to - include both architectural and interconnection requirements essential - for interoperability and may also include supporting source code artifacts - where such architectural, interconnection requirements and source code - artifacts are expressly identified as being required or documentation to - achieve compliance with the Advanced Messaging Queue Protocol Specification. - - As used hereunder, "Licensed Products" means only those specific portions - of products (hardware, software or combinations thereof) that implement - and are compliant with all relevant portions of the Advanced Messaging - Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any - use you may make of the Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," - AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE - CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE - SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY - PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, - INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY - USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED MESSAGING QUEUE - PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, - including advertising or publicity pertaining to the Advanced Messaging - Queue Protocol Specification or its contents without specific, written - prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you - shall destroy all copies of the Advanced Messaging Queue Protocol - Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the - Octagon Symbol are trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA - Technologies PLC and/or its subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered - trademarks of Red Hat, Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of - Sun Microsystems, Inc. in the United States, other countries, or both. - - Other company, product, or service names may be trademarks or service - marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp - ---> - -<!-- -======================================================== -EDITORS: (PH) Pieter Hintjens <ph@imatix.com> - (KvdR) Kim van der Riet <kim.vdriet@redhat.com> - -NOTE: These editors have been assigned by the AMQP working group. Please do not -edit/commit this file without consulting with one of the above editors. -======================================================== - -Revision history: - 2006-06-07 (PH) - version number changed to 0.8 to conform to public - release documentation. - - 2006-05-15 (PH) - fixed comments on queue name in basic.get to clarify - use of current queue in this method. - - 2006-05-15 (PH) - fixed comments on routing key in queue.bind to clarify - how routing key is filled when empty (to allow asynch queue.declare). - - 2006-05-11 (PH) - reset version to 0.70 so that putatitive standards - group can release 2-3 major new versions before hitting 1.0 (again). - - 2006-05-11 (PH) - TODO in documentation: cycle field in frame header - has been removed. - - 2006-05-11 (PH) - added nowait option to exchange.declare, delete, - queue.declare, delete, bind, purge, basic.consume, cancel, - file.consume, cancel, stream.consume and cancel methods. - - 2006-05-11 (PH) - removed notnull rule and added explanations on queue - name in queue.bind, purge, delete, basic.consume, cancel, file.consume, - cancel, stream.consume and cancel methods. - - 2006-05-11 (PH) - added basic.qos, file.qos, and stream.qos methods that - regroup all prefetch options from the consume methods. Also removed the - prefetch option from channel.open. - - 2006-05-11 (PH) - renumbered method indexes to show request-response - nature of methods; requests are 10, 20, 30 while responses are 11, 21, - etc. - - 2006-05-11 (PH) - removed OpenAMQ extension methods from this definition - since these are maintained seperately. - - 2006-05-26 (RG) - added Basic.Recover method to allow replay of - unacknowledged messages on a channel. - - 2006-07-03 (PH) - cosmetic clean-up of Basic.Recover comments. ---> - -<amqp major="8" minor="0" port="5672" comment="AMQ protocol 0.80"> - AMQ Protocol 0.80 - -<!-- -====================================================== -== CONSTANTS -====================================================== ---> - <constant name="frame method" value="1"/> - <constant name="frame header" value="2"/> - <constant name="frame body" value="3"/> - <constant name="frame oob method" value="4"/> - <constant name="frame oob header" value="5"/> - <constant name="frame oob body" value="6"/> - <constant name="frame trace" value="7"/> - <constant name="frame heartbeat" value="8"/> - <constant name="frame min size" value="4096"/> - <constant name="frame end" value="206"/> - <constant name="reply success" value="200"> - Indicates that the method completed successfully. This reply code is - reserved for future use - the current protocol design does not use - positive confirmation and reply codes are sent only in case of an - error. -</constant> - <constant name="not delivered" value="310" class="soft error"> - The client asked for a specific message that is no longer available. - The message was delivered to another client, or was purged from the - queue for some other reason. -</constant> - <constant name="content too large" value="311" class="soft error"> - The client attempted to transfer content larger than the server - could accept at the present time. The client may retry at a later - time. -</constant> - <constant name="connection forced" value="320" class="hard error"> - An operator intervened to close the connection for some reason. - The client may retry at some later date. -</constant> - <constant name="invalid path" value="402" class="hard error"> - The client tried to work with an unknown virtual host or cluster. -</constant> - <constant name="access refused" value="403" class="soft error"> - The client attempted to work with a server entity to which it has - no due to security settings. -</constant> - <constant name="not found" value="404" class="soft error"> - The client attempted to work with a server entity that does not exist. -</constant> - <constant name="resource locked" value="405" class="soft error"> - The client attempted to work with a server entity to which it has - no access because another client is working with it. -</constant> - <constant name="frame error" value="501" class="hard error"> - The client sent a malformed frame that the server could not decode. - This strongly implies a programming error in the client. -</constant> - <constant name="syntax error" value="502" class="hard error"> - The client sent a frame that contained illegal values for one or more - fields. This strongly implies a programming error in the client. -</constant> - <constant name="command invalid" value="503" class="hard error"> - The client sent an invalid sequence of frames, attempting to perform - an operation that was considered invalid by the server. This usually - implies a programming error in the client. -</constant> - <constant name="channel error" value="504" class="hard error"> - The client attempted to work with a channel that had not been - correctly opened. This most likely indicates a fault in the client - layer. -</constant> - <constant name="resource error" value="506" class="hard error"> - The server could not complete the method because it lacked sufficient - resources. This may be due to the client creating too many of some - type of entity. -</constant> - <constant name="not allowed" value="530" class="hard error"> - The client tried to work with some entity in a manner that is - prohibited by the server, due to security settings or by some other - criteria. -</constant> - <constant name="not implemented" value="540" class="hard error"> - The client tried to use functionality that is not implemented in the - server. -</constant> - <constant name="internal error" value="541" class="hard error"> - The server could not complete the method because of an internal error. - The server may require intervention by an operator in order to resume - normal operations. -</constant> - <!-- -====================================================== -== DOMAIN TYPES -====================================================== ---> - <domain name="access ticket" type="short"> - access ticket granted by server - <doc> - An access ticket granted by the server for a certain set of access - rights within a specific realm. Access tickets are valid within the - channel where they were created, and expire when the channel closes. - </doc> - <assert check="ne" value="0"/> - </domain> - <domain name="class id" type="short"/> - <domain name="consumer tag" type="shortstr"> - consumer tag - <doc> - Identifier for the consumer, valid within the current connection. - </doc> - <rule implement="MUST"> - The consumer tag is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in - one channel and then use it in another. - </rule> - </domain> - <domain name="delivery tag" type="longlong"> - server-assigned delivery tag - <doc> - The server-assigned and channel-specific delivery tag - </doc> - <rule implement="MUST"> - The delivery tag is valid only within the channel from which the - message was received. I.e. a client MUST NOT receive a message on - one channel and then acknowledge it on another. - </rule> - <rule implement="MUST"> - The server MUST NOT use a zero value for delivery tags. Zero is - reserved for client use, meaning "all messages so far received". - </rule> - </domain> - <domain name="exchange name" type="shortstr"> - exchange name - <doc> - The exchange name is a client-selected string that identifies - the exchange for publish methods. Exchange names may consist - of any mixture of digits, letters, and underscores. Exchange - names are scoped by the virtual host. - </doc> - <assert check="length" value="127"/> - </domain> - <domain name="known hosts" type="shortstr"> -list of known hosts -<doc> -Specifies the list of equivalent or alternative hosts that the server -knows about, which will normally include the current server itself. -Clients can cache this information and use it when reconnecting to a -server after a failure. -</doc> - <rule implement="MAY"> -The server MAY leave this field empty if it knows of no other -hosts than itself. -</rule> - </domain> - <domain name="method id" type="short"/> - <domain name="no ack" type="bit"> - no acknowledgement needed - <doc> - If this field is set the server does not expect acknowledgments - for messages. That is, when a message is delivered to the client - the server automatically and silently acknowledges it on behalf - of the client. This functionality increases performance but at - the cost of reliability. Messages can get lost if a client dies - before it can deliver them to the application. - </doc> - </domain> - <domain name="no local" type="bit"> - do not deliver own messages - <doc> - If the no-local field is set the server will not send messages to - the client that published them. - </doc> - </domain> - <domain name="path" type="shortstr"> - <doc> - Must start with a slash "/" and continue with path names - separated by slashes. A path name consists of any combination - of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. -</doc> - <assert check="notnull"/> - <assert check="syntax" rule="path"/> - <assert check="length" value="127"/> - </domain> - <domain name="peer properties" type="table"> - <doc> -This string provides a set of peer properties, used for -identification, debugging, and general information. -</doc> - <rule implement="SHOULD"> -The properties SHOULD contain these fields: -"product", giving the name of the peer product, "version", giving -the name of the peer version, "platform", giving the name of the -operating system, "copyright", if appropriate, and "information", -giving other general information. -</rule> - </domain> - <domain name="queue name" type="shortstr"> - queue name - <doc> - The queue name identifies the queue within the vhost. Queue - names may consist of any mixture of digits, letters, and - underscores. - </doc> - <assert check="length" value="127"/> - </domain> - <domain name="redelivered" type="bit"> - message is being redelivered - <doc> - This indicates that the message has been previously delivered to - this or another client. - </doc> - <rule implement="SHOULD"> - The server SHOULD try to signal redelivered messages when it can. - When redelivering a message that was not successfully acknowledged, - the server SHOULD deliver it to the original client if possible. - </rule> - <rule implement="MUST"> - The client MUST NOT rely on the redelivered field but MUST take it - as a hint that the message may already have been processed. A - fully robust client must be able to track duplicate received messages - on non-transacted, and locally-transacted channels. - </rule> - </domain> - <domain name="reply code" type="short"> -reply code from server -<doc> - The reply code. The AMQ reply codes are defined in AMQ RFC 011. -</doc> - <assert check="notnull"/> - </domain> - <domain name="reply text" type="shortstr"> -localised reply text -<doc> - The localised reply text. This text can be logged as an aid to - resolving issues. -</doc> - <assert check="notnull"/> - </domain> - <class name="connection" handler="connection" index="10"> - <!-- -====================================================== -== CONNECTION -====================================================== ---> - work with socket connections -<doc> - The connection class provides methods for a client to establish a - network connection to a server, and for both peers to operate the - connection thereafter. -</doc> - <doc name="grammar"> - connection = open-connection *use-connection close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="start" synchronous="1" index="10"> - start connection negotiation - <doc> - This method starts the connection negotiation process by telling - the client the protocol version that the server proposes, along - with a list of security mechanisms which the client can use for - authentication. - </doc> - <rule implement="MUST"> - If the client cannot handle the protocol version suggested by the - server it MUST close the socket connection. - </rule> - <rule implement="MUST"> - The server MUST provide a protocol version that is lower than or - equal to that requested by the client in the protocol header. If - the server cannot support the specified protocol it MUST NOT send - this method, but MUST close the socket connection. - </rule> - <chassis name="client" implement="MUST"/> - <response name="start-ok"/> - <field name="version major" type="octet"> - protocol major version - <doc> - The protocol major version that the server agrees to use, which - cannot be higher than the client's major version. - </doc> - </field> - <field name="version minor" type="octet"> - protocol major version - <doc> - The protocol minor version that the server agrees to use, which - cannot be higher than the client's minor version. - </doc> - </field> - <field name="server properties" domain="peer properties"> - server properties - </field> - <field name="mechanisms" type="longstr"> - available security mechanisms - <doc> - A list of the security mechanisms that the server supports, delimited - by spaces. Currently ASL supports these mechanisms: PLAIN. - </doc> - <see name="security mechanisms"/> - <assert check="notnull"/> - </field> - <field name="locales" type="longstr"> - available message locales - <doc> - A list of the message locales that the server supports, delimited - by spaces. The locale defines the language in which the server - will send reply texts. - </doc> - <rule implement="MUST"> - All servers MUST support at least the en_US locale. - </rule> - <assert check="notnull"/> - </field> - </method> - <method name="start-ok" synchronous="1" index="11"> - select security mechanism and locale - <doc> - This method selects a SASL security mechanism. ASL uses SASL - (RFC2222) to negotiate authentication and encryption. - </doc> - <chassis name="server" implement="MUST"/> - <field name="client properties" domain="peer properties"> - client properties - </field> - <field name="mechanism" type="shortstr"> - selected security mechanism - <doc> - A single security mechanisms selected by the client, which must be - one of those specified by the server. - </doc> - <rule implement="SHOULD"> - The client SHOULD authenticate using the highest-level security - profile it can handle from the list provided by the server. - </rule> - <rule implement="MUST"> - The mechanism field MUST contain one of the security mechanisms - proposed by the server in the Start method. If it doesn't, the - server MUST close the socket. - </rule> - <assert check="notnull"/> - </field> - <field name="response" type="longstr"> - security response data - <doc> - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. For the - PLAIN security mechanism this is defined as a field table holding - two fields, LOGIN and PASSWORD. - </doc> - <assert check="notnull"/> - </field> - <field name="locale" type="shortstr"> - selected message locale - <doc> - A single message local selected by the client, which must be one - of those specified by the server. - </doc> - <assert check="notnull"/> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="secure" synchronous="1" index="20"> - security mechanism challenge - <doc> - The SASL protocol works by exchanging challenges and responses until - both peers have received sufficient information to authenticate each - other. This method challenges the client to provide more information. - </doc> - <chassis name="client" implement="MUST"/> - <response name="secure-ok"/> - <field name="challenge" type="longstr"> - security challenge data - <doc> - Challenge information, a block of opaque binary data passed to - the security mechanism. - </doc> - <see name="security mechanisms"/> - </field> - </method> - <method name="secure-ok" synchronous="1" index="21"> - security mechanism response - <doc> - This method attempts to authenticate, passing a block of SASL data - for the security mechanism at the server side. - </doc> - <chassis name="server" implement="MUST"/> - <field name="response" type="longstr"> - security response data - <doc> - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. - </doc> - <assert check="notnull"/> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="tune" synchronous="1" index="30"> - propose connection tuning parameters - <doc> - This method proposes a set of connection configuration values - to the client. The client can accept and/or adjust these. - </doc> - <chassis name="client" implement="MUST"/> - <response name="tune-ok"/> - <field name="channel max" type="short"> - proposed maximum channels - <doc> - The maximum total number of channels that the server allows - per connection. Zero means that the server does not impose a - fixed limit, but the number of allowed channels may be limited - by available server resources. - </doc> - </field> - <field name="frame max" type="long"> - proposed maximum frame size - <doc> - The largest frame size that the server proposes for the - connection. The client can negotiate a lower value. Zero means - that the server does not impose any specific limit but may reject - very large frames if it cannot allocate resources for them. - </doc> - <rule implement="MUST"> - Until the frame-max has been negotiated, both peers MUST accept - frames of up to 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - </rule> - </field> - <field name="heartbeat" type="short"> - desired heartbeat delay - <doc> - The delay, in seconds, of the connection heartbeat that the server - wants. Zero means the server does not want a heartbeat. - </doc> - </field> - </method> - <method name="tune-ok" synchronous="1" index="31"> - negotiate connection tuning parameters - <doc> - This method sends the client's connection tuning parameters to the - server. Certain fields are negotiated, others provide capability - information. - </doc> - <chassis name="server" implement="MUST"/> - <field name="channel max" type="short"> - negotiated maximum channels - <doc> - The maximum total number of channels that the client will use - per connection. May not be higher than the value specified by - the server. - </doc> - <rule implement="MAY"> - The server MAY ignore the channel-max value or MAY use it for - tuning its resource allocation. - </rule> - <assert check="notnull"/> - <assert check="le" method="tune" field="channel max"/> - </field> - <field name="frame max" type="long"> - negotiated maximum frame size - <doc> - The largest frame size that the client and server will use for - the connection. Zero means that the client does not impose any - specific limit but may reject very large frames if it cannot - allocate resources for them. Note that the frame-max limit - applies principally to content frames, where large contents - can be broken into frames of arbitrary size. - </doc> - <rule implement="MUST"> - Until the frame-max has been negotiated, both peers must accept - frames of up to 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - </rule> - </field> - <field name="heartbeat" type="short"> - desired heartbeat delay - <doc> - The delay, in seconds, of the connection heartbeat that the client - wants. Zero means the client does not want a heartbeat. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="open" synchronous="1" index="40"> - open connection to virtual host - <doc> - This method opens a connection to a virtual host, which is a - collection of resources, and acts to separate multiple application - domains within a server. - </doc> - <rule implement="MUST"> - The client MUST open the context before doing any work on the - connection. - </rule> - <chassis name="server" implement="MUST"/> - <response name="open-ok"/> - <response name="redirect"/> - <field name="virtual host" domain="path"> - virtual host name - <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> - <doc> - The name of the virtual host to work with. - </doc> - <rule implement="MUST"> - If the server supports multiple virtual hosts, it MUST enforce a - full separation of exchanges, queues, and all associated entities - per virtual host. An application, connected to a specific virtual - host, MUST NOT be able to access resources of another virtual host. - </rule> - <rule implement="SHOULD"> - The server SHOULD verify that the client has permission to access - the specified virtual host. - </rule> - <rule implement="MAY"> - The server MAY configure arbitrary limits per virtual host, such - as the number of each type of entity that may be used, per - connection and/or in total. - </rule> - </field> - <field name="capabilities" type="shortstr"> - required capabilities - <doc> - The client may specify a number of capability names, delimited by - spaces. The server can use this string to how to process the - client's connection request. - </doc> - </field> - <field name="insist" type="bit"> - insist on connecting to server - <doc> - In a configuration with multiple load-sharing servers, the server - may respond to a Connection.Open method with a Connection.Redirect. - The insist option tells the server that the client is insisting on - a connection to the specified server. - </doc> - <rule implement="SHOULD"> - When the client uses the insist option, the server SHOULD accept - the client connection unless it is technically unable to do so. - </rule> - </field> - </method> - <method name="open-ok" synchronous="1" index="41"> - signal that the connection is ready - <doc> - This method signals to the client that the connection is ready for - use. - </doc> - <chassis name="client" implement="MUST"/> - <field name="known hosts" domain="known hosts"/> - </method> - <method name="redirect" synchronous="1" index="50"> - asks the client to use a different server - <doc> - This method redirects the client to another server, based on the - requested virtual host and/or capabilities. - </doc> - <rule implement="SHOULD"> - When getting the Connection.Redirect method, the client SHOULD - reconnect to the host specified, and if that host is not present, - to any of the hosts specified in the known-hosts list. - </rule> - <chassis name="client" implement="MAY"/> - <field name="host" type="shortstr"> - server to connect to - <doc> - Specifies the server to connect to. This is an IP address or a - DNS name, optionally followed by a colon and a port number. If - no port number is specified, the client should use the default - port number for the protocol. - </doc> - <assert check="notnull"/> - </field> - <field name="known hosts" domain="known hosts"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="close" synchronous="1" index="60"> - request a connection close - <doc> - This method indicates that the sender wants to close the connection. - This may be due to internal conditions (e.g. a forced shut-down) or - due to an error handling a specific method, i.e. an exception. When - a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - </doc> - <rule implement="MUST"> - After sending this method any received method except the Close-OK - method MUST be discarded. - </rule> - <rule implement="MAY"> - The peer sending this method MAY use a counter or timeout to - detect failure of the other peer to respond correctly with - the Close-OK method. - </rule> - <rule implement="MUST"> - When a server receives the Close method from a client it MUST - delete all server-side resources associated with the client's - context. A client CANNOT reconnect to a context after sending - or receiving a Close method. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="close-ok"/> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <field name="class id" domain="class id"> - failing method class - <doc> - When the close is provoked by a method exception, this is the - class of the method. - </doc> - </field> - <field name="method id" domain="method id"> - failing method ID - <doc> - When the close is provoked by a method exception, this is the - ID of the method. - </doc> - </field> - </method> - <method name="close-ok" synchronous="1" index="61"> - confirm a connection close - <doc> - This method confirms a Connection.Close method and tells the - recipient that it is safe to release resources for the connection - and close the socket. - </doc> - <rule implement="SHOULD"> - A peer that detects a socket closure without having received a - Close-Ok handshake method SHOULD log the error. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - </method> - </class> - <class name="channel" handler="channel" index="20"> - <!-- -====================================================== -== CHANNEL -====================================================== ---> - work with channels -<doc> - The channel class provides methods for a client to establish a virtual - connection - a channel - to a server and for both peers to operate the - virtual connection thereafter. -</doc> - <doc name="grammar"> - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:ALERT - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="open" synchronous="1" index="10"> - open a channel for use - <doc> - This method opens a virtual connection (a channel). - </doc> - <rule implement="MUST"> - This method MUST NOT be called when the channel is already open. - </rule> - <chassis name="server" implement="MUST"/> - <response name="open-ok"/> - <field name="out of band" type="shortstr"> - out-of-band settings - <doc> - Configures out-of-band transfers on this channel. The syntax and - meaning of this field will be formally defined at a later date. - </doc> - <assert check="null"/> - </field> - </method> - <method name="open-ok" synchronous="1" index="11"> - signal that the channel is ready - <doc> - This method signals to the client that the channel is ready for use. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="flow" synchronous="1" index="20"> - enable/disable flow from peer - <doc> - This method asks the peer to pause or restart the flow of content - data. This is a simple flow-control mechanism that a peer can use - to avoid oveflowing its queues or otherwise finding itself receiving - more messages than it can process. Note that this method is not - intended for window control. The peer that receives a request to - stop sending content should finish sending the current content, if - any, and then wait until it receives a Flow restart method. - </doc> - <rule implement="MAY"> - When a new channel is opened, it is active. Some applications - assume that channels are inactive until started. To emulate this - behaviour a client MAY open the channel, then pause it. - </rule> - <rule implement="SHOULD"> - When sending content data in multiple frames, a peer SHOULD monitor - the channel for incoming methods and respond to a Channel.Flow as - rapidly as possible. - </rule> - <rule implement="MAY"> - A peer MAY use the Channel.Flow method to throttle incoming content - data for internal reasons, for example, when exchangeing data over a - slower connection. - </rule> - <rule implement="MAY"> - The peer that requests a Channel.Flow method MAY disconnect and/or - ban a peer that does not respect the request. - </rule> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <response name="flow-ok"/> - <field name="active" type="bit"> - start/stop content frames - <doc> - If 1, the peer starts sending content frames. If 0, the peer - stops sending content frames. - </doc> - </field> - </method> - <method name="flow-ok" index="21"> - confirm a flow method - <doc> - Confirms to the peer that a flow command was received and processed. - </doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <field name="active" type="bit"> - current flow setting - <doc> - Confirms the setting of the processed flow method: 1 means the - peer will start sending or continue to send content frames; 0 - means it will not. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="alert" index="30"> - send a non-fatal warning message - <doc> - This method allows the server to send a non-fatal warning to the - client. This is used for methods that are normally asynchronous - and thus do not have confirmations, and for which the server may - detect errors that need to be reported. Fatal errors are handled - as channel or connection exceptions; non-fatal errors are sent - through this method. - </doc> - <chassis name="client" implement="MUST"/> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <field name="details" type="table"> - detailed information for warning - <doc> - A set of fields that provide more information about the - problem. The meaning of these fields are defined on a - per-reply-code basis (TO BE DEFINED). - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="close" synchronous="1" index="40"> - request a channel close - <doc> - This method indicates that the sender wants to close the channel. - This may be due to internal conditions (e.g. a forced shut-down) or - due to an error handling a specific method, i.e. an exception. When - a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - </doc> - <rule implement="MUST"> - After sending this method any received method except - Channel.Close-OK MUST be discarded. - </rule> - <rule implement="MAY"> - The peer sending this method MAY use a counter or timeout to detect - failure of the other peer to respond correctly with Channel.Close-OK.. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="close-ok"/> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <field name="class id" domain="class id"> - failing method class - <doc> - When the close is provoked by a method exception, this is the - class of the method. - </doc> - </field> - <field name="method id" domain="method id"> - failing method ID - <doc> - When the close is provoked by a method exception, this is the - ID of the method. - </doc> - </field> - </method> - <method name="close-ok" synchronous="1" index="41"> - confirm a channel close - <doc> - This method confirms a Channel.Close method and tells the recipient - that it is safe to release resources for the channel and close the - socket. - </doc> - <rule implement="SHOULD"> - A peer that detects a socket closure without having received a - Channel.Close-Ok handshake method SHOULD log the error. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - </method> - </class> - <class name="access" handler="connection" index="30"> - <!-- -====================================================== -== ACCESS CONTROL -====================================================== ---> - work with access tickets -<doc> - The protocol control access to server resources using access tickets. - A client must explicitly request access tickets before doing work. - An access ticket grants a client the right to use a specific set of - resources - called a "realm" - in specific ways. -</doc> - <doc name="grammar"> - access = C:REQUEST S:REQUEST-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="request" synchronous="1" index="10"> - request an access ticket - <doc> - This method requests an access ticket for an access realm. - The server responds by granting the access ticket. If the - client does not have access rights to the requested realm - this causes a connection exception. Access tickets are a - per-channel resource. - </doc> - <rule implement="MUST"> - The realm name MUST start with either "/data" (for application - resources) or "/admin" (for server administration resources). - If the realm starts with any other path, the server MUST raise - a connection exception with reply code 403 (access refused). - </rule> - <rule implement="MUST"> - The server MUST implement the /data realm and MAY implement the - /admin realm. The mapping of resources to realms is not - defined in the protocol - this is a server-side configuration - issue. - </rule> - <chassis name="server" implement="MUST"/> - <response name="request-ok"/> - <field name="realm" domain="path"> - name of requested realm - <rule implement="MUST"> - If the specified realm is not known to the server, the server - must raise a channel exception with reply code 402 (invalid - path). - </rule> - </field> - <field name="exclusive" type="bit"> - request exclusive access - <doc> - Request exclusive access to the realm. If the server cannot grant - this - because there are other active tickets for the realm - it - raises a channel exception. - </doc> - </field> - <field name="passive" type="bit"> - request passive access - <doc> - Request message passive access to the specified access realm. - Passive access lets a client get information about resources in - the realm but not to make any changes to them. - </doc> - </field> - <field name="active" type="bit"> - request active access - <doc> - Request message active access to the specified access realm. - Acvtive access lets a client get create and delete resources in - the realm. - </doc> - </field> - <field name="write" type="bit"> - request write access - <doc> - Request write access to the specified access realm. Write access - lets a client publish messages to all exchanges in the realm. - </doc> - </field> - <field name="read" type="bit"> - request read access - <doc> - Request read access to the specified access realm. Read access - lets a client consume messages from queues in the realm. - </doc> - </field> - </method> - <method name="request-ok" synchronous="1" index="11"> - grant access to server resources - <doc> - This method provides the client with an access ticket. The access - ticket is valid within the current channel and for the lifespan of - the channel. - </doc> - <rule implement="MUST"> - The client MUST NOT use access tickets except within the same - channel as originally granted. - </rule> - <rule implement="MUST"> - The server MUST isolate access tickets per channel and treat an - attempt by a client to mix these as a connection exception. - </rule> - <chassis name="client" implement="MUST"/> - <field name="ticket" domain="access ticket"/> - </method> - </class> - <class name="exchange" handler="channel" index="40"> - <!-- -====================================================== -== EXCHANGES (or "routers", if you prefer) -== (Or matchers, plugins, extensions, agents,... Routing is just one of -== the many fun things an exchange can do.) -====================================================== ---> - work with exchanges -<doc> - Exchanges match and distribute messages across queues. Exchanges can be - configured in the server or created at runtime. -</doc> - <doc name="grammar"> - exchange = C:DECLARE S:DECLARE-OK - / C:DELETE S:DELETE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <rule implement="MUST"> - <test>amq_exchange_19</test> - The server MUST implement the direct and fanout exchange types, and - predeclare the corresponding exchanges named amq.direct and amq.fanout - in each virtual host. The server MUST also predeclare a direct - exchange to act as the default exchange for content Publish methods - and for default queue bindings. -</rule> - <rule implement="SHOULD"> - <test>amq_exchange_20</test> - The server SHOULD implement the topic exchange type, and predeclare - the corresponding exchange named amq.topic in each virtual host. -</rule> - <rule implement="MAY"> - <test>amq_exchange_21</test> - The server MAY implement the system exchange type, and predeclare the - corresponding exchanges named amq.system in each virtual host. If the - client attempts to bind a queue to the system exchange, the server - MUST raise a connection exception with reply code 507 (not allowed). -</rule> - <rule implement="MUST"> - <test>amq_exchange_22</test> - The default exchange MUST be defined as internal, and be inaccessible - to the client except by specifying an empty exchange name in a content - Publish method. That is, the server MUST NOT let clients make explicit - bindings to this exchange. -</rule> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="declare" synchronous="1" index="10"> - declare exchange, create if needed - <doc> - This method creates an exchange if it does not already exist, and if the - exchange exists, verifies that it is of the correct and expected class. - </doc> - <rule implement="SHOULD"> - <test>amq_exchange_23</test> - The server SHOULD support a minimum of 16 exchanges per virtual host - and ideally, impose no limit except as defined by available resources. - </rule> - <chassis name="server" implement="MUST"/> - <response name="declare-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - When a client defines a new exchange, this belongs to the access realm - of the ticket used. All further work done with that exchange must be - done with an access ticket for the same realm. - </doc> - <rule implement="MUST"> - The client MUST provide a valid access ticket giving "active" access - to the realm in which the exchange exists or will be created, or - "passive" access if the if-exists flag is set. - </rule> - </field> - <field name="exchange" domain="exchange name"> - <rule implement="MUST"> - <test>amq_exchange_15</test> - Exchange names starting with "amq." are reserved for predeclared - and standardised exchanges. If the client attempts to create an - exchange starting with "amq.", the server MUST raise a channel - exception with reply code 403 (access refused). - </rule> - <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> - </field> - <field name="type" type="shortstr"> - exchange type - <doc> - Each exchange belongs to one of a set of exchange types implemented - by the server. The exchange types define the functionality of the - exchange - i.e. how messages are routed through it. It is not valid - or meaningful to attempt to change the type of an existing exchange. - </doc> - <rule implement="MUST"> - <test>amq_exchange_16</test> - If the exchange already exists with a different type, the server - MUST raise a connection exception with a reply code 507 (not allowed). - </rule> - <rule implement="MUST"> - <test>amq_exchange_18</test> - If the server does not support the requested exchange type it MUST - raise a connection exception with a reply code 503 (command invalid). - </rule> - <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> - </field> - <field name="passive" type="bit"> - do not create exchange - <doc> - If set, the server will not create the exchange. The client can use - this to check whether an exchange exists without modifying the server - state. - </doc> - <rule implement="MUST"> - <test>amq_exchange_05</test> - If set, and the exchange does not already exist, the server MUST - raise a channel exception with reply code 404 (not found). - </rule> - </field> - <field name="durable" type="bit"> - request a durable exchange - <doc> - If set when creating a new exchange, the exchange will be marked as - durable. Durable exchanges remain active when a server restarts. - Non-durable exchanges (transient exchanges) are purged if/when a - server restarts. - </doc> - <rule implement="MUST"> - <test>amq_exchange_24</test> - The server MUST support both durable and transient exchanges. - </rule> - <rule implement="MUST"> - The server MUST ignore the durable field if the exchange already - exists. - </rule> - </field> - <field name="auto delete" type="bit"> - auto-delete when unused - <doc> - If set, the exchange is deleted when all queues have finished - using it. - </doc> - <rule implement="SHOULD"> - <test>amq_exchange_02</test> - The server SHOULD allow for a reasonable delay between the point - when it determines that an exchange is not being used (or no longer - used), and the point when it deletes the exchange. At the least it - must allow a client to create an exchange and then bind a queue to - it, with a small but non-zero delay between these two actions. - </rule> - <rule implement="MUST"> - <test>amq_exchange_25</test> - The server MUST ignore the auto-delete field if the exchange already - exists. - </rule> - </field> - <field name="internal" type="bit"> - create internal exchange - <doc> - If set, the exchange may not be used directly by publishers, but - only when bound to other exchanges. Internal exchanges are used to - construct wiring that is not visible to applications. - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table"> - arguments for declaration - <doc> - A set of arguments for the declaration. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - </doc> - </field> - </method> - <method name="declare-ok" synchronous="1" index="11"> - confirms an exchange declaration - <doc> - This method confirms a Declare method and confirms the name of the - exchange, essential for automatically-named exchanges. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="delete" synchronous="1" index="20"> - delete an exchange - <doc> - This method deletes an exchange. When an exchange is deleted all queue - bindings on the exchange are cancelled. - </doc> - <chassis name="server" implement="MUST"/> - <response name="delete-ok"/> - <field name="ticket" domain="access ticket"> - <rule implement="MUST"> - The client MUST provide a valid access ticket giving "active" - access rights to the exchange's access realm. - </rule> - </field> - <field name="exchange" domain="exchange name"> - <rule implement="MUST"> - <test>amq_exchange_11</test> - The exchange MUST exist. Attempting to delete a non-existing exchange - causes a channel exception. - </rule> - <assert check="notnull"/> - </field> - <field name="if unused" type="bit"> - delete only if unused - <doc> - If set, the server will only delete the exchange if it has no queue - bindings. If the exchange has queue bindings the server does not - delete it but raises a channel exception instead. - </doc> - <rule implement="SHOULD"> - <test>amq_exchange_12</test> - If set, the server SHOULD delete the exchange but only if it has - no queue bindings. - </rule> - <rule implement="SHOULD"> - <test>amq_exchange_13</test> - If set, the server SHOULD raise a channel exception if the exchange is in - use. - </rule> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - </method> - <method name="delete-ok" synchronous="1" index="21"> - confirm deletion of an exchange - <doc> - This method confirms the deletion of an exchange. - </doc> - <chassis name="client" implement="MUST"/> - </method> - - <method name="bound" synchronous="1" index="22"> - <chassis name="server" implement="SHOULD"/> - <field name="exchange" domain="exchange name"/> - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - <field name = "queue" domain = "queue name"/> - </method> - - <method name="bound-ok" synchronous="1" index="23"> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <chassis name="client" implement="SHOULD"/> - </method> - - </class> - - - <class name="queue" handler="channel" index="50"> - <!-- -====================================================== -== QUEUES -====================================================== ---> - work with queues - -<doc> - Queues store and forward messages. Queues can be configured in the server - or created at runtime. Queues must be attached to at least one exchange - in order to receive messages from publishers. -</doc> - <doc name="grammar"> - queue = C:DECLARE S:DECLARE-OK - / C:BIND S:BIND-OK - / C:PURGE S:PURGE-OK - / C:DELETE S:DELETE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <rule implement="MUST"> - <test>amq_queue_33</test> - A server MUST allow any content class to be sent to any queue, in any - mix, and queue and delivery these content classes independently. Note - that all methods that fetch content off queues are specific to a given - content class. -</rule> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="declare" synchronous="1" index="10"> - declare queue, create if needed - <doc> - This method creates or checks a queue. When creating a new queue - the client can specify various properties that control the durability - of the queue and its contents, and the level of sharing for the queue. - </doc> - <rule implement="MUST"> - <test>amq_queue_34</test> - The server MUST create a default binding for a newly-created queue - to the default exchange, which is an exchange of type 'direct'. - </rule> - <rule implement="SHOULD"> - <test>amq_queue_35</test> - The server SHOULD support a minimum of 256 queues per virtual host - and ideally, impose no limit except as defined by available resources. - </rule> - <chassis name="server" implement="MUST"/> - <response name="declare-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - When a client defines a new queue, this belongs to the access realm - of the ticket used. All further work done with that queue must be - done with an access ticket for the same realm. - </doc> - <doc> - The client provides a valid access ticket giving "active" access - to the realm in which the queue exists or will be created, or - "passive" access if the if-exists flag is set. - </doc> - </field> - <field name="queue" domain="queue name"> - <rule implement="MAY"> - <test>amq_queue_10</test> - The queue name MAY be empty, in which case the server MUST create - a new queue with a unique generated name and return this to the - client in the Declare-Ok method. - </rule> - <rule implement="MUST"> - <test>amq_queue_32</test> - Queue names starting with "amq." are reserved for predeclared and - standardised server queues. If the queue name starts with "amq." - and the passive option is zero, the server MUST raise a connection - exception with reply code 403 (access refused). - </rule> - <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> - </field> - <field name="passive" type="bit"> - do not create queue - <doc> - If set, the server will not create the queue. The client can use - this to check whether a queue exists without modifying the server - state. - </doc> - <rule implement="MUST"> - <test>amq_queue_05</test> - If set, and the queue does not already exist, the server MUST - respond with a reply code 404 (not found) and raise a channel - exception. - </rule> - </field> - <field name="durable" type="bit"> - request a durable queue - <doc> - If set when creating a new queue, the queue will be marked as - durable. Durable queues remain active when a server restarts. - Non-durable queues (transient queues) are purged if/when a - server restarts. Note that durable queues do not necessarily - hold persistent messages, although it does not make sense to - send persistent messages to a transient queue. - </doc> - <rule implement="MUST"> - <test>amq_queue_03</test> - The server MUST recreate the durable queue after a restart. - </rule> - <rule implement="MUST"> - <test>amq_queue_36</test> - The server MUST support both durable and transient queues. - </rule> - <rule implement="MUST"> - <test>amq_queue_37</test> - The server MUST ignore the durable field if the queue already - exists. - </rule> - </field> - <field name="exclusive" type="bit"> - request an exclusive queue - <doc> - Exclusive queues may only be consumed from by the current connection. - Setting the 'exclusive' flag always implies 'auto-delete'. - </doc> - <rule implement="MUST"> - <test>amq_queue_38</test> - The server MUST support both exclusive (private) and non-exclusive - (shared) queues. - </rule> - <rule implement="MUST"> - <test>amq_queue_04</test> - The server MUST raise a channel exception if 'exclusive' is specified - and the queue already exists and is owned by a different connection. - </rule> - </field> - <field name="auto delete" type="bit"> - auto-delete queue when unused - <doc> - If set, the queue is deleted when all consumers have finished - using it. Last consumer can be cancelled either explicitly or because - its channel is closed. If there was no consumer ever on the queue, it - won't be deleted. - </doc> - <rule implement="SHOULD"> - <test>amq_queue_02</test> - The server SHOULD allow for a reasonable delay between the point - when it determines that a queue is not being used (or no longer - used), and the point when it deletes the queue. At the least it - must allow a client to create a queue and then create a consumer - to read from it, with a small but non-zero delay between these - two actions. The server should equally allow for clients that may - be disconnected prematurely, and wish to re-consume from the same - queue without losing messages. We would recommend a configurable - timeout, with a suitable default value being one minute. - </rule> - <rule implement="MUST"> - <test>amq_queue_31</test> - The server MUST ignore the auto-delete field if the queue already - exists. - </rule> - </field> - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table"> - arguments for declaration - <doc> - A set of arguments for the declaration. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - </doc> - </field> - </method> - <method name="declare-ok" synchronous="1" index="11"> - confirms a queue definition - <doc> - This method confirms a Declare method and confirms the name of the - queue, essential for automatically-named queues. - </doc> - <chassis name="client" implement="MUST"/> - <field name="queue" domain="queue name"> - <doc> - Reports the name of the queue. If the server generated a queue - name, this field contains that name. - </doc> - <assert check="notnull"/> - </field> - <field name="message count" type="long"> - number of messages in queue - <doc> - Reports the number of messages in the queue, which will be zero - for newly-created queues. - </doc> - </field> - <field name="consumer count" type="long"> - number of consumers - <doc> - Reports the number of active consumers for the queue. Note that - consumers can suspend activity (Channel.Flow) in which case they - do not appear in this count. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="bind" synchronous="1" index="20"> - bind queue to an exchange - <doc> - This method binds a queue to an exchange. Until a queue is - bound it will not receive any messages. In a classic messaging - model, store-and-forward queues are bound to a dest exchange - and subscription queues are bound to a dest_wild exchange. - </doc> - <rule implement="MUST"> - <test>amq_queue_25</test> - A server MUST allow ignore duplicate bindings - that is, two or - more bind methods for a specific queue, with identical arguments - - without treating these as an error. - </rule> - <rule implement="MUST"> - <test>amq_queue_39</test> - If a bind fails, the server MUST raise a connection exception. - </rule> - <rule implement="MUST"> - <test>amq_queue_12</test> - The server MUST NOT allow a durable queue to bind to a transient - exchange. If the client attempts this the server MUST raise a - channel exception. - </rule> - <rule implement="SHOULD"> - <test>amq_queue_13</test> - Bindings for durable queues are automatically durable and the - server SHOULD restore such bindings after a server restart. - </rule> - <rule implement="MUST"> - <test>amq_queue_17</test> - If the client attempts to an exchange that was declared as internal, - the server MUST raise a connection exception with reply code 530 - (not allowed). - </rule> - <rule implement="SHOULD"> - <test>amq_queue_40</test> - The server SHOULD support at least 4 bindings per queue, and - ideally, impose no limit except as defined by available resources. - </rule> - <chassis name="server" implement="MUST"/> - <response name="bind-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to bind. If the queue name is - empty, refers to the current queue for the channel, which is - the last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - </doc> - <doc name = "rule" test = "amq_queue_26"> - If the queue does not exist the server MUST raise a channel exception - with reply code 404 (not found). - </doc> - </field> - - <field name="exchange" domain="exchange name"> - The name of the exchange to bind to. - <rule implement="MUST"> - <test>amq_queue_14</test> - If the exchange does not exist the server MUST raise a channel - exception with reply code 404 (not found). - </rule> - </field> - <field name="routing key" type="shortstr"> - message routing key - <doc> - Specifies the routing key for the binding. The routing key is - used for routing messages depending on the exchange configuration. - Not all exchanges use a routing key - refer to the specific - exchange documentation. If the routing key is empty and the queue - name is empty, the routing key will be the current queue for the - channel, which is the last declared queue. - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table"> - arguments for binding - <doc> - A set of arguments for the binding. The syntax and semantics of - these arguments depends on the exchange class. - </doc> - </field> - </method> - <method name="bind-ok" synchronous="1" index="21"> - confirm bind successful - <doc> - This method confirms that the bind was successful. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="purge" synchronous="1" index="30"> - purge a queue - <doc> - This method removes all messages from a queue. It does not cancel - consumers. Purged messages are deleted without any formal "undo" - mechanism. - </doc> - <rule implement="MUST"> - <test>amq_queue_15</test> - A call to purge MUST result in an empty queue. - </rule> - <rule implement="MUST"> - <test>amq_queue_41</test> - On transacted channels the server MUST not purge messages that have - already been sent to a client but not yet acknowledged. - </rule> - <rule implement="MAY"> - <test>amq_queue_42</test> - The server MAY implement a purge queue or log that allows system - administrators to recover accidentally-purged messages. The server - SHOULD NOT keep purged messages in the same storage spaces as the - live messages since the volumes of purged messages may get very - large. - </rule> - <chassis name="server" implement="MUST"/> - <response name="purge-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - The access ticket must be for the access realm that holds the - queue. - </doc> - <rule implement="MUST"> - The client MUST provide a valid access ticket giving "read" access - rights to the queue's access realm. Note that purging a queue is - equivalent to reading all messages and discarding them. - </rule> - </field> - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to purge. If the queue name is - empty, refers to the current queue for the channel, which is - the last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - </doc> - <doc name = "rule" test = "amq_queue_16"> - The queue must exist. Attempting to purge a non-existing queue - causes a channel exception. - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - </method> - <method name="purge-ok" synchronous="1" index="31"> - confirms a queue purge - <doc> - This method confirms the purge of a queue. - </doc> - <chassis name="client" implement="MUST"/> - <field name="message count" type="long"> - number of messages purged - <doc> - Reports the number of messages purged. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="delete" synchronous="1" index="40"> - delete a queue - <doc> - This method deletes a queue. When a queue is deleted any pending - messages are sent to a dead-letter queue if this is defined in the - server configuration, and all consumers on the queue are cancelled. - </doc> - <rule implement="SHOULD"> - <test>amq_queue_43</test> - The server SHOULD use a dead-letter queue to hold messages that - were pending on a deleted queue, and MAY provide facilities for - a system administrator to move these messages back to an active - queue. - </rule> - <chassis name="server" implement="MUST"/> - <response name="delete-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to delete. If the queue name is - empty, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - </doc> - <doc name = "rule" test = "amq_queue_21"> - The queue must exist. Attempting to delete a non-existing queue - causes a channel exception. - </doc> - </field> - - <field name="if unused" type="bit"> - delete only if unused - <doc> - If set, the server will only delete the queue if it has no - consumers. If the queue has consumers the server does does not - delete it but raises a channel exception instead. - </doc> - <rule implement="MUST"> - <test>amq_queue_29</test> - <test>amq_queue_30</test> - The server MUST respect the if-unused flag when deleting a queue. - </rule> - </field> - <field name="if empty" type="bit"> - delete only if empty - <test>amq_queue_27</test> - <doc> - If set, the server will only delete the queue if it has no - messages. If the queue is not empty the server raises a channel - exception. - </doc> - </field> - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - </method> - - <method name="delete-ok" synchronous="1" index="41"> - confirm deletion of a queue - <doc> - This method confirms the deletion of a queue. - </doc> - <chassis name="client" implement="MUST"/> - <field name="message count" type="long"> - number of messages purged - <doc> - Reports the number of messages purged. - </doc> - </field> - </method> - </class> - <class name="basic" handler="channel" index="60"> - <!-- -====================================================== -== BASIC MIDDLEWARE -====================================================== ---> - work with basic content -<doc> - The Basic class provides methods that support an industry-standard - messaging model. -</doc> - -<doc name = "grammar"> - basic = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT -</doc> - -<chassis name = "server" implement = "MUST" /> -<chassis name = "client" implement = "MAY" /> - -<doc name = "rule" test = "amq_basic_08"> - The server SHOULD respect the persistent property of basic messages - and SHOULD make a best-effort to hold persistent basic messages on a - reliable storage mechanism. -</doc> -<doc name = "rule" test = "amq_basic_09"> - The server MUST NOT discard a persistent basic message in case of a - queue overflow. The server MAY use the Channel.Flow method to slow - or stop a basic message publisher when necessary. -</doc> -<doc name = "rule" test = "amq_basic_10"> - The server MAY overflow non-persistent basic messages to persistent - storage and MAY discard or dead-letter non-persistent basic messages - on a priority basis if the queue size exceeds some configured limit. -</doc> -<doc name = "rule" test = "amq_basic_11"> - The server MUST implement at least 2 priority levels for basic - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. -</doc> -<doc name = "rule" test = "amq_basic_12"> - The server MUST deliver messages of the same priority in order - irrespective of their individual persistence. -</doc> -<doc name = "rule" test = "amq_basic_13"> - The server MUST support both automatic and explicit acknowledgements - on Basic content. -</doc> - -<!-- These are the properties for a Basic content --> - -<field name = "content type" type = "shortstr"> - MIME content type -</field> -<field name = "content encoding" type = "shortstr"> - MIME content encoding -</field> -<field name = "headers" type = "table"> - Message header field table -</field> -<field name = "delivery mode" type = "octet"> - Non-persistent (1) or persistent (2) -</field> -<field name = "priority" type = "octet"> - The message priority, 0 to 9 -</field> -<field name = "correlation id" type = "shortstr"> - The application correlation identifier -</field> -<field name = "reply to" type = "shortstr"> - The destination to reply to -</field> -<field name = "expiration" type = "shortstr"> - Message expiration specification -</field> -<field name = "message id" type = "shortstr"> - The application message identifier -</field> -<field name = "timestamp" type = "timestamp"> - The message timestamp -</field> -<field name = "type" type = "shortstr"> - The message type name -</field> -<field name = "user id" type = "shortstr"> - The creating user id -</field> -<field name = "app id" type = "shortstr"> - The creating application id -</field> -<field name = "cluster id" type = "shortstr"> - Intra-cluster routing identifier -</field> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "qos" synchronous = "1" index = "10"> - specify quality of service - <doc> - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch size" type = "long"> - prefetch window in octets - <doc> - The client can request that messages be sent in advance so that - when the client finishes processing a message, the following - message is already held locally, rather than needing to be sent - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. The - server will send a message in advance if it is equal to or - smaller in size than the available prefetch size (and also falls - into other prefetch limits). May be set to zero, meaning "no - specific limit", although other prefetch limits may still apply. - The prefetch-size is ignored if the no-ack option is set. - </doc> - <doc name = "rule" test = "amq_basic_17"> - The server MUST ignore this setting when the client is not - processing any messages - i.e. the prefetch size does not limit - the transfer of single messages to a client, only the sending in - advance of more messages while the client still has one or more - unacknowledged messages. - </doc> - </field> - - <field name = "prefetch count" type = "short"> - prefetch window in messages - <doc> - Specifies a prefetch window in terms of whole messages. This - field may be used in combination with the prefetch-size field; - a message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - The prefetch-count is ignored if the no-ack option is set. - </doc> - <doc name = "rule" test = "amq_basic_18"> - The server MAY send less data in advance than allowed by the - client's specified prefetch windows but it MUST NOT send more. - </doc> - </field> - - <field name = "global" type = "bit"> - apply to entire connection - <doc> - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - </doc> - </field> -</method> - -<method name = "qos-ok" synchronous = "1" index = "11"> - confirm the requested qos - <doc> - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - </doc> - <chassis name = "client" implement = "MUST" /> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "consume" synchronous = "1" index = "20"> - start a queue consumer - <doc> - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - </doc> - <doc name = "rule" test = "amq_basic_01"> - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - </doc> - <doc name = "rule" test = "todo"> - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - </doc> - </field> - - <field name = "no local" domain = "no local" /> - - <field name = "no ack" domain = "no ack" /> - - <field name = "exclusive" type = "bit"> - request exclusive access - <doc> - Request exclusive consumer access, meaning only this consumer can - access the queue. - </doc> - <doc name = "rule" test = "amq_basic_02"> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 403 (access refused). - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - </doc> - </field> -</method> - -<method name = "consume-ok" synchronous = "1" index = "21"> - confirm a new consumer - <doc> - The server provides the client with a consumer tag, which is used - by the client for methods called on the consumer at a later stage. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Holds the consumer tag specified by the client or provided by - the server. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "cancel" synchronous = "1" index = "30"> - end a queue consumer - <doc test = "amq_basic_04"> - This method cancels a consumer. This does not affect already - delivered messages, but it does mean the server will not send any - more messages for that consumer. The client may receive an - abitrary number of messages in between sending the cancel method - and receiving the cancel-ok reply. - </doc> - <doc name = "rule" test = "todo"> - If the queue no longer exists when the client sends a cancel command, - or the consumer has been cancelled for other reasons, this command - has no effect. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "cancel-ok" synchronous = "1" index = "31"> - confirm a cancelled consumer - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "publish" content = "1" index = "40"> - publish a message - <doc> - This method publishes a message to a specific exchange. The message - will be routed to queues as defined by the exchange configuration - and distributed to any active consumers when the transaction, if any, - is committed. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - </doc> - </field> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - </doc> - <doc name = "rule" test = "amq_basic_06"> - The server MUST accept a blank exchange name to mean the default - exchange. - </doc> - <doc name = "rule" test = "amq_basic_14"> - If the exchange was declared as an internal exchange, the server - MUST raise a channel exception with a reply code 403 (access - refused). - </doc> - <doc name = "rule" test = "amq_basic_15"> - The exchange MAY refuse basic content in which case it MUST raise - a channel exception with reply code 540 (not implemented). - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" type = "bit"> - indicate mandatory routing - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - </doc> - <doc name = "rule" test = "amq_basic_07"> - The server SHOULD implement the mandatory flag. - </doc> - </field> - - <field name = "immediate" type = "bit"> - request immediate delivery - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - <doc name = "rule" test = "amq_basic_16"> - The server SHOULD implement the immediate flag. - </doc> - </field> -</method> - -<method name = "return" content = "1" index = "50"> - return a failed message - <doc> - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "reply code" domain = "reply code" /> - <field name = "reply text" domain = "reply text" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "deliver" content = "1" index = "60"> - notify the client of a consumer message - <doc> - This method delivers a message to the client, via a consumer. In - the asynchronous message delivery model, the client starts a - consumer using the Consume method, then the server responds with - Deliver methods as and when messages arrive for that consumer. - </doc> - <doc name = "rule" test = "amq_basic_19"> - The server SHOULD track the number of times a message has been - delivered to clients and when a message is redelivered a certain - number of times - e.g. 5 times - without being acknowledged, the - server SHOULD consider the message to be unprocessable (possibly - causing client applications to abort), and move the message to a - dead letter queue. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "get" synchronous = "1" index = "70"> - direct access to a queue - <doc> - This method provides a direct access to the messages in a queue - using a synchronous dialogue that is designed for specific types of - application where synchronous functionality is more important than - performance. - </doc> - <response name = "get-ok" /> - <response name = "get-empty" /> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" - access rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "no ack" domain = "no ack" /> -</method> - -<method name = "get-ok" synchronous = "1" content = "1" index = "71"> - provide client with a message - <doc> - This method delivers a message to the client following a get - method. A message delivered by 'get-ok' must be acknowledged - unless the no-ack option was set in the get method. - </doc> - <chassis name = "client" implement = "MAY" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was originally - published to. If empty, the message was published to the default - exchange. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> - - <field name = "message count" type = "long" > - number of messages pending - <doc> - This field reports the number of messages pending on the queue, - excluding the message being delivered. Note that this figure is - indicative, not reliable, and can change arbitrarily as messages - are added to the queue and removed by other clients. - </doc> - </field> -</method> - - -<method name = "get-empty" synchronous = "1" index = "72"> - indicate no messages available - <doc> - This method tells the client that the queue has no messages - available for the client. - </doc> - <chassis name = "client" implement = "MAY" /> - - <field name = "cluster id" type = "shortstr"> - Cluster id - <doc> - For use by cluster applications, should not be used by - client applications. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "ack" index = "80"> - acknowledge one or more messages - <doc> - This method acknowledges one or more messages delivered via the - Deliver or Get-Ok methods. The client can ask to confirm a - single message or a set of messages up to and including a specific - message. - </doc> - <chassis name = "server" implement = "MUST" /> - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "multiple" type = "bit"> - acknowledge multiple messages - <doc> - If set to 1, the delivery tag is treated as "up to and including", - so that the client can acknowledge multiple messages with a single - method. If set to zero, the delivery tag refers to a single - message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding mesages. - </doc> - <doc name = "rule" test = "amq_basic_20"> - The server MUST validate that a non-zero delivery-tag refers to an - delivered message, and raise a channel exception if this is not the - case. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "reject" index = "90"> - reject an incoming message - <doc> - This method allows a client to reject a message. It can be used to - interrupt and cancel large incoming messages, or return untreatable - messages to their original queue. - </doc> - <doc name = "rule" test = "amq_basic_21"> - The server SHOULD be capable of accepting and process the Reject - method while sending message content with a Deliver or Get-Ok - method. I.e. the server should read and process incoming methods - while sending output frames. To cancel a partially-send content, - the server sends a content body frame of size 1 (i.e. with no data - except the frame-end octet). - </doc> - <doc name = "rule" test = "amq_basic_22"> - The server SHOULD interpret this method as meaning that the client - is unable to process the message at this time. - </doc> - <doc name = "rule"> - A client MUST NOT use this method as a means of selecting messages - to process. A rejected message MAY be discarded or dead-lettered, - not necessarily passed to another client. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be discarded. If this bit - is 1, the server will attempt to requeue the message. - </doc> - <doc name = "rule" test = "amq_basic_23"> - The server MUST NOT deliver the message to the same client within - the context of the current channel. The recommended strategy is - to attempt to deliver the message to an alternative consumer, and - if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold - the message on the queue and redeliver it to the same client at - a later stage. - </doc> - </field> -</method> - -<method name = "recover" index = "100"> - redeliver unacknowledged messages - <doc> - This method asks the broker to redeliver all unacknowledged messages on a - specified channel. Zero or more messages may be redelivered. This method - is only allowed on non-transacted channels. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the - message, potentially then delivering it to an alternative subscriber. - </doc> - </field> - <doc name="rule"> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - <doc name="rule"> - The server MUST raise a channel exception if this is called on a - transacted channel. - </doc> - <response name="recover-ok"/> - </method> - <method name="recover-ok" synchronous="1" index="101"> - confirm a successful recover - <doc> - This method confirms to the client that the recover succeeded. - Note that if an recover fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - -</class> - - - <class name="file" handler="channel" index="70"> - <!-- -====================================================== -== FILE TRANSFER -====================================================== ---> - work with file content -<doc> - The file class provides methods that support reliable file transfer. - File messages have a specific set of properties that are required for - interoperability with file transfer applications. File messages and - acknowledgements are subject to channel transactions. Note that the - file class does not provide message browsing methods; these are not - compatible with the staging model. Applications that need browsable - file transfer should use Basic content and the Basic class. -</doc> - -<doc name = "grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT -</doc> - -<chassis name = "server" implement = "MAY" /> -<chassis name = "client" implement = "MAY" /> - -<doc name = "rule"> - The server MUST make a best-effort to hold file messages on a - reliable storage mechanism. -</doc> -<doc name = "rule"> - The server MUST NOT discard a file message in case of a queue - overflow. The server MUST use the Channel.Flow method to slow or stop - a file message publisher when necessary. -</doc> -<doc name = "rule"> - The server MUST implement at least 2 priority levels for file - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. -</doc> -<doc name = "rule"> - The server MUST support both automatic and explicit acknowledgements - on file content. -</doc> - -<!-- These are the properties for a File content --> - -<field name = "content type" type = "shortstr"> - MIME content type -</field> -<field name = "content encoding" type = "shortstr"> - MIME content encoding -</field> -<field name = "headers" type = "table"> - Message header field table -</field> -<field name = "priority" type = "octet"> - The message priority, 0 to 9 -</field> -<field name = "reply to" type = "shortstr"> - The destination to reply to -</field> -<field name = "message id" type = "shortstr"> - The application message identifier -</field> -<field name = "filename" type = "shortstr"> - The message filename -</field> -<field name = "timestamp" type = "timestamp"> - The message timestamp -</field> -<field name = "cluster id" type = "shortstr"> - Intra-cluster routing identifier -</field> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "qos" synchronous = "1" index = "10"> - specify quality of service - <doc> - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch size" type = "long"> - prefetch window in octets - <doc> - The client can request that messages be sent in advance so that - when the client finishes processing a message, the following - message is already held locally, rather than needing to be sent - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. May be - set to zero, meaning "no specific limit". Note that other - prefetch limits may still apply. The prefetch-size is ignored - if the no-ack option is set. - </doc> - </field> - - <field name = "prefetch count" type = "short"> - prefetch window in messages - <doc> - Specifies a prefetch window in terms of whole messages. This - is compatible with some file API implementations. This field - may be used in combination with the prefetch-size field; a - message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - The prefetch-count is ignored if the no-ack option is set. - </doc> - <doc name = "rule"> - The server MAY send less data in advance than allowed by the - client's specified prefetch windows but it MUST NOT send more. - </doc> - </field> - - <field name = "global" type = "bit"> - apply to entire connection - <doc> - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - </doc> - </field> -</method> - -<method name = "qos-ok" synchronous = "1" index = "11"> - confirm the requested qos - <doc> - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - </doc> - <chassis name = "client" implement = "MUST" /> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "consume" synchronous = "1" index = "20"> - start a queue consumer - <doc> - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - </doc> - <doc name = "rule"> - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - </doc> - <doc name = "rule" test = "todo"> - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - </doc> - </field> - - <field name = "no local" domain = "no local" /> - - <field name = "no ack" domain = "no ack" /> - - <field name = "exclusive" type = "bit"> - request exclusive access - <doc> - Request exclusive consumer access, meaning only this consumer can - access the queue. - </doc> - <doc name = "rule" test = "amq_file_00"> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 405 (resource locked). - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "consume-ok" synchronous = "1" index = "21"> - confirm a new consumer - <doc> - This method provides the client with a consumer tag which it MUST - use in methods that work with the consumer. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Holds the consumer tag specified by the client or provided by - the server. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "cancel" synchronous = "1" index = "30"> - end a queue consumer - <doc> - This method cancels a consumer. This does not affect already - delivered messages, but it does mean the server will not send any - more messages for that consumer. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "cancel-ok" synchronous = "1" index = "31"> - confirm a cancelled consumer - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "open" synchronous = "1" index = "40"> - request to start staging - <doc> - This method requests permission to start staging a message. Staging - means sending the message into a temporary area at the recipient end - and then delivering the message by referring to this temporary area. - Staging is how the protocol handles partial file transfers - if a - message is partially staged and the connection breaks, the next time - the sender starts to stage it, it can restart from where it left off. - </doc> - <response name = "open-ok" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "identifier" type = "shortstr"> - staging identifier - <doc> - This is the staging identifier. This is an arbitrary string chosen - by the sender. For staging to work correctly the sender must use - the same staging identifier when staging the same message a second - time after recovery from a failure. A good choice for the staging - identifier would be the SHA1 hash of the message properties data - (including the original filename, revised time, etc.). - </doc> - </field> - - <field name = "content size" type = "longlong"> - message content size - <doc> - The size of the content in octets. The recipient may use this - information to allocate or check available space in advance, to - avoid "disk full" errors during staging of very large messages. - </doc> - <doc name = "rule"> - The sender MUST accurately fill the content-size field. - Zero-length content is permitted. - </doc> - </field> -</method> - -<method name = "open-ok" synchronous = "1" index = "41"> - confirm staging ready - <doc> - This method confirms that the recipient is ready to accept staged - data. If the message was already partially-staged at a previous - time the recipient will report the number of octets already staged. - </doc> - <response name = "stage" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "staged size" type = "longlong"> - already staged amount - <doc> - The amount of previously-staged content in octets. For a new - message this will be zero. - </doc> - <doc name = "rule"> - The sender MUST start sending data from this octet offset in the - message, counting from zero. - </doc> - <doc name = "rule"> - The recipient MAY decide how long to hold partially-staged content - and MAY implement staging by always discarding partially-staged - content. However if it uses the file content type it MUST support - the staging methods. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "stage" content = "1" index = "50"> - stage message content - <doc> - This method stages the message, sending the message content to the - recipient from the octet offset specified in the Open-Ok method. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "publish" index = "60"> - publish a message - <doc> - This method publishes a staged file message to a specific exchange. - The file message will be routed to queues as defined by the exchange - configuration and distributed to any active consumers when the - transaction, if any, is committed. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - </doc> - </field> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - </doc> - <doc name = "rule"> - The server MUST accept a blank exchange name to mean the default - exchange. - </doc> - <doc name = "rule"> - If the exchange was declared as an internal exchange, the server - MUST respond with a reply code 403 (access refused) and raise a - channel exception. - </doc> - <doc name = "rule"> - The exchange MAY refuse file content in which case it MUST respond - with a reply code 540 (not implemented) and raise a channel - exception. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" type = "bit"> - indicate mandatory routing - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - </doc> - <doc name = "rule" test = "amq_file_00"> - The server SHOULD implement the mandatory flag. - </doc> - </field> - - <field name = "immediate" type = "bit"> - request immediate delivery - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - <doc name = "rule" test = "amq_file_00"> - The server SHOULD implement the immediate flag. - </doc> - </field> - - <field name = "identifier" type = "shortstr"> - staging identifier - <doc> - This is the staging identifier of the message to publish. The - message must have been staged. Note that a client can send the - Publish method asynchronously without waiting for staging to - finish. - </doc> - </field> -</method> - -<method name = "return" content = "1" index = "70"> - return a failed message - <doc> - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "reply code" domain = "reply code" /> - <field name = "reply text" domain = "reply text" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "deliver" index = "80"> - notify the client of a consumer message - <doc> - This method delivers a staged file message to the client, via a - consumer. In the asynchronous message delivery model, the client - starts a consumer using the Consume method, then the server - responds with Deliver methods as and when messages arrive for - that consumer. - </doc> - <doc name = "rule"> - The server SHOULD track the number of times a message has been - delivered to clients and when a message is redelivered a certain - number of times - e.g. 5 times - without being acknowledged, the - server SHOULD consider the message to be unprocessable (possibly - causing client applications to abort), and move the message to a - dead letter queue. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was originally - published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> - - <field name = "identifier" type = "shortstr"> - staging identifier - <doc> - This is the staging identifier of the message to deliver. The - message must have been staged. Note that a server can send the - Deliver method asynchronously without waiting for staging to - finish. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "ack" index = "90"> - acknowledge one or more messages - <doc> - This method acknowledges one or more messages delivered via the - Deliver method. The client can ask to confirm a single message or - a set of messages up to and including a specific message. - </doc> - <chassis name = "server" implement = "MUST" /> - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "multiple" type = "bit"> - acknowledge multiple messages - <doc> - If set to 1, the delivery tag is treated as "up to and including", - so that the client can acknowledge multiple messages with a single - method. If set to zero, the delivery tag refers to a single - message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding mesages. - </doc> - <doc name = "rule"> - The server MUST validate that a non-zero delivery-tag refers to an - delivered message, and raise a channel exception if this is not the - case. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "reject" index = "100"> - reject an incoming message - <doc> - This method allows a client to reject a message. It can be used to - return untreatable messages to their original queue. Note that file - content is staged before delivery, so the client will not use this - method to interrupt delivery of a large message. - </doc> - <doc name = "rule"> - The server SHOULD interpret this method as meaning that the client - is unable to process the message at this time. - </doc> - <doc name = "rule"> - A client MUST NOT use this method as a means of selecting messages - to process. A rejected message MAY be discarded or dead-lettered, - not necessarily passed to another client. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be discarded. If this bit - is 1, the server will attempt to requeue the message. - </doc> - <doc name = "rule"> - The server MUST NOT deliver the message to the same client within - the context of the current channel. The recommended strategy is - to attempt to deliver the message to an alternative consumer, and - if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold - the message on the queue and redeliver it to the same client at - a later stage. - </doc> - </field> -</method> - -</class> - - <class name="stream" handler="channel" index="80"> - <!-- -====================================================== -== STREAMING -====================================================== ---> - work with streaming content - -<doc> - The stream class provides methods that support multimedia streaming. - The stream class uses the following semantics: one message is one - packet of data; delivery is unacknowleged and unreliable; the consumer - can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favour of high - priority messages. -</doc> - -<doc name = "grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN - / S:DELIVER content -</doc> - -<chassis name = "server" implement = "MAY" /> -<chassis name = "client" implement = "MAY" /> - -<doc name = "rule"> - The server SHOULD discard stream messages on a priority basis if - the queue size exceeds some configured limit. -</doc> -<doc name = "rule"> - The server MUST implement at least 2 priority levels for stream - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. -</doc> -<doc name = "rule"> - The server MUST implement automatic acknowledgements on stream - content. That is, as soon as a message is delivered to a client - via a Deliver method, the server must remove it from the queue. -</doc> - - -<!-- These are the properties for a Stream content --> - -<field name = "content type" type = "shortstr"> - MIME content type -</field> -<field name = "content encoding" type = "shortstr"> - MIME content encoding -</field> -<field name = "headers" type = "table"> - Message header field table -</field> -<field name = "priority" type = "octet"> - The message priority, 0 to 9 -</field> -<field name = "timestamp" type = "timestamp"> - The message timestamp -</field> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "qos" synchronous = "1" index = "10"> - specify quality of service - <doc> - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch size" type = "long"> - prefetch window in octets - <doc> - The client can request that messages be sent in advance so that - when the client finishes processing a message, the following - message is already held locally, rather than needing to be sent - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. May be - set to zero, meaning "no specific limit". Note that other - prefetch limits may still apply. - </doc> - </field> - - <field name = "prefetch count" type = "short"> - prefetch window in messages - <doc> - Specifies a prefetch window in terms of whole messages. This - field may be used in combination with the prefetch-size field; - a message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - </doc> - </field> - - <field name = "consume rate" type = "long"> - transfer rate in octets/second - <doc> - Specifies a desired transfer rate in octets per second. This is - usually determined by the application that uses the streaming - data. A value of zero means "no limit", i.e. as rapidly as - possible. - </doc> - <doc name = "rule"> - The server MAY ignore the prefetch values and consume rates, - depending on the type of stream and the ability of the server - to queue and/or reply it. The server MAY drop low-priority - messages in favour of high-priority messages. - </doc> - </field> - - <field name = "global" type = "bit"> - apply to entire connection - <doc> - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - </doc> - </field> -</method> - -<method name = "qos-ok" synchronous = "1" index = "11"> - confirm the requested qos - <doc> - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - </doc> - <chassis name = "client" implement = "MUST" /> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "consume" synchronous = "1" index = "20"> - start a queue consumer - <doc> - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - </doc> - <doc name = "rule"> - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - </doc> - <doc name = "rule"> - Streaming applications SHOULD use different channels to select - different streaming resolutions. AMQP makes no provision for - filtering and/or transforming streams except on the basis of - priority-based selective delivery of individual messages. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - </doc> - <doc name = "rule" test = "todo"> - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - </doc> - </field> - - <field name = "no local" domain = "no local" /> - - <field name = "exclusive" type = "bit"> - request exclusive access - <doc> - Request exclusive consumer access, meaning only this consumer can - access the queue. - </doc> - <doc name = "rule" test = "amq_file_00"> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 405 (resource locked). - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - - -<method name = "consume-ok" synchronous = "1" index = "21"> - confirm a new consumer - <doc> - This method provides the client with a consumer tag which it may - use in methods that work with the consumer. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Holds the consumer tag specified by the client or provided by - the server. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "cancel" synchronous = "1" index = "30"> - end a queue consumer - <doc> - This method cancels a consumer. Since message delivery is - asynchronous the client may continue to receive messages for - a short while after canceling a consumer. It may process or - discard these as appropriate. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "cancel-ok" synchronous = "1" index = "31"> - confirm a cancelled consumer - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "publish" content = "1" index = "40"> - publish a message - <doc> - This method publishes a message to a specific exchange. The message - will be routed to queues as defined by the exchange configuration - and distributed to any active consumers as appropriate. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - </doc> - </field> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - </doc> - <doc name = "rule"> - The server MUST accept a blank exchange name to mean the default - exchange. - </doc> - <doc name = "rule"> - If the exchange was declared as an internal exchange, the server - MUST respond with a reply code 403 (access refused) and raise a - channel exception. - </doc> - <doc name = "rule"> - The exchange MAY refuse stream content in which case it MUST - respond with a reply code 540 (not implemented) and raise a - channel exception. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" type = "bit"> - indicate mandatory routing - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - </doc> - <doc name = "rule" test = "amq_stream_00"> - The server SHOULD implement the mandatory flag. - </doc> - </field> - - <field name = "immediate" type = "bit"> - request immediate delivery - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - <doc name = "rule" test = "amq_stream_00"> - The server SHOULD implement the immediate flag. - </doc> - </field> -</method> - -<method name = "return" content = "1" index = "50"> - return a failed message - <doc> - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "reply code" domain = "reply code" /> - <field name = "reply text" domain = "reply text" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "deliver" content = "1" index = "60"> - notify the client of a consumer message - <doc> - This method delivers a message to the client, via a consumer. In - the asynchronous message delivery model, the client starts a - consumer using the Consume method, then the server responds with - Deliver methods as and when messages arrive for that consumer. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was originally - published to. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue that the message came from. Note - that a single channel can start many consumers on different - queues. - </doc> - <assert check = "notnull" /> - </field> -</method> - </class> - - <class name="tx" handler="channel" index="90"> - <!-- -====================================================== -== TRANSACTIONS -====================================================== ---> - work with standard transactions - -<doc> - Standard transactions provide so-called "1.5 phase commit". We can - ensure that work is never lost, but there is a chance of confirmations - being lost, so that messages may be resent. Applications that use - standard transactions must be able to detect and ignore duplicate - messages. -</doc> - <rule implement="SHOULD"> - An client using standard transactions SHOULD be able to track all - messages received within a reasonable period, and thus detect and - reject duplicates of the same message. It SHOULD NOT pass these to - the application layer. -</rule> - <doc name="grammar"> - tx = C:SELECT S:SELECT-OK - / C:COMMIT S:COMMIT-OK - / C:ROLLBACK S:ROLLBACK-OK -</doc> - <chassis name="server" implement="SHOULD"/> - <chassis name="client" implement="MAY"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="select" synchronous="1" index="10"> -select standard transaction mode - <doc> - This method sets the channel to use standard transactions. The - client must use this method at least once on a channel before - using the Commit or Rollback methods. - </doc> - <chassis name="server" implement="MUST"/> - <response name="select-ok"/> - </method> - <method name="select-ok" synchronous="1" index="11"> -confirm transaction mode - <doc> - This method confirms to the client that the channel was successfully - set to use standard transactions. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="commit" synchronous="1" index="20"> -commit the current transaction - <doc> - This method commits all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a commit. - </doc> - <chassis name="server" implement="MUST"/> - <response name="commit-ok"/> - </method> - <method name="commit-ok" synchronous="1" index="21"> -confirm a successful commit - <doc> - This method confirms to the client that the commit succeeded. - Note that if a commit fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="rollback" synchronous="1" index="30"> -abandon the current transaction - <doc> - This method abandons all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a rollback. - </doc> - <chassis name="server" implement="MUST"/> - <response name="rollback-ok"/> - </method> - <method name="rollback-ok" synchronous="1" index="31"> -confirm a successful rollback - <doc> - This method confirms to the client that the rollback succeeded. - Note that if an rollback fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - </class> - <class name="dtx" handler="channel" index="100"> - <!-- -====================================================== -== DISTRIBUTED TRANSACTIONS -====================================================== ---> - work with distributed transactions - -<doc> - Distributed transactions provide so-called "2-phase commit". The - AMQP distributed transaction model supports the X-Open XA - architecture and other distributed transaction implementations. - The Dtx class assumes that the server has a private communications - channel (not AMQP) to a distributed transaction coordinator. -</doc> - <doc name="grammar"> - dtx = C:SELECT S:SELECT-OK - C:START S:START-OK -</doc> - <chassis name="server" implement="MAY"/> - <chassis name="client" implement="MAY"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="select" synchronous="1" index="10"> -select standard transaction mode - <doc> - This method sets the channel to use distributed transactions. The - client must use this method at least once on a channel before - using the Start method. - </doc> - <chassis name="server" implement="MUST"/> - <response name="select-ok"/> - </method> - <method name="select-ok" synchronous="1" index="11"> -confirm transaction mode - <doc> - This method confirms to the client that the channel was successfully - set to use distributed transactions. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="start" synchronous="1" index="20"> - start a new distributed transaction - <doc> - This method starts a new distributed transaction. This must be - the first method on a new channel that uses the distributed - transaction mode, before any methods that publish or consume - messages. - </doc> - <chassis name="server" implement="MAY"/> - <response name="start-ok"/> - <field name="dtx identifier" type="shortstr"> - transaction identifier - <doc> - The distributed transaction key. This identifies the transaction - so that the AMQP server can coordinate with the distributed - transaction coordinator. - </doc> - <assert check="notnull"/> - </field> - </method> - <method name="start-ok" synchronous="1" index="21"> - confirm the start of a new distributed transaction - <doc> - This method confirms to the client that the transaction started. - Note that if a start fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - </class> - <class name="tunnel" handler="tunnel" index="110"> - <!-- -====================================================== -== TUNNEL -====================================================== ---> - methods for protocol tunneling. - -<doc> - The tunnel methods are used to send blocks of binary data - which - can be serialised AMQP methods or other protocol frames - between - AMQP peers. -</doc> - <doc name="grammar"> - tunnel = C:REQUEST - / S:REQUEST -</doc> - <chassis name="server" implement="MAY"/> - <chassis name="client" implement="MAY"/> - <field name="headers" type="table"> - Message header field table -</field> - <field name="proxy name" type="shortstr"> - The identity of the tunnelling proxy -</field> - <field name="data name" type="shortstr"> - The name or type of the message being tunnelled -</field> - <field name="durable" type="octet"> - The message durability indicator -</field> - <field name="broadcast" type="octet"> - The message broadcast mode -</field> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="request" content="1" index="10"> - sends a tunnelled method - <doc> - This method tunnels a block of binary data, which can be an - encoded AMQP method or other data. The binary data is sent - as the content for the Tunnel.Request method. - </doc> - <chassis name="server" implement="MUST"/> - <field name="meta data" type="table"> - meta data for the tunnelled block - <doc> - This field table holds arbitrary meta-data that the sender needs - to pass to the recipient. - </doc> - </field> - </method> - </class> - <class name="test" handler="channel" index="120"> - <!-- -====================================================== -== TEST - CHECK FUNCTIONAL CAPABILITIES OF AN IMPLEMENTATION -====================================================== ---> - test functional primitives of the implementation - -<doc> - The test class provides methods for a peer to test the basic - operational correctness of another peer. The test methods are - intended to ensure that all peers respect at least the basic - elements of the protocol, such as frame and content organisation - and field types. We assume that a specially-designed peer, a - "monitor client" would perform such tests. -</doc> - <doc name="grammar"> - test = C:INTEGER S:INTEGER-OK - / S:INTEGER C:INTEGER-OK - / C:STRING S:STRING-OK - / S:STRING C:STRING-OK - / C:TABLE S:TABLE-OK - / S:TABLE C:TABLE-OK - / C:CONTENT S:CONTENT-OK - / S:CONTENT C:CONTENT-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="SHOULD"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="integer" synchronous="1" index="10"> - test integer handling - <doc> - This method tests the peer's capability to correctly marshal integer - data. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="integer-ok"/> - <field name="integer 1" type="octet"> - octet test value - <doc> - An octet integer test value. - </doc> - </field> - <field name="integer 2" type="short"> - short test value - <doc> - A short integer test value. - </doc> - </field> - <field name="integer 3" type="long"> - long test value - <doc> - A long integer test value. - </doc> - </field> - <field name="integer 4" type="longlong"> - long-long test value - <doc> - A long long integer test value. - </doc> - </field> - <field name="operation" type="octet"> - operation to test - <doc> - The client must execute this operation on the provided integer - test fields and return the result. - </doc> - <assert check="enum"> - <value name="add">return sum of test values</value> - <value name="min">return lowest of test values</value> - <value name="max">return highest of test values</value> - </assert> - </field> - </method> - <method name="integer-ok" synchronous="1" index="11"> - report integer test result - <doc> - This method reports the result of an Integer method. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="result" type="longlong"> - result value - <doc> - The result of the tested operation. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="string" synchronous="1" index="20"> - test string handling - <doc> - This method tests the peer's capability to correctly marshal string - data. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="string-ok"/> - <field name="string 1" type="shortstr"> - short string test value - <doc> - An short string test value. - </doc> - </field> - <field name="string 2" type="longstr"> - long string test value - <doc> - A long string test value. - </doc> - </field> - <field name="operation" type="octet"> - operation to test - <doc> - The client must execute this operation on the provided string - test fields and return the result. - </doc> - <assert check="enum"> - <value name="add">return concatentation of test strings</value> - <value name="min">return shortest of test strings</value> - <value name="max">return longest of test strings</value> - </assert> - </field> - </method> - <method name="string-ok" synchronous="1" index="21"> - report string test result - <doc> - This method reports the result of a String method. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="result" type="longstr"> - result value - <doc> - The result of the tested operation. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="table" synchronous="1" index="30"> - test field table handling - <doc> - This method tests the peer's capability to correctly marshal field - table data. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="table-ok"/> - <field name="table" type="table"> - field table of test values - <doc> - A field table of test values. - </doc> - </field> - <field name="integer op" type="octet"> - operation to test on integers - <doc> - The client must execute this operation on the provided field - table integer values and return the result. - </doc> - <assert check="enum"> - <value name="add">return sum of numeric field values</value> - <value name="min">return min of numeric field values</value> - <value name="max">return max of numeric field values</value> - </assert> - </field> - <field name="string op" type="octet"> - operation to test on strings - <doc> - The client must execute this operation on the provided field - table string values and return the result. - </doc> - <assert check="enum"> - <value name="add">return concatenation of string field values</value> - <value name="min">return shortest of string field values</value> - <value name="max">return longest of string field values</value> - </assert> - </field> - </method> - <method name="table-ok" synchronous="1" index="31"> - report table test result - <doc> - This method reports the result of a Table method. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="integer result" type="longlong"> - integer result value - <doc> - The result of the tested integer operation. - </doc> - </field> - <field name="string result" type="longstr"> - string result value - <doc> - The result of the tested string operation. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="content" synchronous="1" content="1" index="40"> - test content handling - <doc> - This method tests the peer's capability to correctly marshal content. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="content-ok"/> - </method> - <method name="content-ok" synchronous="1" content="1" index="41"> - report content test result - <doc> - This method reports the result of a Content method. It contains the - content checksum and echoes the original content as provided. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="content checksum" type="long"> - content hash - <doc> - The 32-bit checksum of the content, calculated by adding the - content into a 32-bit accumulator. - </doc> - </field> - </method> - </class> -</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-9-1-stripped.xml b/qpid/python/qpid/specs/amqp-0-9-1-stripped.xml new file mode 100644 index 0000000000..ec55c8dd7a --- /dev/null +++ b/qpid/python/qpid/specs/amqp-0-9-1-stripped.xml @@ -0,0 +1,477 @@ +<?xml version="1.0"?> +<!-- +Copyright (c) 2009 AMQP Working Group. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> +<amqp major="0" minor="91" port="5672"> + <constant name="frame-method" value="1"/> + <constant name="frame-header" value="2"/> + <constant name="frame-body" value="3"/> + <constant name="frame-heartbeat" value="8"/> + <constant name="frame-min-size" value="4096"/> + <constant name="frame-end" value="206"/> + <constant name="reply-success" value="200"/> + <constant name="content-too-large" value="311" class="soft-error"/> + <constant name="no-consumers" value="313" class="soft-error"/> + <constant name="connection-forced" value="320" class="hard-error"/> + <constant name="invalid-path" value="402" class="hard-error"/> + <constant name="access-refused" value="403" class="soft-error"/> + <constant name="not-found" value="404" class="soft-error"/> + <constant name="resource-locked" value="405" class="soft-error"/> + <constant name="precondition-failed" value="406" class="soft-error"/> + <constant name="frame-error" value="501" class="hard-error"/> + <constant name="syntax-error" value="502" class="hard-error"/> + <constant name="command-invalid" value="503" class="hard-error"/> + <constant name="channel-error" value="504" class="hard-error"/> + <constant name="unexpected-frame" value="505" class="hard-error"/> + <constant name="resource-error" value="506" class="hard-error"/> + <constant name="not-allowed" value="530" class="hard-error"/> + <constant name="not-implemented" value="540" class="hard-error"/> + <constant name="internal-error" value="541" class="hard-error"/> + <domain name="class-id" type="short"/> + <domain name="consumer-tag" type="shortstr"/> + <domain name="delivery-tag" type="longlong"/> + <domain name="exchange-name" type="shortstr"> + <assert check="length" value="127"/> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </domain> + <domain name="method-id" type="short"/> + <domain name="no-ack" type="bit"/> + <domain name="no-local" type="bit"/> + <domain name="nowait" type="bit"/> + <!-- Qpid: restore these so that the generation sees the methods aas the same --> + <domain name="known-hosts" type="shortstr"/> + <domain name="access-ticket" type="short"/> + <!-- end Qpid specific --> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer-properties" type="table"/> + <domain name="queue-name" type="shortstr"> + <assert check="length" value="127"/> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="message-count" type="long"/> + <domain name="reply-code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply-text" type="shortstr"> + <assert check="notnull"/> + </domain> + <domain name="bit" type="bit"/> + <domain name="octet" type="octet"/> + <domain name="short" type="short"/> + <domain name="long" type="long"/> + <domain name="longlong" type="longlong"/> + <domain name="shortstr" type="shortstr"/> + <domain name="longstr" type="longstr"/> + <domain name="timestamp" type="timestamp"/> + <domain name="table" type="table"/> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version-major" domain="octet"/> + <field name="version-minor" domain="octet"/> + <field name="server-properties" domain="peer-properties"/> + <field name="mechanisms" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locales" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client-properties" domain="peer-properties"/> + <field name="mechanism" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" domain="longstr"/> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" domain="short"/> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel-max" domain="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel-max"/> + </field> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="virtual-host" domain="path"/> + <field name="capabilities" type="shortstr" reserved="1"/> + <field name="insist" type="bit" reserved="1"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known-hosts" domain="known-hosts" reserved="1"/> + </method> + <method name="close" synchronous="1" index="50"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out-of-band" type="shortstr" reserved="1"/> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="channel-id" type="longstr" reserved="1"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" domain="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" domain="bit"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="exchange" domain="exchange-name"> + <assert check="notnull"/> + </field> + <field name="type" domain="shortstr"/> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="auto-delete" type="bit" reserved="1"/> + <field name="internal" type="bit" reserved="1"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="exchange" domain="exchange-name"> + <assert check="notnull"/> + </field> + <field name="if-unused" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <!-- Qpid : Added Exchange.bound and Exchange.bound-ok --> + <method name="bound" synchronous="1" index="22"> + <chassis name="server" implement="SHOULD"/> + <response name="bound-ok"/> + <field name="exchange" domain="exchange-name"/> + <field name = "routing-key" type = "shortstr"/> + <field name = "queue" domain = "queue name"/> + </method> + <method name="bound-ok" synchronous="1" index="23"> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <chassis name="client" implement="SHOULD"/> + </method> + <!-- End Qpid addition --> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="exclusive" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + <field name="message-count" domain="long"/> + <field name="consumer-count" domain="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="unbind" synchronous="1" index="50"> + <chassis name="server" implement="MUST"/> + <response name="unbind-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="arguments" domain="table"/> + </method> + <method name="unbind-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="nowait" domain="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="if-unused" domain="bit"/> + <field name="if-empty" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="delivery-mode" domain="octet"/> + <field name="priority" domain="octet"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="expiration" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="type" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="reserved" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket" reserved="1"/> + <field name="queue" domain="queue-name"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-count" domain="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster-id" type="shortstr" reserved="1"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + <method name="recover" index="100" deprecated="1"> + <chassis name="server" implement="MAY"/> + <field name="requeue" domain="bit"/> + </method> + <method name="recover-sync" index="110"> + <chassis name="server" implement="MUST"/> + <field name="requeue" domain="bit"/> + </method> + <method name="recover-sync-ok" synchronous="1" index="111"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> +</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-9-qpid-stripped.xml b/qpid/python/qpid/specs/amqp-0-9-qpid-stripped.xml new file mode 100644 index 0000000000..e0075870de --- /dev/null +++ b/qpid/python/qpid/specs/amqp-0-9-qpid-stripped.xml @@ -0,0 +1,876 @@ +<?xml version="1.0"?> + +<!-- +(c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy +Technologies Inc., iMatix Corporation, IONA\ufffd Technologies, Red +Hat, Inc., TWIST Process Innovations, and 29West Inc. 2006. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="0" minor="9" port="5672"> + <constant name="frame-method" value="1"/> + <constant name="frame-header" value="2"/> + <constant name="frame-body" value="3"/> + <constant name="frame-oob-method" value="4"/> + <constant name="frame-oob-header" value="5"/> + <constant name="frame-oob-body" value="6"/> + <constant name="frame-trace" value="7"/> + <constant name="frame-heartbeat" value="8"/> + <constant name="frame-min-size" value="4096"/> + <constant name="frame-end" value="206"/> + <constant name="reply-success" value="200"/> + <constant name="not-delivered" value="310" class="soft-error"/> + <constant name="content-too-large" value="311" class="soft-error"/> + <constant name="no-route" value="312" class="soft-error"/> + <constant name="no-consumers" value="313" class="soft-error"/> + <constant name="connection-forced" value="320" class="hard-error"/> + <constant name="invalid-path" value="402" class="hard-error"/> + <constant name="access-refused" value="403" class="soft-error"/> + <constant name="not-found" value="404" class="soft-error"/> + <constant name="resource-locked" value="405" class="soft-error"/> + <constant name="precondition-failed" value="406" class="soft-error"/> + <constant name="frame-error" value="501" class="hard-error"/> + <constant name="syntax-error" value="502" class="hard-error"/> + <constant name="command-invalid" value="503" class="hard-error"/> + <constant name="channel-error" value="504" class="hard-error"/> + <constant name="resource-error" value="506" class="hard-error"/> + <constant name="not-allowed" value="530" class="hard-error"/> + <constant name="not-implemented" value="540" class="hard-error"/> + <constant name="internal-error" value="541" class="hard-error"/> + <domain name="access-ticket" type="short"> + <assert check="ne" value="0"/> + </domain> + <domain name="class-id" type="short"/> + <domain name="consumer-tag" type="shortstr"/> + <domain name="delivery-tag" type="longlong"/> + <domain name="exchange-name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="known-hosts" type="shortstr"/> + <domain name="method-id" type="short"/> + <domain name="no-ack" type="bit"/> + <domain name="no-local" type="bit"/> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="syntax" rule="path"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer-properties" type="table"/> + <domain name="queue-name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="reply-code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply-text" type="shortstr"> + <assert check="notnull"/> + </domain> + <domain name="channel-id" type="longstr"/> + <domain name="duration" type="longlong"/> + <domain name="offset" type="longlong"/> + <domain name="reference" type="longstr"/> + <domain name="destination" type="shortstr"/> + <domain name="reject-code" type="short"/> + <domain name="reject-text" type="shortstr"/> + <domain name="security-token" type="longstr"/> + <domain name="bit" type="bit"/> + <domain name="octet" type="octet"/> + <domain name="short" type="short"/> + <domain name="long" type="long"/> + <domain name="longlong" type="longlong"/> + <domain name="shortstr" type="shortstr"/> + <domain name="longstr" type="longstr"/> + <domain name="timestamp" type="timestamp"/> + <domain name="table" type="table"/> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version-major" domain="octet"/> + <field name="version-minor" domain="octet"/> + <field name="server-properties" domain="peer-properties"/> + <field name="mechanisms" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locales" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client-properties" domain="peer-properties"/> + <field name="mechanism" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" domain="longstr"/> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" domain="short"/> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel-max" domain="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel-max"/> + </field> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" domain="path"> + <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> + </field> + <field name="capabilities" domain="shortstr"/> + <field name="insist" domain="bit"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known-hosts" domain="known-hosts"/> + </method> + <method name="redirect" synchronous="1" index="42"> + <chassis name="client" implement="MUST"/> + <field name="host" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="known-hosts" domain="known-hosts"/> + </method> + <method name="close" synchronous="1" index="50"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out-of-band" domain="shortstr"> + <assert check="null"/> + </field> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="channel-id" domain="channel-id"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" domain="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" domain="bit"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + <method name="resume" index="50"> + <response name="ok"/> + <chassis name="server" implement="MAY"/> + <field name="channel-id" domain="channel-id"/> + </method> + <method name="ping" index="60"> + <response name="ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="pong" index="70"> + <response name="ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="ok" index="80"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="access" handler="connection" index="30"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="request" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="request-ok"/> + <field name="realm" domain="shortstr"/> + <field name="exclusive" domain="bit"/> + <field name="passive" domain="bit"/> + <field name="active" domain="bit"/> + <field name="write" domain="bit"/> + <field name="read" domain="bit"/> + </method> + <method name="request-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="type" domain="shortstr"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="internal" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"> + <assert check="notnull"/> + </field> + <field name="if-unused" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <!-- Qpid specific addition --> + <method name="bound" synchronous="1" index="22"> + <chassis name="server" implement="SHOULD"/> + <response name="bound-ok"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" type="shortstr"/> + <field name="queue" domain="queue name"/> + </method> + <method name="bound-ok" synchronous="1" index="23"> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <chassis name="client" implement="SHOULD"/> + </method> + <!-- End Qpid specific addition --> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </field> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="exclusive" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="nowait" domain="bit"/> + <!-- Qpid diff - this field is known as filter in the original 0-9, + however since the name does not go on the wire, there is no + interop implication --> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + <field name="message-count" domain="long"/> + <field name="consumer-count" domain="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="unbind" synchronous="1" index="50"> + <chassis name="server" implement="MUST"/> + <response name="unbind-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="arguments" domain="table"/> + </method> + <method name="unbind-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="nowait" domain="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="if-unused" domain="bit"/> + <field name="if-empty" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="delivery-mode" domain="octet"/> + <field name="priority" domain="octet"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="expiration" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="type" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="cluster-id" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-count" domain="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster-id" domain="shortstr"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + <method name="recover" index="100"> + <chassis name="server" implement="MUST"/> + <field name="requeue" domain="bit"/> + </method> + <!-- Qpid specific addition --> + <method name="recover-sync" index="102"> + <chassis name="server" implement="MUST"/> + <field name="requeue" type="bit"/> + <response name="recover-sync-ok"/> + </method> + <method name="recover-sync-ok" synchronous="1" index="101"> + <chassis name="client" implement="MUST"/> + </method> + <!-- End Qpid specific addition --> + </class> + <class name="file" handler="channel" index="70"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="priority" domain="octet"/> + <field name="reply-to" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="filename" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="cluster-id" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <response name="cancel-ok"/> + <chassis name="server" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="open" synchronous="1" index="40"> + <response name="open-ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="identifier" domain="shortstr"/> + <field name="content-size" domain="longlong"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <response name="stage"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="staged-size" domain="longlong"/> + </method> + <method name="stage" content="1" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="publish" index="60"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="return" content="1" index="70"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" index="80"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="ack" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="100"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + </class> + <class name="stream" handler="channel" index="80"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="priority" domain="octet"/> + <field name="timestamp" domain="timestamp"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="consume-rate" domain="long"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="exchange" domain="exchange-name"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="dtx" handler="channel" index="100"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="start" synchronous="1" index="20"> + <chassis name="server" implement="MAY"/> + <response name="start-ok"/> + <field name="dtx-identifier" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tunnel" handler="tunnel" index="110"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="headers" domain="table"/> + <field name="proxy-name" domain="shortstr"/> + <field name="data-name" domain="shortstr"/> + <field name="durable" domain="octet"/> + <field name="broadcast" domain="octet"/> + <method name="request" content="1" index="10"> + <chassis name="server" implement="MUST"/> + <field name="meta-data" domain="table"/> + </method> + </class> + <class name="message" handler="channel" index="120"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="transfer" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <response name="reject"/> + <field name="ticket" domain="access-ticket"/> + <field name="destination" domain="destination"/> + <field name="redelivered" domain="redelivered"/> + <field name="immediate" domain="bit"/> + <field name="ttl" domain="duration"/> + <field name="priority" domain="octet"/> + <field name="timestamp" domain="timestamp"/> + <field name="delivery-mode" domain="octet"/> + <field name="expiration" domain="timestamp"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="transaction-id" domain="shortstr"/> + <field name="security-token" domain="security-token"/> + <field name="application-headers" domain="table"/> + <field name="body" domain="content"/> + </method> + <method name="consume" index="20"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="destination" domain="destination"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="cancel" index="30"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="destination" domain="destination"/> + </method> + <method name="get" index="40"> + <response name="ok"/> + <response name="empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="destination" domain="destination"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="recover" index="50"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="requeue" domain="bit"/> + </method> + <method name="open" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + </method> + <method name="close" index="70"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + </method> + <method name="append" index="80"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + <field name="bytes" domain="longstr"/> + </method> + <method name="checkpoint" index="90"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="resume" index="100"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="offset"/> + <field name="reference" domain="reference"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="qos" index="110"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="ok" index="500"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="empty" index="510"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="reject" index="520"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="code" domain="reject-code"/> + <field name="text" domain="reject-text"/> + </method> + <method name="offset" index="530"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="value" domain="offset"/> + </method> + </class> +</amqp> diff --git a/qpid/python/qpid/specs/amqp-0-9.xml b/qpid/python/qpid/specs/amqp-0-9.xml deleted file mode 100644 index 73cace7015..0000000000 --- a/qpid/python/qpid/specs/amqp-0-9.xml +++ /dev/null @@ -1,5248 +0,0 @@ -<?xml version = "1.0"?> - -<!-- - EDITORS: (PH) Pieter Hintjens <ph@imatix.com> - (KvdR) Kim van der Riet <kim.vdriet@redhat.com> - - These editors have been assigned by the AMQP working group. - Please do not edit/commit this file without consulting with - one of the above editors. - ======================================================== - - TODOs - - see TODO comments in the text ---> - -<!-- - Copyright Notice - ================ - (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., - iMatix Corporation, IONA\ufffd Technologies, Red Hat, Inc., - TWIST Process Innovations, and 29West Inc. 2006. All rights reserved. - - License - ======= - JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix - Corporation, IONA Technologies, Red Hat, Inc., TWIST Process Innovations, and - 29West Inc. (collectively, the "Authors") each hereby grants to you a worldwide, - perpetual, royalty-free, nontransferable, nonexclusive license to - (i) copy, display, distribute and implement the Advanced Messaging Queue Protocol - ("AMQP") Specification and (ii) the Licensed Claims that are held by - the Authors, all for the purpose of implementing the Advanced Messaging - Queue Protocol Specification. Your license and any rights under this - Agreement will terminate immediately without notice from - any Author if you bring any claim, suit, demand, or action related to - the Advanced Messaging Queue Protocol Specification against any Author. - Upon termination, you shall destroy all copies of the Advanced Messaging - Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or - patent application, throughout the world, excluding design patents and - design registrations, owned or controlled, or that can be sublicensed - without fee and in compliance with the requirements of this - Agreement, by an Author or its affiliates now or at any - future time and which would necessarily be infringed by implementation - of the Advanced Messaging Queue Protocol Specification. A claim is - necessarily infringed hereunder only when it is not possible to avoid - infringing it because there is no plausible non-infringing alternative - for implementing the required portions of the Advanced Messaging Queue - Protocol Specification. Notwithstanding the foregoing, Licensed Claims - shall not include any claims other than as set forth above even if - contained in the same patent as Licensed Claims; or that read solely - on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging - Queue Protocol Specification, or that, if licensed, would require a - payment of royalties by the licensor to unaffiliated third parties. - Moreover, Licensed Claims shall not include (i) any enabling technologies - that may be necessary to make or use any Licensed Product but are not - themselves expressly set forth in the Advanced Messaging Queue Protocol - Specification (e.g., semiconductor manufacturing technology, compiler - technology, object oriented technology, networking technology, operating - system technology, and the like); or (ii) the implementation of other - published standards developed elsewhere and merely referred to in the - body of the Advanced Messaging Queue Protocol Specification, or - (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced - Messaging Queue Protocol Specification. For purposes of this definition, - the Advanced Messaging Queue Protocol Specification shall be deemed to - include both architectural and interconnection requirements essential - for interoperability and may also include supporting source code artifacts - where such architectural, interconnection requirements and source code - artifacts are expressly identified as being required or documentation to - achieve compliance with the Advanced Messaging Queue Protocol Specification. - - As used hereunder, "Licensed Products" means only those specific portions - of products (hardware, software or combinations thereof) that implement - and are compliant with all relevant portions of the Advanced Messaging - Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any - use you may make of the Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," - AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE - CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE - SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY - PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, - INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY - USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED MESSAGING QUEUE - PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, - including advertising or publicity pertaining to the Advanced Messaging - Queue Protocol Specification or its contents without specific, written - prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you - shall destroy all copies of the Advanced Messaging Queue Protocol - Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the - Octagon Symbol are trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA - Technologies PLC and/or its subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered - trademarks of Red Hat, Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of - Sun Microsystems, Inc. in the United States, other countries, or both. - - Other company, product, or service names may be trademarks or service - marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp ---> - -<!-- - <!DOCTYPE amqp SYSTEM "amqp.dtd"> ---> - -<!-- 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 spaces to seperate words in names, so that we can print names in - their natural form depending on the context - underlines for source code, - hyphens for written text, etc. - - 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. - - --> - -<amqp major = "0" minor = "9" port = "5672" comment = "AMQ Protocol version 0-9"> - <!-- - ====================================================== - == CONSTANTS - ====================================================== - --> - <!-- Frame types --> - <constant name = "frame-method" value = "1" /> - <constant name = "frame-header" value = "2" /> - <constant name = "frame-body" value = "3" /> - <constant name = "frame-oob-method" value = "4" /> - <constant name = "frame-oob-header" value = "5" /> - <constant name = "frame-oob-body" value = "6" /> - <constant name = "frame-trace" value = "7" /> - <constant name = "frame-heartbeat" value = "8" /> - - <!-- Protocol constants --> - <constant name = "frame-min-size" value = "4096" /> - <constant name = "frame-end" value = "206" /> - - <!-- Reply codes --> - <constant name = "reply-success" value = "200"> - <doc> - Indicates that the method completed successfully. This reply code is - reserved for future use - the current protocol design does not use positive - confirmation and reply codes are sent only in case of an error. - </doc> - </constant> - - <constant name = "not-delivered" value = "310" class = "soft-error"> - <doc> - The client asked for a specific message that is no longer available. - The message was delivered to another client, or was purged from the queue - for some other reason. - </doc> - </constant> - - <constant name = "content-too-large" value = "311" class = "soft-error"> - <doc> - The client attempted to transfer content larger than the server could accept - at the present time. The client may retry at a later time. - </doc> - </constant> - - <constant name = "no-route" value = "312" class = "soft-error"> - <doc> - When the exchange cannot route the result of a .Publish, most likely due - to an invalid routing key. Only when the mandatory flag is set. - </doc> - </constant> - - <constant name = "no-consumers" value = "313" class = "soft-error"> - <doc> - When the exchange cannot deliver to a consumer when the immediate flag is - set. As a result of pending data on the queue or the absence of any - consumers of the queue. - </doc> - </constant> - - <constant name = "connection-forced" value = "320" class = "hard-error"> - <doc> - An operator intervened to close the connection for some reason. The client - may retry at some later date. - </doc> - </constant> - - <constant name = "invalid-path" value = "402" class = "hard-error"> - <doc> - The client tried to work with an unknown virtual host. - </doc> - </constant> - - <constant name = "access-refused" value = "403" class = "soft-error"> - <doc> - The client attempted to work with a server entity to which it has no - access due to security settings. - </doc> - </constant> - - <constant name = "not-found" value = "404" class = "soft-error"> - <doc>The client attempted to work with a server entity that does not exist.</doc> - </constant> - - <constant name = "resource-locked" value = "405" class = "soft-error"> - <doc> - The client attempted to work with a server entity to which it has no - access because another client is working with it. - </doc> - </constant> - - <constant name = "precondition-failed" value = "406" class = "soft-error"> - <doc> - The client requested a method that was not allowed because some precondition - failed. - </doc> - </constant> - - <constant name = "frame-error" value = "501" class = "hard-error"> - <doc> - The client sent a malformed frame that the server could not decode. This - strongly implies a programming error in the client. - </doc> - </constant> - - <constant name = "syntax-error" value = "502" class = "hard-error"> - <doc> - The client sent a frame that contained illegal values for one or more - fields. This strongly implies a programming error in the client. - </doc> - </constant> - - <constant name = "command-invalid" value = "503" class = "hard-error"> - <doc> - The client sent an invalid sequence of frames, attempting to perform an - operation that was considered invalid by the server. This usually implies - a programming error in the client. - </doc> - </constant> - - <constant name = "channel-error" value = "504" class = "hard-error"> - <doc> - The client attempted to work with a channel that had not been correctly - opened. This most likely indicates a fault in the client layer. - </doc> - </constant> - - <constant name = "resource-error" value = "506" class = "hard-error"> - <doc> - The server could not complete the method because it lacked sufficient - resources. This may be due to the client creating too many of some type - of entity. - </doc> - </constant> - - <constant name = "not-allowed" value = "530" class = "hard-error"> - <doc> - The client tried to work with some entity in a manner that is prohibited - by the server, due to security settings or by some other criteria. - </doc> - </constant> - - <constant name = "not-implemented" value = "540" class = "hard-error"> - <doc> - The client tried to use functionality that is not implemented in the - server. - </doc> - </constant> - - <constant name = "internal-error" value = "541" class = "hard-error"> - <doc> - The server could not complete the method because of an internal error. - The server may require intervention by an operator in order to resume - normal operations. - </doc> - </constant> - - <!-- - ====================================================== - == DOMAIN TYPES - ====================================================== - --> - - <domain name = "access-ticket" type = "short" label = "access ticket granted by server"> - <doc> - An access ticket granted by the server for a certain set of access rights - within a specific realm. Access tickets are valid within the channel where - they were created, and expire when the channel closes. - </doc> - <assert check = "ne" value = "0" /> - </domain> - - <domain name = "class-id" type = "short" /> - - <domain name = "consumer-tag" type = "shortstr" label = "consumer tag"> - <doc> - Identifier for the consumer, valid within the current connection. - </doc> - </domain> - - <domain name = "delivery-tag" type = "longlong" label = "server-assigned delivery tag"> - <doc> - The server-assigned and channel-specific delivery tag - </doc> - <rule name = "channel-local"> - <doc> - The delivery tag is valid only within the channel from which the message was - received. I.e. a client MUST NOT receive a message on one channel and then - acknowledge it on another. - </doc> - </rule> - <rule name = "non-zero"> - <doc> - The server MUST NOT use a zero value for delivery tags. Zero is reserved - for client use, meaning "all messages so far received". - </doc> - </rule> - </domain> - - <domain name = "exchange-name" type = "shortstr" label = "exchange name"> - <doc> - The exchange name is a client-selected string that identifies the exchange for publish - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - </doc> - <assert check = "length" value = "127" /> - </domain> - - <domain name = "known-hosts" type = "shortstr" label = "list of known hosts"> - <doc> - Specifies the list of equivalent or alternative hosts that the server knows about, - which will normally include the current server itself. Clients can cache this - information and use it when reconnecting to a server after a failure. This field - may be empty. - </doc> - </domain> - - <domain name = "method-id" type = "short" /> - - <domain name = "no-ack" type = "bit" label = "no acknowledgement needed"> - <doc> - If this field is set the server does not expect acknowledgements for - messages. That is, when a message is delivered to the client the server - automatically and silently acknowledges it on behalf of the client. This - functionality increases performance but at the cost of reliability. - Messages can get lost if a client dies before it can deliver them to the - application. - </doc> - </domain> - - <domain name = "no-local" type = "bit" label = "do not deliver own messages"> - <doc> - If the no-local field is set the server will not send messages to the connection that - published them. - </doc> - </domain> - - <domain name = "path" type = "shortstr"> - <doc> - Must start with a slash "/" and continue with path names separated by slashes. A path - name consists of any combination of at least one of [A-Za-z0-9] plus zero or more of - [.-_+!=:]. - </doc> - - <assert check = "notnull" /> - <assert check = "syntax" rule = "path" /> - <assert check = "length" value = "127" /> - </domain> - - <domain name = "peer-properties" type = "table"> - <doc> - This string provides a set of peer properties, used for identification, debugging, and - general information. - </doc> - </domain> - - <domain name = "queue-name" type = "shortstr" label = "queue name"> - <doc> - The queue name identifies the queue within the vhost. Queue names may consist of any - mixture of digits, letters, and underscores. - </doc> - <assert check = "length" value = "127" /> - </domain> - - <domain name = "redelivered" type = "bit" label = "message is being redelivered"> - <doc> - This indicates that the message has been previously delivered to this or - another client. - </doc> - <rule name = "implementation"> - <doc> - The server SHOULD try to signal redelivered messages when it can. When - redelivering a message that was not successfully acknowledged, the server - SHOULD deliver it to the original client if possible. - </doc> - <doc type = "scenario"> - Create a shared queue and publish a message to the queue. Consume the - message using explicit acknowledgements, but do not acknowledge the - message. Close the connection, reconnect, and consume from the queue - again. The message should arrive with the redelivered flag set. - </doc> - </rule> - <rule name = "hinting"> - <doc> - The client MUST NOT rely on the redelivered field but should take it as a - hint that the message may already have been processed. A fully robust - client must be able to track duplicate received messages on non-transacted, - and locally-transacted channels. - </doc> - </rule> - </domain> - - <domain name = "reply-code" type = "short" label = "reply code from server"> - <doc> - The reply code. The AMQ reply codes are defined as constants at the start - of this formal specification. - </doc> - <assert check = "notnull" /> - </domain> - - <domain name = "reply-text" type = "shortstr" label = "localised reply text"> - <doc> - The localised reply text. This text can be logged as an aid to resolving - issues. - </doc> - <assert check = "notnull" /> - </domain> - - <domain name = "channel-id" type = "longstr" label = "unique identifier for a channel" /> - - <!-- Domains for the message class --> - <domain name = "duration" type = "longlong" label = "duration in milliseconds" /> - <domain name = "offset" type = "longlong" label = "offset into a message body" /> - <domain name = "reference" type = "longstr" label = "pointer to a message body" /> - <domain name = "destination" type = "shortstr" label = "destination for a message"> - <doc> - Specifies the destination to which the message is to be - transferred. The destination can be empty, meaning the - default exchange or consumer. - </doc> - </domain> - <domain name = "reject-code" type = "short" label = "reject code for transfer"> - <rule name = "01"> - <doc> - The reject code must be one of 0 (generic) or 1 (immediate - delivery was attempted but failed). - </doc> - </rule> - </domain> - <domain name = "reject-text" type = "shortstr" label = "informational text for message reject"/> - <domain name = "security-token" type = "longstr" label = "security token"> - <doc> - Used for authentication, replay prevention, and encrypted bodies. - </doc> - </domain> - - <!-- Elementary domains --> - <domain name = "bit" type = "bit" label = "single bit" /> - <domain name = "octet" type = "octet" label = "single octet" /> - <domain name = "short" type = "short" label = "16-bit integer" /> - <domain name = "long" type = "long" label = "32-bit integer" /> - <domain name = "longlong" type = "longlong" label = "64-bit integer" /> - <domain name = "shortstr" type = "shortstr" label = "short string" /> - <domain name = "longstr" type = "longstr" label = "long string" /> - <domain name = "timestamp" type = "timestamp" label = "64-bit timestamp" /> - <domain name = "table" type = "table" label = "field table" /> - - <!-- == CONNECTION ======================================================= --> - - <!-- TODO 0.81 - the 'handler' attribute of methods needs to be reviewed, and if - no current implementations use it, removed. /PH 2006/07/20 - --> - - <class name = "connection" handler = "connection" index = "10" label = "work with socket connections"> - <doc> - The connection class provides methods for a client to establish a network connection to - a server, and for both peers to operate the connection thereafter. - </doc> - - <doc type = "grammar"> - connection = open-connection *use-connection close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "start" synchronous = "1" index = "10" label = "start connection negotiation"> - <doc> - This method starts the connection negotiation process by telling the client the - protocol version that the server proposes, along with a list of security mechanisms - which the client can use for authentication. - </doc> - - <rule name = "protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, - it MUST close the socket connection without sending any response method. - </doc> - <doc type = "scenario"> - The client sends a protocol header containing an invalid protocol name. - The server must respond by closing the connection. - </doc> - </rule> - <rule name = "server-support"> - <doc> - The server MUST provide a protocol version that is lower than or equal to - that requested by the client in the protocol header. - </doc> - <doc type = "scenario"> - The client requests a protocol version that is higher than any valid - implementation, e.g. 9.0. The server must respond with a current - protocol version, e.g. 1.0. - </doc> - </rule> - <rule name = "client-support"> - <doc> - If the client cannot handle the protocol version suggested by the server - it MUST close the socket connection. - </doc> - <doc type = "scenario"> - The server sends a protocol version that is lower than any valid - implementation, e.g. 0.1. The client must respond by closing the - connection. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - <response name = "start-ok" /> - - <field name = "version-major" domain = "octet" label = "protocol major version"> - <doc> - The protocol version, major component, as transmitted in the AMQP protocol - header. This, combined with the protocol minor component fully describe the - protocol version, which is written in the format major-minor. Hence, with - major=1, minor=3, the protocol version would be "1-3". - </doc> - </field> - - <field name = "version-minor" domain = "octet" label = "protocol minor version"> - <doc> - The protocol version, minor component, as transmitted in the AMQP protocol - header. This, combined with the protocol major component fully describe the - protocol version, which is written in the format major-minor. Hence, with - major=1, minor=3, the protocol version would be "1-3". - </doc> - </field> - - <field name = "server-properties" domain = "peer-properties" label = "server properties"> - <rule name = "required-fields"> - <doc> - The properties SHOULD contain at least these fields: "host", specifying the - server host name or address, "product", giving the name of the server product, - "version", giving the name of the server version, "platform", giving the name - of the operating system, "copyright", if appropriate, and "information", giving - other general information. - </doc> - <doc type = "scenario"> - Client connects to server and inspects the server properties. It checks for - the presence of the required fields. - </doc> - </rule> - </field> - - <field name = "mechanisms" domain = "longstr" label = "available security mechanisms"> - <doc> - A list of the security mechanisms that the server supports, delimited by spaces. - </doc> - <assert check = "notnull" /> - </field> - - <field name = "locales" domain = "longstr" label = "available message locales"> - <doc> - A list of the message locales that the server supports, delimited by spaces. The - locale defines the language in which the server will send reply texts. - </doc> - <rule name = "required-support"> - <doc> - The server MUST support at least the en_US locale. - </doc> - <doc type = "scenario"> - Client connects to server and inspects the locales field. It checks for - the presence of the required locale(s). - </doc> - </rule> - <assert check = "notnull" /> - </field> - </method> - - <method name = "start-ok" synchronous = "1" index = "11" - label = "select security mechanism and locale"> - <doc> - This method selects a SASL security mechanism. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "client-properties" domain = "peer-properties" label = "client properties"> - <rule name = "required-fields"> - <!-- This rule is not testable from the client side --> - <doc> - The properties SHOULD contain at least these fields: "product", giving the name - of the client product, "version", giving the name of the client version, "platform", - giving the name of the operating system, "copyright", if appropriate, and - "information", giving other general information. - </doc> - </rule> - </field> - - <field name = "mechanism" domain = "shortstr" label = "selected security mechanism"> - <doc> - A single security mechanisms selected by the client, which must be one of those - specified by the server. - </doc> - <rule name = "security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it - can handle from the list provided by the server. - </doc> - </rule> - <rule name = "validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms - proposed by the server in the Start method, the server MUST close the - connection without sending any further data. - </doc> - <doc type = "scenario"> - Client connects to server and sends an invalid security mechanism. The - server must respond by closing the connection (a socket close, with no - connection close negotiation). - </doc> - </rule> - <assert check = "notnull" /> - </field> - - <field name = "response" domain = "longstr" label = "security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this - data are defined by the SASL security mechanism. - </doc> - <assert check = "notnull" /> - </field> - - <field name = "locale" domain = "shortstr" label = "selected message locale"> - <doc> - A single message locale selected by the client, which must be one of those - specified by the server. - </doc> - <assert check = "notnull" /> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "secure" synchronous = "1" index = "20" label = "security mechanism challenge"> - <doc> - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This method challenges - the client to provide more information. - </doc> - - <chassis name = "client" implement = "MUST" /> - <response name = "secure-ok" /> - - <field name = "challenge" domain = "longstr" label = "security challenge data"> - <doc> - Challenge information, a block of opaque binary data passed to the security - mechanism. - </doc> - </field> - </method> - - <method name = "secure-ok" synchronous = "1" index = "21" label = "security mechanism response"> - <doc> - This method attempts to authenticate, passing a block of SASL data for the security - mechanism at the server side. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "response" domain = "longstr" label = "security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this - data are defined by the SASL security mechanism. - </doc> - <assert check = "notnull" /> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "tune" synchronous = "1" index = "30" - label = "propose connection tuning parameters"> - <doc> - This method proposes a set of connection configuration values to the client. The - client can accept and/or adjust these. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <response name = "tune-ok" /> - - <field name = "channel-max" domain = "short" label = "proposed maximum channels"> - <doc> - The maximum total number of channels that the server allows per connection. Zero - means that the server does not impose a fixed limit, but the number of allowed - channels may be limited by available server resources. - </doc> - </field> - - <field name = "frame-max" domain = "long" label = "proposed maximum frame size"> - <doc> - The largest frame size that the server proposes for the connection. The client - can negotiate a lower value. Zero means that the server does not impose any - specific limit but may reject very large frames if it cannot allocate resources - for them. - </doc> - <rule name = "minimum"> - <doc> - Until the frame-max has been negotiated, both peers MUST accept frames of up - to frame-min-size octets large, and the minimum negotiated value for frame-max - is also frame-min-size. - </doc> - <doc type = "scenario"> - Client connects to server and sends a large properties field, creating a frame - of frame-min-size octets. The server must accept this frame. - </doc> - </rule> - </field> - - <field name = "heartbeat" domain = "short" label = "desired heartbeat delay"> - <!-- TODO 0.82 - the heartbeat negotiation mechanism was changed during - implementation because the model documented here does not actually - work properly. The best model we found is that the server proposes - a heartbeat value to the client; the client can reply with zero, meaning - 'do not use heartbeats (as documented here), or can propose its own - heartbeat value, which the server should then accept. This is different - from the model here which is disconnected - e.g. each side requests a - heartbeat independently. Basically a connection is heartbeated in - both ways, or not at all, depending on whether both peers support - heartbeating or not, and the heartbeat value should itself be chosen - by the client so that remote links can get a higher value. Also, the - actual heartbeat mechanism needs documentation, and is as follows: so - long as there is activity on a connection - in or out - both peers - assume the connection is active. When there is no activity, each peer - must send heartbeat frames. When no heartbeat frame is received after - N cycles (where N is at least 2), the connection can be considered to - have died. /PH 2006/07/19 - --> - <doc> - The delay, in seconds, of the connection heartbeat that the server wants. - Zero means the server does not want a heartbeat. - </doc> - </field> - </method> - - <method name = "tune-ok" synchronous = "1" index = "31" - label = "negotiate connection tuning parameters"> - <doc> - This method sends the client's connection tuning parameters to the server. - Certain fields are negotiated, others provide capability information. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "channel-max" domain = "short" label = "negotiated maximum channels"> - <doc> - The maximum total number of channels that the client will use per connection. - </doc> - <rule name = "upper-limit"> - <doc> - If the client specifies a channel max that is higher than the value provided - by the server, the server MUST close the connection without attempting a - negotiated close. The server may report the error in some fashion to assist - implementors. - </doc> - </rule> - <assert check = "notnull" /> - <assert check = "le" method = "tune" field = "channel-max" /> - </field> - - <field name = "frame-max" domain = "long" label = "negotiated maximum frame size"> - <doc> - The largest frame size that the client and server will use for the connection. - Zero means that the client does not impose any specific limit but may reject - very large frames if it cannot allocate resources for them. Note that the - frame-max limit applies principally to content frames, where large contents can - be broken into frames of arbitrary size. - </doc> - <rule name = "minimum"> - <doc> - Until the frame-max has been negotiated, both peers MUST accept frames of up - to frame-min-size octets large, and the minimum negotiated value for frame-max - is also frame-min-size. - </doc> - </rule> - <rule name = "upper-limit"> - <doc> - If the client specifies a frame max that is higher than the value provided - by the server, the server MUST close the connection without attempting a - negotiated close. The server may report the error in some fashion to assist - implementors. - </doc> - </rule> - </field> - - <field name = "heartbeat" domain = "short" label = "desired heartbeat delay"> - <doc> - The delay, in seconds, of the connection heartbeat that the client wants. Zero - means the client does not want a heartbeat. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" synchronous = "1" index = "40" label = "open connection to virtual host"> - <doc> - This method opens a connection to a virtual host, which is a collection of - resources, and acts to separate multiple application domains within a server. - The server may apply arbitrary limits per virtual host, such as the number - of each type of entity that may be used, per connection and/or in total. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "open-ok" /> - <response name = "redirect" /> - - <field name = "virtual-host" domain = "path" label = "virtual host name"> - <!-- TODO 0.82 - the entire vhost model needs review. This concept was - prompted by the HTTP vhost concept but does not fit very well into - AMQP. Currently we use the vhost as a "cluster identifier" which is - inaccurate usage. /PH 2006/07/19 - --> - <assert check = "regexp" value = "^[a-zA-Z0-9/-_]+$" /> - <doc> - The name of the virtual host to work with. - </doc> - <rule name = "separation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full - separation of exchanges, queues, and all associated entities per virtual - host. An application, connected to a specific virtual host, MUST NOT be able - to access resources of another virtual host. - </doc> - </rule> - <rule name = "security"> - <doc> - The server SHOULD verify that the client has permission to access the - specified virtual host. - </doc> - </rule> - </field> - - <field name = "capabilities" domain = "shortstr" label = "required capabilities"> - <doc> - The client can specify zero or more capability names, delimited by spaces. - The server can use this string to how to process the client's connection - request. - </doc> - </field> - - <field name = "insist" domain = "bit" label = "insist on connecting to server"> - <doc> - In a configuration with multiple collaborating servers, the server may respond - to a Connection.Open method with a Connection.Redirect. The insist option tells - the server that the client is insisting on a connection to the specified server. - </doc> - <rule name = "behaviour"> - <doc> - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect method. If it cannot accept the client's connection - request it should respond by closing the connection with a suitable reply - code. - </doc> - </rule> - </field> - </method> - - <method name = "open-ok" synchronous = "1" index = "41" label = "signal that connection is ready"> - <doc> - This method signals to the client that the connection is ready for use. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "known-hosts" domain = "known-hosts" /> - </method> - - <method name = "redirect" synchronous = "1" index = "42" label = "redirects client to other server"> - <doc> - This method redirects the client to another server, based on the requested virtual - host and/or capabilities. - </doc> - <rule name = "usage"> - <doc> - When getting the Connection.Redirect method, the client SHOULD reconnect to - the host specified, and if that host is not present, to any of the hosts - specified in the known-hosts list. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <field name = "host" domain = "shortstr" label = "server to connect to"> - <doc> - Specifies the server to connect to. This is an IP address or a DNS name, - optionally followed by a colon and a port number. If no port number is - specified, the client should use the default port number for the protocol. - </doc> - <assert check = "notnull" /> - </field> - <field name = "known-hosts" domain = "known-hosts" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "close" synchronous = "1" index = "50" label = "request a connection close"> - <doc> - This method indicates that the sender wants to close the connection. This may be - due to internal conditions (e.g. a forced shut-down) or due to an error handling - a specific method, i.e. an exception. When a close is due to an exception, the - sender provides the class and method id of the method which caused the exception. - </doc> - <!-- TODO: the connection close mechanism needs to be reviewed from the ODF - documentation and better expressed as rules here. /PH 2006/07/20 - --> - <rule name = "stability"> - <doc> - After sending this method any received method except the Close-OK method MUST - be discarded. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - <response name = "close-ok" /> - - <field name = "reply-code" domain = "reply-code" /> - <field name = "reply-text" domain = "reply-text" /> - - <field name = "class-id" domain = "class-id" label = "failing method class"> - <doc> - When the close is provoked by a method exception, this is the class of the - method. - </doc> - </field> - - <field name = "method-id" domain = "method-id" label = "failing method ID"> - <doc> - When the close is provoked by a method exception, this is the ID of the method. - </doc> - </field> - </method> - - <method name = "close-ok" synchronous = "1" index = "51" label = "confirm a connection close"> - <doc> - This method confirms a Connection.Close method and tells the recipient that it is - safe to release resources for the connection and close the socket. - </doc> - <rule name = "reporting"> - <doc> - A peer that detects a socket closure without having received a Close-Ok - handshake method SHOULD log the error. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - </method> - </class> - - <!-- == CHANNEL ========================================================== --> - - <class name = "channel" handler = "channel" index = "20" label = "work with channels"> - <doc> - The channel class provides methods for a client to establish a channel to a - server and for both peers to operate the channel thereafter. - </doc> - - <doc type = "grammar"> - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - / C:RESUME S:OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:PING C:OK - / C:PONG S:OK - / C:PING S:OK - / S:PONG C:OK - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" synchronous = "1" index = "10" label = "open a channel for use"> - <doc> - This method opens a channel to the server. - </doc> - <rule name = "state" on-failure = "channel-error"> - <doc> - The client MUST NOT use this method on an already-opened channel. - </doc> - <doc type = "scenario"> - Client opens a channel and then reopens the same channel. - </doc> - </rule> - <chassis name = "server" implement = "MUST" /> - <response name = "open-ok" /> - <field name = "out-of-band" domain = "shortstr" label = "out-of-band settings"> - <doc> - Configures out-of-band transfers on this channel. The syntax and meaning of this - field will be formally defined at a later date. - </doc> - <assert check = "null" /> - </field> - </method> - - <method name = "open-ok" synchronous = "1" index = "11" label = "signal that the channel is ready"> - <doc> - This method signals to the client that the channel is ready for use. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "channel-id" domain = "channel-id" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "flow" synchronous = "1" index = "20" label = "enable/disable flow from peer"> - <doc> - This method asks the peer to pause or restart the flow of content data. This is a - simple flow-control mechanism that a peer can use to avoid overflowing its queues or - otherwise finding itself receiving more messages than it can process. Note that this - method is not intended for window control. The peer that receives a disable flow - method should finish sending the current content frame, if any, then pause. - </doc> - - <rule name = "initial-state"> - <doc> - When a new channel is opened, it is active (flow is active). Some applications - assume that channels are inactive until started. To emulate this behaviour a - client MAY open the channel, then pause it. - </doc> - </rule> - - <rule name = "bidirectional"> - <doc> - When sending content frames, a peer SHOULD monitor the channel for incoming - methods and respond to a Channel.Flow as rapidly as possible. - </doc> - </rule> - - <rule name = "throttling"> - <doc> - A peer MAY use the Channel.Flow method to throttle incoming content data for - internal reasons, for example, when exchanging data over a slower connection. - </doc> - </rule> - - <rule name = "expected-behaviour"> - <doc> - The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer - that does not respect the request. This is to prevent badly-behaved clients - from overwhelming a broker. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <response name = "flow-ok" /> - - <field name = "active" domain = "bit" label = "start/stop content frames"> - <doc> - If 1, the peer starts sending content frames. If 0, the peer stops sending - content frames. - </doc> - </field> - </method> - - <method name = "flow-ok" index = "21" label = "confirm a flow method"> - <doc> - Confirms to the peer that a flow command was received and processed. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <field name = "active" domain = "bit" label = "current flow setting"> - <doc> - Confirms the setting of the processed flow method: 1 means the peer will start - sending or continue to send content frames; 0 means it will not. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "close" synchronous = "1" index = "40" label = "request a channel close"> - <doc> - This method indicates that the sender wants to close the channel. This may be due to - internal conditions (e.g. a forced shut-down) or due to an error handling a specific - method, i.e. an exception. When a close is due to an exception, the sender provides - the class and method id of the method which caused the exception. - </doc> - - <!-- TODO: the channel close behaviour needs to be reviewed from the ODF - documentation and better expressed as rules here. /PH 2006/07/20 - --> - <rule name = "stability"> - <doc> - After sending this method any received method except the Close-OK method MUST - be discarded. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - <response name = "close-ok" /> - - <field name = "reply-code" domain = "reply-code" /> - <field name = "reply-text" domain = "reply-text" /> - - <field name = "class-id" domain = "class-id" label = "failing method class"> - <doc> - When the close is provoked by a method exception, this is the class of the - method. - </doc> - </field> - - <field name = "method-id" domain = "method-id" label = "failing method ID"> - <doc> - When the close is provoked by a method exception, this is the ID of the method. - </doc> - </field> - </method> - - <method name = "close-ok" synchronous = "1" index = "41" label = "confirm a channel close"> - <doc> - This method confirms a Channel.Close method and tells the recipient that it is safe - to release resources for the channel. - </doc> - <rule name = "reporting"> - <doc> - A peer that detects a socket closure without having received a Channel.Close-Ok - handshake method SHOULD log the error. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "resume" index = "50" label = "resume an interrupted channel"> - <doc> - This method resume a previously interrupted channel. - </doc> - <response name = "ok" /> - <chassis name = "server" implement = "MAY" /> - <field name = "channel-id" domain = "channel-id" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "ping" index = "60" label = "[WORK IN PROGRESS] initiates a pong"> - <doc> - [WORK IN PROGRESS] Request that the recipient issue a pong request. - </doc> - <response name = "ok" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "pong" index = "70" label = "[WORK IN PROGRESS] issued after receiving a ping"> - <doc> - [WORK IN PROGRESS] Issued after a ping request is received. Note that this is a - request issued after receiving a ping, not a response to - receiving a ping. - </doc> - <response name = "ok" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "ok" index = "80" label = "[WORK IN PROGRESS] signals normal completion"> - <doc> - [WORK IN PROGRESS] Signals normal completion of a method. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - </class> - - <!-- == ACCESS =========================================================== --> - - <!-- TODO 0.82 - this class must be implemented by two teams before we can - consider it matured. - --> - - <class name = "access" handler = "connection" index = "30" label = "work with access tickets"> - <doc> - The protocol control access to server resources using access tickets. A - client must explicitly request access tickets before doing work. An access - ticket grants a client the right to use a specific set of resources - - called a "realm" - in specific ways. - </doc> - - <doc type = "grammar"> - access = C:REQUEST S:REQUEST-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "request" synchronous = "1" index = "10" label = "request an access ticket"> - <doc> - This method requests an access ticket for an access realm. The server - responds by granting the access ticket. If the client does not have - access rights to the requested realm this causes a connection exception. - Access tickets are a per-channel resource. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "request-ok" /> - - <field name = "realm" domain = "shortstr" label = "name of requested realm"> - <doc> - Specifies the name of the realm to which the client is requesting access. - The realm is a configured server-side object that collects a set of - resources (exchanges, queues, etc.). If the channel has already requested - an access ticket onto this realm, the previous ticket is destroyed and a - new ticket is created with the requested access rights, if allowed. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST specify a realm that is known to the server. The server - makes an identical response for undefined realms as it does for realms - that are defined but inaccessible to this client. - </doc> - <doc type = "scenario"> - Client specifies an undefined realm. - </doc> - </rule> - </field> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive access to the realm, meaning that this will be the only - channel that uses the realm's resources. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MAY NOT request exclusive access to a realm that has active - access tickets, unless the same channel already had the only access - ticket onto that realm. - </doc> - <doc type = "scenario"> - Client opens two channels and requests exclusive access to the same realm. - </doc> - </rule> - </field> - <field name = "passive" domain = "bit" label = "request passive access"> - <doc> - Request message passive access to the specified access realm. Passive - access lets a client get information about resources in the realm but - not to make any changes to them. - </doc> - </field> - <field name = "active" domain = "bit" label = "request active access"> - <doc> - Request message active access to the specified access realm. Active access lets - a client get create and delete resources in the realm. - </doc> - </field> - <field name = "write" domain = "bit" label = "request write access"> - <doc> - Request write access to the specified access realm. Write access lets a client - publish messages to all exchanges in the realm. - </doc> - </field> - <field name = "read" domain = "bit" label = "request read access"> - <doc> - Request read access to the specified access realm. Read access lets a client - consume messages from queues in the realm. - </doc> - </field> - </method> - - <method name = "request-ok" synchronous = "1" index = "11" label = "grant access to server resources"> - <doc> - This method provides the client with an access ticket. The access ticket is valid - within the current channel and for the lifespan of the channel. - </doc> - <rule name = "per-channel" on-failure = "not-allowed"> - <doc> - The client MUST NOT use access tickets except within the same channel as - originally granted. - </doc> - <doc type = "scenario"> - Client opens two channels, requests a ticket on one channel, and then - tries to use that ticket in a second channel. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <field name = "ticket" domain = "access-ticket" /> - </method> - </class> - - <!-- == EXCHANGE ========================================================= --> - - <class name = "exchange" handler = "channel" index = "40" label = "work with exchanges"> - <doc> - Exchanges match and distribute messages across queues. Exchanges can be configured in - the server or created at runtime. - </doc> - - <doc type = "grammar"> - exchange = C:DECLARE S:DECLARE-OK - / C:DELETE S:DELETE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <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. - </doc> - <doc> - The server MUST, in each virtual host, pre-declare at least two direct - exchange instances: one named "amq.direct", the other with no public name - that serves as a default exchange for Publish methods. - </doc> - <doc type = "scenario"> - Client creates a temporary queue and attempts to bind to each required - exchange instance ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" - if those types are defined). - </doc> - </rule> - <rule name = "default-exchange"> - <doc> - The server MUST pre-declare a direct exchange with no public name to act as - the default exchange for content Publish methods and for default queue bindings. - </doc> - <doc type = "scenario"> - Client checks that the default exchange is active by specifying a queue - binding with no exchange name, and 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 server MUST NOT allow clients to access the default exchange except - by specifying an empty exchange name in the Queue.Bind and content Publish - methods. - </doc> - </rule> - <rule name = "extensions"> - <doc> - The server MAY implement other exchange types as wanted. - </doc> - </rule> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "declare" synchronous = "1" index = "10" label = "verify exchange exists, create if needed"> - <doc> - This method creates an exchange if it does not already exist, and if the exchange - exists, verifies that it is of the correct and expected class. - </doc> - <rule name = "minimum"> - <doc> - The server SHOULD support a minimum of 16 exchanges per virtual host and - ideally, impose no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - The client creates as many exchanges as it can until the server reports - an error; the number of exchanges successfully created must be at least - sixteen. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "declare-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - When a client defines a new exchange, this belongs to the access realm of the - ticket used. All further work done with that exchange must be done with an - access ticket for the same realm. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access to - the realm in which the exchange exists or will be created, or "passive" - access if the if-exists flag is set. - </doc> - <doc type = "scenario"> - Client creates access ticket with wrong access rights and attempts to use - in this method. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <rule name = "reserved" on-failure = "access-refused"> - <doc> - Exchange names starting with "amq." are reserved for pre-declared and - standardised exchanges. The client MUST NOT attempt to create an exchange - starting with "amq.". - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <assert check = "regexp" value = "^[a-zA-Z0-9-_.:]+$" /> - </field> - - <field name = "type" domain = "shortstr" label = "exchange type"> - <doc> - Each exchange belongs to one of a set of exchange types implemented by the - server. The exchange types define the functionality of the exchange - i.e. how - messages are routed through it. It is not valid or meaningful to attempt to - change the type of an existing exchange. - </doc> - <rule name = "typed" on-failure = "not-allowed"> - <doc> - Exchanges cannot be redeclared with different types. The client MUST not - attempt to redeclare an existing exchange with a different type than used - in the original Exchange.Declare method. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <rule name = "support" on-failure = "command-invalid"> - <doc> - The client MUST NOT attempt to create an exchange with a type that the - server does not support. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <assert check = "regexp" value = "^[a-zA-Z0-9-_.:]+$" /> - </field> - - <field name = "passive" domain = "bit" label = "do not create exchange"> - <doc> - If set, the server will not create the exchange. The client can use this to - check whether an exchange exists without modifying the server state. - </doc> - <rule name = "not-found"> - <doc> - If set, and the exchange does not already exist, the server MUST raise a - channel exception with reply code 404 (not found). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "durable" domain = "bit" label = "request a durable exchange"> - <doc> - If set when creating a new exchange, the exchange will be marked as durable. - Durable exchanges remain active when a server restarts. Non-durable exchanges - (transient exchanges) are purged if/when a server restarts. - </doc> - <rule name = "support"> - <doc> - The server MUST support both durable and transient exchanges. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <rule name = "sticky"> - <doc> - The server MUST ignore the durable field if the exchange already exists. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <!-- TODO 0.82 - clarify how this works; there is no way to cancel a binding - except by deleting a queue. - --> - <field name = "auto-delete" domain = "bit" label = "auto-delete when unused"> - <doc> - If set, the exchange is deleted when all queues have finished using it. - </doc> - <rule name = "sticky"> - <doc> - The server MUST ignore the auto-delete field if the exchange already - exists. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "internal" domain = "bit" label = "create internal exchange"> - <doc> - If set, the exchange may not be used directly by publishers, but only when bound - to other exchanges. Internal exchanges are used to construct wiring that is not - visible to applications. - </doc> - </field> - - <field name = "nowait" domain = "bit" label = "do not send reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these - arguments depends on the server implementation. This field is ignored if passive - is 1. - </doc> - </field> - </method> - - <method name = "declare-ok" synchronous = "1" index = "11" label = "confirm exchange declaration"> - <doc> - This method confirms a Declare method and confirms the name of the exchange, - essential for automatically-named exchanges. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "delete" synchronous = "1" index = "20" label = "delete an exchange"> - <doc> - This method deletes an exchange. When an exchange is deleted all queue bindings on - the exchange are cancelled. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "delete-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access - rights to the exchange's access realm. - </doc> - <doc type = "scenario"> - Client creates access ticket with wrong access rights and attempts to use - in this method. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <rule name = "exists" on-failure = "not-found"> - <doc> - The client MUST NOT attempt to delete an exchange that does not exist. - </doc> - </rule> - <assert check = "notnull" /> - </field> - - <!-- TODO 0.82 - discuss whether this option is useful or not. I don't have - any real use case for it. /PH 2006-07-23. - --> - <field name = "if-unused" domain = "bit" label = "delete only if unused"> - <doc> - If set, the server will only delete the exchange if it has no queue bindings. If - the exchange has queue bindings the server does not delete it but raises a - channel exception instead. - </doc> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "delete-ok" synchronous = "1" index = "21" - label = "confirm deletion of an exchange"> - <doc>This method confirms the deletion of an exchange.</doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- RG : Added Exchange.bound and Exchange.bound-ok --> - <method name="bound" synchronous="1" index="22"> - <chassis name="server" implement="SHOULD"/> - <response name="bound-ok"/> - <field name="exchange" domain="exchange-name"/> - <field name = "routing-key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - <field name = "queue" domain = "queue name"/> - </method> - - <method name="bound-ok" synchronous="1" index="23"> - <field name="reply-code" domain="reply-code"/> - <field name="reply-text" domain="reply-text"/> - <chassis name="client" implement="SHOULD"/> - </method> - - </class> - - <!-- == QUEUE ============================================================ --> - - <class name = "queue" handler = "channel" index = "50" label = "work with queues"> - <doc> - Queues store and forward messages. Queues can be configured in the server or created at - runtime. Queues must be attached to at least one exchange in order to receive messages - from publishers. - </doc> - - <doc type = "grammar"> - queue = C:DECLARE S:DECLARE-OK - / C:BIND S:BIND-OK - / C:PURGE S:PURGE-OK - / C:DELETE S:DELETE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <rule name = "any-content"> - <doc> - A server MUST allow any content class to be sent to any queue, in any mix, and - queue and deliver these content classes independently. Note that all methods - that fetch content off queues are specific to a given content class. - </doc> - <doc type = "scenario"> - Client creates an exchange of each standard type and several queues that - it binds to each exchange. It must then successfully send each of the standard - content types to each of the available queues. - </doc> - </rule> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "declare" synchronous = "1" index = "10" label = "declare queue, create if needed"> - <doc> - This method creates or checks a queue. When creating a new queue the client can - specify various properties that control the durability of the queue and its - contents, and the level of sharing for the queue. - </doc> - - <rule name = "default-binding"> - <doc> - The server MUST create a default binding for a newly-created queue to the - default exchange, which is an exchange of type 'direct' and use the queue - name as the routing key. - </doc> - <doc type = "scenario"> - Client creates a new queue, and then without explicitly binding it to an - exchange, attempts to send a message through the default exchange binding, - i.e. publish a message to the empty exchange, with the queue name as routing - key. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_35" --> - <rule name = "minimum-queues"> - <doc> - The server SHOULD support a minimum of 256 queues per virtual host and ideally, - impose no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - Client attempts to create as many queues as it can until the server reports - an error. The resulting count must at least be 256. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "declare-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - When a client defines a new queue, this belongs to the access realm of the - ticket used. All further work done with that queue must be done with an access - ticket for the same realm. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access to - the realm in which the queue exists or will be created. - </doc> - <doc type = "scenario"> - Client creates access ticket with wrong access rights and attempts to use - in this method. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <rule name = "default-name"> - <doc> - The queue name MAY be empty, in which case the server MUST create a new - queue with a unique generated name and return this to the client in the - Declare-Ok method. - </doc> - <doc type = "scenario"> - Client attempts to create several queues with an empty name. The client then - verifies that the server-assigned names are unique and different. - </doc> - </rule> - <rule name = "reserved-prefix" on-failure = "not-allowed"> - <doc> - Queue names starting with "amq." are reserved for pre-declared and - standardised server queues. A client MAY NOT attempt to declare a queue with a - name that starts with "amq." and the passive option set to zero. - </doc> - <doc type = "scenario"> - A client attempts to create a queue with a name starting with "amq." and with - the passive option set to zero. - </doc> - </rule> - <assert check = "regexp" value = "^[a-zA-Z0-9-_.:]*$" /> - </field> - - <field name = "passive" domain = "bit" label = "do not create queue"> - <doc> - If set, the server will not create the queue. This field allows the client - to assert the presence of a queue without modifying the server state. - </doc> - <rule name = "passive" on-failure = "not-found"> - <doc> - The client MAY ask the server to assert that a queue exists without - creating the queue if not. If the queue does not exist, the server - treats this as a failure. - </doc> - <doc type = "scenario"> - Client declares an existing queue with the passive option and expects - the server to respond with a declare-ok. Client then attempts to declare - a non-existent queue with the passive option, and the server must close - the channel with the correct reply-code. - </doc> - </rule> - </field> - - <field name = "durable" domain = "bit" label = "request a durable queue"> - <doc> - If set when creating a new queue, the queue will be marked as durable. Durable - queues remain active when a server restarts. Non-durable queues (transient - queues) are purged if/when a server restarts. Note that durable queues do not - necessarily hold persistent messages, although it does not make sense to send - persistent messages to a transient queue. - </doc> - <!-- Rule test name: was "amq_queue_03" --> - <rule name = "persistence"> - <doc>The server MUST recreate the durable queue after a restart.</doc> - - <!-- TODO: use 'client does something' rather than 'a client does something'. --> - <doc type = "scenario"> - A client creates a durable queue. The server is then restarted. The client - then attempts to send a message to the queue. The message should be successfully - delivered. - </doc> - </rule> - <!-- Rule test name: was "amq_queue_36" --> - <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 test name: was "amq_queue_37" --> - <rule name = "pre-existence"> - <doc>The server MUST ignore the durable field if the queue already exists.</doc> - <doc type = "scenario"> - A client creates two named queues, one durable and one transient. The client - then attempts to declare the two queues using the same names again, but reversing - the value of the durable flag in each case. Verify that the queues still exist - with the original durable flag values. - <!-- TODO: but how? --> - </doc> - </rule> - </field> - - <field name = "exclusive" domain = "bit" label = "request an exclusive queue"> - <doc> - Exclusive queues may only be consumed from by the current connection. Setting - the 'exclusive' flag always implies 'auto-delete'. - </doc> - - <!-- Rule test name: was "amq_queue_38" --> - <rule name = "types"> - <doc> - The server MUST support both exclusive (private) and non-exclusive (shared) - queues. - </doc> - <doc type = "scenario"> - A client creates two named queues, one exclusive and one non-exclusive. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_04" --> - <rule name = "02" on-failure = "channel-error"> - <doc> - The client MAY NOT attempt to declare any existing and exclusive queue - on multiple connections. - </doc> - <doc type = "scenario"> - A client declares an exclusive named queue. A second client on a different - connection attempts to declare a queue of the same name. - </doc> - </rule> - </field> - - <field name = "auto-delete" domain = "bit" label = "auto-delete queue when unused"> - <doc> - If set, the queue is deleted when all consumers have finished using it. Last - consumer can be cancelled either explicitly or because its channel is closed. If - there was no consumer ever on the queue, it won't be deleted. - </doc> - - <!-- Rule test name: was "amq_queue_31" --> - <rule name = "pre-existence"> - <doc> - The server MUST ignore the auto-delete field if the queue already exists. - </doc> - <doc type = "scenario"> - A client creates two named queues, one as auto-delete and one explicit-delete. - The client then attempts to declare the two queues using the same names again, - but reversing the value of the auto-delete field in each case. Verify that the - queues still exist with the original auto-delete flag values. - <!-- TODO: but how? --> - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these - arguments depends on the server implementation. This field is ignored if passive - is 1. - </doc> - </field> - </method> - - <method name = "declare-ok" synchronous = "1" index = "11" label = "confirms a queue definition"> - <doc> - This method confirms a Declare method and confirms the name of the queue, essential - for automatically-named queues. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "queue" domain = "queue-name"> - <doc> - Reports the name of the queue. If the server generated a queue name, this field - contains that name. - </doc> - <assert check = "notnull" /> - </field> - - <field name = "message-count" domain = "long" label = "number of messages in queue"> - <doc> - Reports the number of messages in the queue, which will be zero for - newly-created queues. - </doc> - </field> - - <field name = "consumer-count" domain = "long" label = "number of consumers"> - <doc> - Reports the number of active consumers for the queue. Note that consumers can - suspend activity (Channel.Flow) in which case they do not appear in this count. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "bind" synchronous = "1" index = "20" label = "bind queue to an exchange"> - <doc> - This method binds a queue to an exchange. Until a queue is bound it will not receive - any messages. In a classic messaging model, store-and-forward queues are bound to a - direct exchange and subscription queues are bound to a topic exchange. - </doc> - - <!-- Rule test name: was "amq_queue_25" --> - <rule name = "duplicates"> - <doc> - A server MUST allow ignore duplicate bindings - that is, two or more bind - methods for a specific queue, with identical arguments - without treating these - as an error. - </doc> - <doc type = "scenario"> - A client binds a named queue to an exchange. The client then repeats the bind - (with identical arguments). - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_39" --> - <rule name = "failure"> - <!-- - TODO: Find correct on-failure code. The on-failure code returned should depend on why the bind - failed. Assuming that failures owing to bad parameters are covered in the rules relating - to those parameters, the only remaining reason for a failure would be the lack of - server resorces or some internal error - such as too many queues open. Would these - cases qualify as "resource error" 506 or "internal error" 541? - --> - <doc>If a bind fails, the server MUST raise a connection exception.</doc> - <doc type = "scenario"> - TODO - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_12" --> - <rule name = "transient-exchange" on-failure = "not-allowed"> - <doc> - The server MUST NOT allow a durable queue to bind to a transient exchange. - </doc> - <doc type = "scenario"> - A client creates a transient exchange. The client then declares a named durable - queue and then attempts to bind the transient exchange to the durable queue. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_13" --> - <rule name = "durable-exchange"> - <doc> - Bindings for durable queues are automatically durable and the server SHOULD - restore such bindings after a server restart. - </doc> - <doc type = "scenario"> - A server creates a named durable queue and binds it to a durable exchange. The - server is restarted. The client then attempts to use the queue/exchange combination. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_17" --> - <rule name = "internal-exchange"> - <doc> - If the client attempts to bind to an exchange that was declared as internal, the server - MUST raise a connection exception with reply code 530 (not allowed). - </doc> - <doc type = "scenario"> - A client attempts to bind a named queue to an internal exchange. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_40" --> - <rule name = "binding-count"> - <doc> - The server SHOULD support at least 4 bindings per queue, and ideally, impose no - limit except as defined by available resources. - </doc> - <doc type = "scenario"> - A client creates a named queue and attempts to bind it to 4 different non-internal - exchanges. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "bind-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - The client provides a valid access ticket giving "active" access rights to the - queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to bind. If the queue name is empty, refers to - the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "empty-queue" on-failure = "not-allowed"> - <doc> - A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. - empty queue name) to an exchange. - </doc> - <doc type = "scenario"> - A client attempts to bind with an unnamed (empty) queue name to an exchange. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_26" --> - <rule name = "queue-existence" on-failure = "not-found"> - <doc> - A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously - declared) to an exchange. - </doc> - <doc type = "scenario"> - A client attempts to bind an undeclared queue name to an exchange. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name" label = "name of the exchange to bind to"> - <!-- Rule test name: was "amq_queue_14" --> - <rule name = "exchange-existence" on-failure = "not-found"> - <doc> - A client MUST NOT be allowed to bind a queue to a non-existent exchange. - </doc> - <doc type = "scenario"> - A client attempts to bind an named queue to a undeclared exchange. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "message routing key"> - <doc> - Specifies the routing key for the binding. The routing key is used for routing - messages depending on the exchange configuration. Not all exchanges use a - routing key - refer to the specific exchange documentation. If the queue name - is empty, the server uses the last queue declared on the channel. If the - routing key is also empty, the server uses this queue name for the routing - key as well. If the queue name is provided but the routing key is empty, the - server does the binding with that empty routing key. The meaning of empty - routing keys depends on the exchange implementation. - </doc> - <rule name = "direct-exchange-key-matching"> - <doc> - If a message queue binds to a direct exchange using routing key K and a - publisher sends the exchange a message with routing key R, then the message - MUST be passed to the message queue if K = R. - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments for binding"> - <doc> - A set of arguments for the binding. The syntax and semantics of these arguments - depends on the exchange class. - </doc> - </field> - </method> - - <method name = "bind-ok" synchronous = "1" index = "21" label = "confirm bind successful"> - <doc>This method confirms that the bind was successful.</doc> - - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "unbind" synchronous = "1" index = "50" label = "unbind a queue from an exchange"> - <doc>This method unbinds a queue from an exchange.</doc> - <rule name = "01"> - <doc>If a unbind fails, the server MUST raise a connection exception.</doc> - </rule> - <chassis name="server" implement="MUST"/> - <response name="unbind-ok"/> - - <field name = "ticket" domain = "access-ticket"> - <doc> - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc>Specifies the name of the queue to unbind.</doc> - <rule name = "02"> - <doc> - If the queue does not exist the server MUST raise a channel exception - with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc>The name of the exchange to unbind from.</doc> - <rule name = "03"> - <doc> - If the exchange does not exist the server MUST raise a channel - exception with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "routing key of binding"> - <doc>Specifies the routing key of the binding to unbind.</doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments of binding"> - <doc>Specifies the arguments of the binding to unbind.</doc> - </field> - </method> - - <method name = "unbind-ok" synchronous = "1" index = "51" label = "confirm unbind successful"> - <doc>This method confirms that the unbind was successful.</doc> - <chassis name = "client" implement = "MUST"/> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "purge" synchronous = "1" index = "30" label = "purge a queue"> - <doc> - This method removes all messages from a queue. It does not cancel consumers. Purged - messages are deleted without any formal "undo" mechanism. - </doc> - - <!-- Rule test name: was "amq_queue_15" --> - <rule name = "01"> - <doc>A call to purge MUST result in an empty queue.</doc> - </rule> - - <!-- Rule test name: was "amq_queue_41" --> - <rule name = "02"> - <doc> - On transacted channels the server MUST not purge messages that have already been - sent to a client but not yet acknowledged. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <!-- Rule test name: was "amq_queue_42" --> - <rule name = "03"> - <doc> - The server MAY implement a purge queue or log that allows system administrators - to recover accidentally-purged messages. The server SHOULD NOT keep purged - messages in the same storage spaces as the live messages since the volumes of - purged messages may get very large. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "purge-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc>The access ticket must be for the access realm that holds the queue.</doc> - - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the queue's access realm. Note that purging a queue is equivalent to reading - all messages and discarding them. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to purge. If the queue name is empty, refers to - the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - - <!-- TODO Rule split? --> - - <!-- Rule test name: was "amq_queue_16" --> - <rule name = "02"> - <doc> - The queue MUST exist. Attempting to purge a non-existing queue MUST cause a - channel exception. - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "purge-ok" synchronous = "1" index = "31" label = "confirms a queue purge"> - <doc>This method confirms the purge of a queue.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "message-count" domain = "long" label = "number of messages purged"> - <doc>Reports the number of messages purged.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "delete" synchronous = "1" index = "40" label = "delete a queue"> - <doc> - This method deletes a queue. When a queue is deleted any pending messages are sent - to a dead-letter queue if this is defined in the server configuration, and all - consumers on the queue are cancelled. - </doc> - - <!-- TODO: Rule split? --> - - <!-- Rule test name: was "amq_queue_43" --> - <rule name = "01"> - <doc> - The server SHOULD use a dead-letter queue to hold messages that were pending on - a deleted queue, and MAY provide facilities for a system administrator to move - these messages back to an active queue. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "delete-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - The client provides a valid access ticket giving "active" access rights to the - queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to delete. If the queue name is empty, refers to - the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_21" --> - <rule name = "02"> - <doc> - The queue must exist. If the client attempts to delete a non-existing queue - the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name = "if-unused" domain = "bit" label = "delete only if unused"> - <doc> - If set, the server will only delete the queue if it has no consumers. If the - queue has consumers the server does does not delete it but raises a channel - exception instead. - </doc> - - <!-- Rule test name: was "amq_queue_29" and "amq_queue_30" --> - <rule name = "01"> - <doc>The server MUST respect the if-unused flag when deleting a queue.</doc> - </rule> - </field> - - <field name = "if-empty" domain = "bit" label = "delete only if empty"> - <doc> - If set, the server will only delete the queue if it has no messages. - </doc> - <rule name = "01"> - <doc> - If the queue is not empty the server MUST raise a channel exception with - reply code 406 (precondition failed). - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "delete-ok" synchronous = "1" index = "41" label = "confirm deletion of a queue"> - <doc>This method confirms the deletion of a queue.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "message-count" domain = "long" label = "number of messages purged"> - <doc>Reports the number of messages purged.</doc> - </field> - </method> - </class> - - <!-- == BASIC ============================================================ --> - - <class name = "basic" handler = "channel" index = "60" label = "work with basic content"> - <doc> - The Basic class provides methods that support an industry-standard messaging model. - </doc> - - <doc type = "grammar"> - basic = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MAY" /> - - <!-- Rule test name: was "amq_basic_08" --> - <rule name = "01"> - <doc> - The server SHOULD respect the persistent property of basic messages and - SHOULD make a best-effort to hold persistent basic messages on a reliable - storage mechanism. - </doc> - <doc type = "scenario"> - Send a persistent message to queue, stop server, restart server and then - verify whether message is still present. Assumes that queues are durable. - Persistence without durable queues makes no sense. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_09" --> - <rule name = "02"> - <doc> - The server MUST NOT discard a persistent basic message in case of a queue - overflow. - </doc> - <doc type = "scenario"> - Create a queue overflow situation with persistent messages and verify that - messages do not get lost (presumably the server will write them to disk). - </doc> - </rule> - - <rule name = "03"> - <doc> - The server MAY use the Channel.Flow method to slow or stop a basic message - publisher when necessary. - </doc> - <doc type = "scenario"> - Create a queue overflow situation with non-persistent messages and verify - whether the server responds with Channel.Flow or not. Repeat with persistent - messages. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_10" --> - <rule name = "04"> - <doc> - The server MAY overflow non-persistent basic messages to persistent - storage. - </doc> - <!-- Test scenario: untestable --> - </rule> - - <rule name = "05"> - <doc> - The server MAY discard or dead-letter non-persistent basic messages on a - priority basis if the queue size exceeds some configured limit. - </doc> - <!-- Test scenario: untestable --> - </rule> - - <!-- Rule test name: was "amq_basic_11" --> - <rule name = "06"> - <doc> - The server MUST implement at least 2 priority levels for basic messages, - where priorities 0-4 and 5-9 are treated as two distinct levels. - </doc> - <doc type = "scenario"> - Send a number of priority 0 messages to a queue. Send one priority 9 - message. Consume messages from the queue and verify that the first message - received was priority 9. - </doc> - </rule> - - <rule name = "07"> - <doc> - The server MAY implement up to 10 priority levels. - </doc> - <doc type = "scenario"> - Send a number of messages with mixed priorities to a queue, so that all - priority values from 0 to 9 are exercised. A good scenario would be ten - messages in low-to-high priority. Consume from queue and verify how many - priority levels emerge. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_12" --> - <rule name = "08"> - <doc> - The server MUST deliver messages of the same priority in order irrespective of - their individual persistence. - </doc> - <doc type = "scenario"> - Send a set of messages with the same priority but different persistence - settings to a queue. Consume and verify that messages arrive in same order - as originally published. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_13" --> - <rule name = "09"> - <doc> - The server MUST support automatic acknowledgements on Basic content, i.e. - consumers with the no-ack field set to FALSE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using automatic acknowledgements. Publish - a set of messages to the queue. Consume the messages and verify that all - messages are received. - </doc> - </rule> - - <rule name = "10"> - <doc> - The server MUST support explicit acknowledgements on Basic content, i.e. - consumers with the no-ack field set to TRUE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using explicit acknowledgements. Publish a - set of messages to the queue. Consume the messages but acknowledge only - half of them. Disconnect and reconnect, and consume from the queue. - Verify that the remaining messages are received. - </doc> - </rule> - - <!-- These are the properties for a Basic content --> - - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "delivery-mode" domain = "octet" label = "non-persistent (1) or persistent (2)" /> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "correlation-id" domain = "shortstr" label = "application correlation identifier" /> - <field name = "reply-to" domain = "shortstr" label = "destination to reply to" /> - <field name = "expiration" domain = "shortstr" label = "message expiration specification" /> - <field name = "message-id" domain = "shortstr" label = "application message identifier" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp" /> - <field name = "type" domain = "shortstr" label = "message type name" /> - <field name = "user-id" domain = "shortstr" label = "creating user id" /> - <field name = "app-id" domain = "shortstr" label = "creating application id" /> - <!-- This field is deprecated pending review --> - <field name = "cluster-id" domain = "shortstr" label = "intra-cluster routing identifier" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. The server - will send a message in advance if it is equal to or smaller in size than the - available prefetch size (and also falls into other prefetch limits). May be set - to zero, meaning "no specific limit", although other prefetch limits may still - apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - <!-- Rule test name: was "amq_basic_17" --> - <rule name = "01"> - <doc> - The server MUST ignore this setting when the client is not processing any - messages - i.e. the prefetch size does not limit the transfer of single - messages to a client, only the sending in advance of more messages while - the client still has one or more unacknowledged messages. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and send a single message that exceeds - that limit. Verify that the message arrives correctly. - </doc> - </rule> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used - in combination with the prefetch-size field; a message will only be sent in - advance if both prefetch windows (and those at the channel and connection level) - allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - <!-- Rule test name: was "amq_basic_18" --> - <rule name = "01"> - <doc> - The server may send less data in advance than allowed by the client's - specified prefetch windows but it MUST NOT send more. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and a prefetch-count limit greater than - one. Send multiple messages that exceed the prefetch size. Verify that - no more than one message arrives at once. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the - server. The requested QoS applies to all active consumers until a new QoS is - defined. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <!-- Rule test name: was "amq_basic_01" --> - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, and ideally, impose - no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - Create a queue and create consumers on that queue until the server closes the - connection. Verify that the number of consumers created was at least sixteen - and report the total number. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an invalid (non-zero) access ticket. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - If the queue name is empty the client MUST have previously declared a - queue using this channel. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an empty queue name and no previously - declared queue on the channel. - </doc> - </rule> - </field> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a - connection, so two clients can use the same consumer tags. If this field is - empty the server will generate a unique tag. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - The client MUST NOT specify a tag that refers to an existing consumer. - </doc> - <doc type = "scenario"> - Attempt to create two consumers with the same non-empty tag. - </doc> - </rule> - <rule name = "02" on-failure = "not-allowed"> - <doc> - The consumer tag is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in one - channel and then use it in another. - </doc> - <doc type = "scenario"> - Attempt to create a consumer in one channel, then use in another channel, - in which consumers have also been created (to test that the server uses - unique consumer tags). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "no-ack" domain = "no-ack" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - <!-- Rule test name: was "amq_basic_02" --> - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MAY NOT gain exclusive access to a queue that already has - active consumers. - </doc> - <doc type = "scenario"> - Open two connections to a server, and in one connection create a shared - (non-exclusive) queue and then consume from the queue. In the second - connection attempt to consume from the same queue using the exclusive - option. - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise - a channel or connection exception. - </doc> - </field> - - <!-- RG changed name from filter to arguments on basic.consume: this is inline with qpid0-8 and 0-10 and has no effect on the wire level encoding - <field name = "arguments" domain = "table" label = "arguments for consuming"> --> - <field name = "arguments" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer"> - <doc> - The server provides the client with a consumer tag, which is used by the client - for methods called on the consumer at a later stage. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer"> - <doc> - This method cancels a consumer. This does not affect already delivered - messages, but it does mean the server will not send any more messages for - that consumer. The client may receive an arbitrary number of messages in - between sending the cancel method and receiving the cancel-ok reply. - </doc> - - <rule name = "01"> - <doc> - If the queue does not exist the server MUST ignore the cancel method, so - long as the consumer tag is valid for that channel. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer"> - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "consumer-tag" domain = "consumer-tag" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "publish" content = "1" index = "40" label = "publish a message"> - <doc> - This method publishes a message to a specific exchange. The message will be routed - to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be - empty, meaning the default exchange. If the exchange name is specified, and that - exchange does not exist, the server will raise a channel exception. - </doc> - - <!-- Rule test name: was "amq_basic_06" --> - <rule name = "01"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_14" --> - <rule name = "02"> - <doc> - If the exchange was declared as an internal exchange, the server MUST raise - a channel exception with a reply code 403 (access refused). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_15" --> - <rule name = "03"> - <doc> - The exchange MAY refuse basic content in which case it MUST raise a channel - exception with reply code 540 (not implemented). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing - messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" domain = "bit" label = "indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue. If this flag is set, the server will return an unroutable message with a - Return method. If this flag is zero, the server silently drops the message. - </doc> - <!-- Rule test name: was "amq_basic_07" --> - <rule name = "01"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue consumer immediately. If this flag is set, the server will return an - undeliverable message with a Return method. If this flag is zero, the server - will queue the message, but with no guarantee that it will ever be consumed. - </doc> - <!-- Rule test name: was "amq_basic_16" --> - <rule name = "01"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - </method> - - <method name = "return" content = "1" index = "50" label = "return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" - flag set, or an unroutable message published with the "mandatory" flag set. The - reply code and text provide information about the reason that the message was - undeliverable. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "reply-code" domain = "reply-code" /> - - <field name = "reply-text" domain = "reply-text" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "deliver" content = "1" index = "60" - label = "notify the client of a consumer message"> - <doc> - This method delivers a message to the client, via a consumer. In the asynchronous - message delivery model, the client starts a consumer using the Consume method, then - the server responds with Deliver methods as and when messages arrive for that - consumer. - </doc> - - <!-- Rule test name: was "amq_basic_19" --> - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server SHOULD track the number of times a message has been delivered to - clients and when a message is redelivered a certain number of times - e.g. 5 - times - without being acknowledged, the server SHOULD consider the message to be - unprocessable (possibly causing client applications to abort), and move the - message to a dead letter queue. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "get" synchronous = "1" index = "70" label = "direct access to a queue"> - <doc> - This method provides a direct access to the messages in a queue using a synchronous - dialogue that is designed for specific types of application where synchronous - functionality is more important than performance. - </doc> - - <response name = "get-ok" /> - <response name = "get-empty" /> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "no-ack" domain = "no-ack" /> - </method> - - <method name = "get-ok" synchronous = "1" content = "1" index = "71" - label = "provide client with a message"> - <doc> - This method delivers a message to the client following a get method. A message - delivered by 'get-ok' must be acknowledged unless the no-ack option was set in the - get method. - </doc> - - <chassis name = "client" implement = "MAY" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - If empty, the message was published to the default exchange. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - - <field name = "message-count" domain = "long" label = "number of messages pending"> - <doc> - This field reports the number of messages pending on the queue, excluding the - message being delivered. Note that this figure is indicative, not reliable, and - can change arbitrarily as messages are added to the queue and removed by other - clients. - </doc> - </field> - </method> - - <method name = "get-empty" synchronous = "1" index = "72" - label = "indicate no messages available"> - <doc> - This method tells the client that the queue has no messages available for the - client. - </doc> - - <chassis name = "client" implement = "MAY" /> - - <!-- This field is deprecated pending review --> - <field name = "cluster-id" domain = "shortstr" label = "Cluster id"> - <doc> - For use by cluster applications, should not be used by client applications. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "ack" index = "80" label = "acknowledge one or more messages"> - <doc> - This method acknowledges one or more messages delivered via the Deliver or Get-Ok - methods. The client can ask to confirm a single message or a set of messages up to - and including a specific message. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "multiple" domain = "bit" label = "acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the - client can acknowledge multiple messages with a single method. If set to zero, - the delivery tag refers to a single message. If the multiple field is 1, and the - delivery tag is zero, tells the server to acknowledge all outstanding messages. - </doc> - - <!-- Rule test name: was "amq_basic_20" --> - <rule name = "01"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered - message, and raise a channel exception if this is not the case. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "reject" index = "90" label = "reject an incoming message"> - <doc> - This method allows a client to reject a message. It can be used to interrupt and - cancel large incoming messages, or return untreatable messages to their original - queue. - </doc> - - <!-- Rule test name: was "amq_basic_21" --> - <rule name = "01"> - <doc> - The server SHOULD be capable of accepting and process the Reject method while - sending message content with a Deliver or Get-Ok method. I.e. the server should - read and process incoming methods while sending output frames. To cancel a - partially-send content, the server sends a content body frame of size 1 (i.e. - with no data except the frame-end octet). - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_22" --> - <rule name = "02"> - <doc> - The server SHOULD interpret this method as meaning that the client is unable to - process the message at this time. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <rule name = "03"> - <!-- TODO: Rule split? --> - <doc> - A client MUST NOT use this method as a means of selecting messages to process. A - rejected message MAY be discarded or dead-lettered, not necessarily passed to - another client. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the - server will attempt to requeue the message. - </doc> - - <!-- Rule test name: was "amq_basic_23" --> - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MUST NOT deliver the message to the same client within the - context of the current channel. The recommended strategy is to attempt to - deliver the message to an alternative consumer, and if that is not possible, - to move the message to a dead-letter queue. The server MAY use more - sophisticated tracking to hold the message on the queue and redeliver it to - the same client at a later stage. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - </method> - - <method name = "recover" index = "100" label = "redeliver unacknowledged messages"> - <doc> - This method asks the broker to redeliver all unacknowledged messages on a specified - channel. Zero or more messages may be redelivered. This method is only allowed on - non-transacted channels. - </doc> - - <rule name = "01"> - <doc> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <rule name = "02"> - <doc> - The server MUST raise a channel exception if this is called on a transacted - channel. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the message, - potentially then delivering it to an alternative subscriber. - </doc> - </field> - </method> - - - <!-- RG : Added recover-sync and recover-sync-ok to give a synchronous recover without interfering with the correct 0-9 recover method --> - <method name = "recover-sync" index = "102"> - redeliver unacknowledged messages - <doc> - This method asks the broker to redeliver all unacknowledged messages on a - specified channel. Zero or more messages may be redelivered. This method - is only allowed on non-transacted channels. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the - message, potentially then delivering it to an alternative subscriber. - </doc> - </field> - <doc name="rule"> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - <doc name="rule"> - The server MUST raise a channel exception if this is called on a - transacted channel. - </doc> - <response name="recover-sync-ok"/> - </method> - <method name="recover-sync-ok" synchronous="1" index="101"> - confirm a successful recover - <doc> - This method confirms to the client that the recover succeeded. - Note that if an recover fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - - - </class> - - <!-- == FILE ============================================================= --> - - <class name = "file" handler = "channel" index = "70" label = "work with file content"> - <doc> - The file class provides methods that support reliable file transfer. File - messages have a specific set of properties that are required for interoperability - with file transfer applications. File messages and acknowledgements are subject to - channel transactions. Note that the file class does not provide message browsing - methods; these are not compatible with the staging model. Applications that need - browsable file transfer should use Basic content and the Basic class. - </doc> - - <doc type = "grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <rule name = "01"> - <doc> - The server MUST make a best-effort to hold file messages on a reliable storage - mechanism. - </doc> - </rule> - - <!-- TODO Rule implement attr inverse? --> - - <!-- TODO: Rule split? --> - - <rule name = "02"> - <doc> - The server MUST NOT discard a file message in case of a queue overflow. The server - MUST use the Channel.Flow method to slow or stop a file message publisher when - necessary. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <rule name = "03"> - <doc> - The server MUST implement at least 2 priority levels for file messages, where - priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement - up to 10 priority levels. - </doc> - </rule> - - <rule name = "04"> - <doc> - The server MUST support both automatic and explicit acknowledgements on file - content. - </doc> - </rule> - - <!-- These are the properties for a File content --> - - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "reply-to" domain = "shortstr" label = "destination to reply to" /> - <field name = "message-id" domain = "shortstr" label = "application message identifier" /> - <field name = "filename" domain = "shortstr" label = "message filename" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp" /> - <!-- This field is deprecated pending review --> - <field name = "cluster-id" domain = "shortstr" label = "intra-cluster routing identifier" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <response name = "qos-ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. May be set - to zero, meaning "no specific limit". Note that other prefetch limits may still - apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This is compatible with - some file API implementations. This field may be used in combination with the - prefetch-size field; a message will only be sent in advance if both prefetch - windows (and those at the channel and connection level) allow it. The - prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MAY send less data in advance than allowed by the client's - specified prefetch windows but it MUST NOT send more. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the - server. The requested QoS applies to all active consumers until a new QoS is - defined. - </doc> - - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was - declared as private, and ideally, impose no limit except as defined by available - resources. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a - connection, so two clients can use the same consumer tags. If this field is - empty the server will generate a unique tag. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to - create two consumers with the same non-empty tag the server MUST raise a - connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "no-ack" domain = "no-ack" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel exception - with return code 405 (resource locked). - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "filter" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer"> - <doc> - This method provides the client with a consumer tag which it MUST use in methods - that work with the consumer. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc>Holds the consumer tag specified by the client or provided by the server.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer"> - <doc> - This method cancels a consumer. This does not affect already delivered messages, but - it does mean the server will not send any more messages for that consumer. - </doc> - - <response name = "cancel-ok" /> - - <chassis name = "server" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer"> - <doc>This method confirms that the cancellation was completed.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" synchronous = "1" index = "40" label = "request to start staging"> - <doc> - This method requests permission to start staging a message. Staging means sending - the message into a temporary area at the recipient end and then delivering the - message by referring to this temporary area. Staging is how the protocol handles - partial file transfers - if a message is partially staged and the connection breaks, - the next time the sender starts to stage it, it can restart from where it left off. - </doc> - - <response name = "open-ok" /> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "identifier" domain = "shortstr" label = "staging identifier"> - <doc> - This is the staging identifier. This is an arbitrary string chosen by the - sender. For staging to work correctly the sender must use the same staging - identifier when staging the same message a second time after recovery from a - failure. A good choice for the staging identifier would be the SHA1 hash of the - message properties data (including the original filename, revised time, etc.). - </doc> - </field> - - <field name = "content-size" domain = "longlong" label = "message content size"> - <doc> - The size of the content in octets. The recipient may use this information to - allocate or check available space in advance, to avoid "disk full" errors during - staging of very large messages. - </doc> - - <rule name = "01"> - <doc> - The sender MUST accurately fill the content-size field. Zero-length content - is permitted. - </doc> - </rule> - </field> - </method> - - <method name = "open-ok" synchronous = "1" index = "41" label = "confirm staging ready"> - <doc> - This method confirms that the recipient is ready to accept staged data. If the - message was already partially-staged at a previous time the recipient will report - the number of octets already staged. - </doc> - - <response name = "stage" /> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "staged-size" domain = "longlong" label = "already staged amount"> - <doc> - The amount of previously-staged content in octets. For a new message this will - be zero. - </doc> - - <rule name = "01"> - <doc> - The sender MUST start sending data from this octet offset in the message, - counting from zero. - </doc> - </rule> - - <rule name = "02"> - <!-- TODO: Rule split? --> - <doc> - The recipient MAY decide how long to hold partially-staged content and MAY - implement staging by always discarding partially-staged content. However if - it uses the file content type it MUST support the staging methods. - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "stage" content = "1" index = "50" label = "stage message content"> - <doc> - This method stages the message, sending the message content to the recipient from - the octet offset specified in the Open-Ok method. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "publish" index = "60" label = "publish a message"> - <doc> - This method publishes a staged file message to a specific exchange. The file message - will be routed to queues as defined by the exchange configuration and distributed to - any active consumers when the transaction, if any, is committed. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be - empty, meaning the default exchange. If the exchange name is specified, and that - exchange does not exist, the server will raise a channel exception. - </doc> - - <rule name = "01"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name = "02"> - <doc> - If the exchange was declared as an internal exchange, the server MUST - respond with a reply code 403 (access refused) and raise a channel - exception. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <rule name = "03"> - <doc> - The exchange MAY refuse file content in which case it MUST respond with a - reply code 540 (not implemented) and raise a channel exception. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing - messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" domain = "bit" label = "indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue. If this flag is set, the server will return an unroutable message with a - Return method. If this flag is zero, the server silently drops the message. - </doc> - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the mandatory flag.</doc> - </rule> - </field> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue consumer immediately. If this flag is set, the server will return an - undeliverable message with a Return method. If this flag is zero, the server - will queue the message, but with no guarantee that it will ever be consumed. - </doc> - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the immediate flag.</doc> - </rule> - </field> - - <field name = "identifier" domain = "shortstr" label = "staging identifier"> - <doc> - This is the staging identifier of the message to publish. The message must have - been staged. Note that a client can send the Publish method asynchronously - without waiting for staging to finish. - </doc> - </field> - </method> - - <method name = "return" content = "1" index = "70" label = "return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" - flag set, or an unroutable message published with the "mandatory" flag set. The - reply code and text provide information about the reason that the message was - undeliverable. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "reply-code" domain = "reply-code" /> - - <field name = "reply-text" domain = "reply-text" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "deliver" index = "80" label = "notify the client of a consumer message"> - <doc> - This method delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the Consume - method, then the server responds with Deliver methods as and when messages arrive - for that consumer. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server SHOULD track the number of times a message has been delivered to - clients and when a message is redelivered a certain number of times - e.g. 5 - times - without being acknowledged, the server SHOULD consider the message to be - unprocessable (possibly causing client applications to abort), and move the - message to a dead letter queue. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - - <field name = "identifier" domain = "shortstr" label = "staging identifier"> - <doc> - This is the staging identifier of the message to deliver. The message must have - been staged. Note that a server can send the Deliver method asynchronously - without waiting for staging to finish. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "ack" index = "90" label = "acknowledge one or more messages"> - <doc> - This method acknowledges one or more messages delivered via the Deliver method. The - client can ask to confirm a single message or a set of messages up to and including - a specific message. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "multiple" domain = "bit" label = "acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the - client can acknowledge multiple messages with a single method. If set to zero, - the delivery tag refers to a single message. If the multiple field is 1, and the - delivery tag is zero, tells the server to acknowledge all outstanding messages. - </doc> - - <rule name = "01"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered - message, and raise a channel exception if this is not the case. - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "reject" index = "100" label = "reject an incoming message"> - <doc> - This method allows a client to reject a message. It can be used to return - untreatable messages to their original queue. Note that file content is staged - before delivery, so the client will not use this method to interrupt delivery of a - large message. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD interpret this method as meaning that the client is unable to - process the message at this time. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <rule name = "02"> - <doc> - A client MUST NOT use this method as a means of selecting messages to process. A - rejected message MAY be discarded or dead-lettered, not necessarily passed to - another client. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the - server will attempt to requeue the message. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MUST NOT deliver the message to the same client within the - context of the current channel. The recommended strategy is to attempt to - deliver the message to an alternative consumer, and if that is not possible, - to move the message to a dead-letter queue. The server MAY use more - sophisticated tracking to hold the message on the queue and redeliver it to - the same client at a later stage. - </doc> - </rule> - </field> - </method> - </class> - - <!-- == STREAM =========================================================== --> - - <class name = "stream" handler = "channel" index = "80" label = "work with streaming content"> - <doc> - The stream class provides methods that support multimedia streaming. The stream class - uses the following semantics: one message is one packet of data; delivery is - unacknowledged and unreliable; the consumer can specify quality of service parameters - that the server can try to adhere to; lower-priority messages may be discarded in favour - of high priority messages. - </doc> - - <doc type = "grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <rule name = "01"> - <doc> - The server SHOULD discard stream messages on a priority basis if the queue size - exceeds some configured limit. - </doc> - </rule> - - <rule name = "02"> - <!-- TODO: Rule split? --> - <doc> - The server MUST implement at least 2 priority levels for stream messages, where - priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement - up to 10 priority levels. - </doc> - </rule> - - <rule name = "03"> - <doc> - The server MUST implement automatic acknowledgements on stream content. That is, as - soon as a message is delivered to a client via a Deliver method, the server must - remove it from the queue. - </doc> - </rule> - - <!-- These are the properties for a Stream content --> - - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <response name = "qos-ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. May be set - to zero, meaning "no specific limit". Note that other prefetch limits may still - apply. - </doc> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used - in combination with the prefetch-size field; a message will only be sent in - advance if both prefetch windows (and those at the channel and connection level) - allow it. - </doc> - </field> - - <field name = "consume-rate" domain = "long" label = "transfer rate in octets/second"> - <doc> - Specifies a desired transfer rate in octets per second. This is usually - determined by the application that uses the streaming data. A value of zero - means "no limit", i.e. as rapidly as possible. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MAY ignore the prefetch values and consume rates, depending on - the type of stream and the ability of the server to queue and/or reply it. - The server MAY drop low-priority messages in favour of high-priority - messages. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the - server. The requested QoS applies to all active consumers until a new QoS is - defined. - </doc> - - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was - declared as private, and ideally, impose no limit except as defined by available - resources. - </doc> - </rule> - - <rule name = "02"> - <doc> - Streaming applications SHOULD use different channels to select different - streaming resolutions. AMQP makes no provision for filtering and/or transforming - streams except on the basis of priority-based selective delivery of individual - messages. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a - connection, so two clients can use the same consumer tags. If this field is - empty the server will generate a unique tag. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to - create two consumers with the same non-empty tag the server MUST raise a - connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel exception - with return code 405 (resource locked). - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "filter" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer"> - <doc> - This method provides the client with a consumer tag which it may use in methods that - work with the consumer. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc>Holds the consumer tag specified by the client or provided by the server.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer"> - <doc> - This method cancels a consumer. Since message delivery is asynchronous the client - may continue to receive messages for a short while after cancelling a consumer. It - may process or discard these as appropriate. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <response name = "cancel-ok" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer"> - <doc>This method confirms that the cancellation was completed.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "publish" content = "1" index = "40" label = "publish a message"> - <doc> - This method publishes a message to a specific exchange. The message will be routed - to queues as defined by the exchange configuration and distributed to any active - consumers as appropriate. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be - empty, meaning the default exchange. If the exchange name is specified, and that - exchange does not exist, the server will raise a channel exception. - </doc> - - <rule name = "01"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name = "02"> - <doc> - If the exchange was declared as an internal exchange, the server MUST - respond with a reply code 403 (access refused) and raise a channel - exception. - </doc> - </rule> - - <rule name = "03"> - <doc> - The exchange MAY refuse stream content in which case it MUST respond with a - reply code 540 (not implemented) and raise a channel exception. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing - messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" domain = "bit" label = "indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue. If this flag is set, the server will return an unroutable message with a - Return method. If this flag is zero, the server silently drops the message. - </doc> - - <!-- Rule test name: was "amq_stream_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the mandatory flag.</doc> - </rule> - </field> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue consumer immediately. If this flag is set, the server will return an - undeliverable message with a Return method. If this flag is zero, the server - will queue the message, but with no guarantee that it will ever be consumed. - </doc> - - <!-- Rule test name: was "amq_stream_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the immediate flag.</doc> - </rule> - </field> - </method> - - <method name = "return" content = "1" index = "50" label = "return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" - flag set, or an unroutable message published with the "mandatory" flag set. The - reply code and text provide information about the reason that the message was - undeliverable. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "reply-code" domain = "reply-code" /> - - <field name = "reply-text" domain = "reply-text" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "deliver" content = "1" index = "60" - label = "notify the client of a consumer message"> - <doc> - This method delivers a message to the client, via a consumer. In the asynchronous - message delivery model, the client starts a consumer using the Consume method, then - the server responds with Deliver methods as and when messages arrive for that - consumer. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue that the message came from. Note that a single - channel can start many consumers on different queues. - </doc> - <assert check = "notnull" /> - </field> - </method> - </class> - - <!-- == TX =============================================================== --> - - <class name = "tx" handler = "channel" index = "90" label = "work with standard transactions"> - <doc> - Standard transactions provide so-called "1.5 phase commit". We can ensure that work is - never lost, but there is a chance of confirmations being lost, so that messages may be - resent. Applications that use standard transactions must be able to detect and ignore - duplicate messages. - </doc> - - <!-- TODO: Rule split? --> - - <rule name = "01"> - <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> - - <doc type = "grammar"> - tx = C:SELECT S:SELECT-OK - / C:COMMIT S:COMMIT-OK - / C:ROLLBACK S:ROLLBACK-OK - </doc> - - <chassis name = "server" implement = "SHOULD" /> - <chassis name = "client" implement = "MAY" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "select" synchronous = "1" index = "10" label = "select standard transaction mode"> - <doc> - This method sets the channel to use standard transactions. The client must use this - method at least once on a channel before using the Commit or Rollback methods. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "select-ok" /> - </method> - - <method name = "select-ok" synchronous = "1" index = "11" label = "confirm transaction mode"> - <doc> - This method confirms to the client that the channel was successfully set to use - standard transactions. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "commit" synchronous = "1" index = "20" label = "commit the current transaction"> - <doc> - This method commits all messages published and acknowledged in the current - transaction. A new transaction starts immediately after a commit. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "commit-ok" /> - </method> - - <method name = "commit-ok" synchronous = "1" index = "21" label = "confirm a successful commit"> - <doc> - This method confirms to the client that the commit succeeded. Note that if a commit - fails, the server raises a channel exception. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "rollback" synchronous = "1" index = "30" - label = "abandon the current transaction"> - <doc> - This method abandons all messages published and acknowledged in the current - transaction. A new transaction starts immediately after a rollback. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "rollback-ok" /> - </method> - - <method name = "rollback-ok" synchronous = "1" index = "31" label = "confirm successful rollback"> - <doc> - This method confirms to the client that the rollback succeeded. Note that if an - rollback fails, the server raises a channel exception. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - </class> - - <!-- == DTX ============================================================== --> - - <class name = "dtx" handler = "channel" index = "100" label = "work with distributed transactions"> - <doc> - Distributed transactions provide so-called "2-phase commit". The AMQP distributed - transaction model supports the X-Open XA architecture and other distributed transaction - implementations. The Dtx class assumes that the server has a private communications - channel (not AMQP) to a distributed transaction coordinator. - </doc> - - <doc type = "grammar"> - dtx = C:SELECT S:SELECT-OK - C:START S:START-OK - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "select" synchronous = "1" index = "10" label = "select standard transaction mode"> - <doc> - This method sets the channel to use distributed transactions. The client must use - this method at least once on a channel before using the Start method. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "select-ok" /> - </method> - - <method name = "select-ok" synchronous = "1" index = "11" label = "confirm transaction mode"> - <doc> - This method confirms to the client that the channel was successfully set to use - distributed transactions. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "start" synchronous = "1" index = "20" - label = "start a new distributed transaction"> - <doc> - This method starts a new distributed transaction. This must be the first method on a - new channel that uses the distributed transaction mode, before any methods that - publish or consume messages. - </doc> - <chassis name = "server" implement = "MAY" /> - <response name = "start-ok" /> - <field name = "dtx-identifier" domain = "shortstr" label = "transaction identifier"> - <doc> - The distributed transaction key. This identifies the transaction so that the - AMQP server can coordinate with the distributed transaction coordinator. - </doc> - <assert check = "notnull" /> - </field> - </method> - - <method name = "start-ok" synchronous = "1" index = "21" - label = "confirm the start of a new distributed transaction"> - <doc> - This method confirms to the client that the transaction started. Note that if a - start fails, the server raises a channel exception. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - </class> - - <!-- == TUNNEL =========================================================== --> - - <class name = "tunnel" handler = "tunnel" index = "110" label = "methods for protocol tunnelling"> - <doc> - The tunnel methods are used to send blocks of binary data - which can be serialised AMQP - methods or other protocol frames - between AMQP peers. - </doc> - - <doc type = "grammar"> - tunnel = C:REQUEST - / S:REQUEST - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "proxy-name" domain = "shortstr" label = "identity of tunnelling proxy" /> - <field name = "data-name" domain = "shortstr" label = "name or type of message being tunnelled" /> - <field name = "durable" domain = "octet" label = "message durability indicator" /> - <field name = "broadcast" domain = "octet" label = "message broadcast mode" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "request" content = "1" index = "10" label = "sends a tunnelled method"> - <doc> - This method tunnels a block of binary data, which can be an encoded - AMQP method or other data. The binary data is sent as the content for - the Tunnel.Request method. - </doc> - <chassis name = "server" implement = "MUST" /> - <field name = "meta-data" domain = "table" label = "meta data for the tunnelled block"> - <doc> - This field table holds arbitrary meta-data that the sender needs to - pass to the recipient. - </doc> - </field> - </method> - </class> - - <!-- == MESSAGE ============================================================ --> - - <class name = "message" index = "120" handler = "channel" label = "[WORK IN PROGRESS] message transfer"> - <doc> - [WORK IN PROGRESS] The message class provides methods that support an industry-standard messaging model. - </doc> - - <doc type = "grammar"> - message = C:QOS S:OK - / C:CONSUME S:OK - / C:CANCEL S:OK - / C:TRANSFER ( S:OK / S:REJECT ) - / S:TRANSFER ( C:OK / C:REJECT ) - / C:GET ( S:OK / S:EMPTY ) - / C:RECOVER S:OK - / C:OPEN S:OK - / S:OPEN C:OK - / C:APPEND S:OK - / S:APPEND C:OK - / C:CLOSE S:OK - / S:CLOSE C:OK - / C:CHECKPOINT S:OK - / S:CHECKPOINT C:OK - / C:RESUME S:OFFSET - / S:RESUME C:OFFSET - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <rule name = "01"> - <doc> - The server SHOULD respect the persistent property of messages - and SHOULD make a best-effort to hold persistent mess ages on - a reliable storage mechanism. - </doc> - <doc type = "scenario"> - Send a persistent message to queue, stop server, restart - server and then verify whether message is still present. - Assumes that queues are durable. Persistence without durable - queues makes no sense. - </doc> - </rule> - - <rule name = "02"> - <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 = "03"> - <doc> - The server MAY use the Channel.Flow method to slow or stop a - message publisher when necessary. - </doc> - <doc type = "scenario"> - Create a queue overflow situation with non-persistent messages - and verify whether the server responds with Channel.Flow or - not. Repeat with persistent messages. - </doc> - </rule> - - <rule name = "04"> - <doc> - The server MAY overflow non-persistent messages to persistent - storage. - </doc> - </rule> - - <rule name = "05"> - <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 = "06"> - <doc> - The server MUST implement at least 2 priority levels for - messages, where priorities 0-4 and 5-9 are treated as two - distinct levels. - </doc> - <doc type = "scenario"> - Send a number of priority 0 messages to a queue. Send one - priority 9 message. Consume messages from the queue and verify - that the first message received was priority 9. - </doc> - </rule> - - <rule name = "07"> - <doc> - The server MAY implement up to 10 priority levels. - </doc> - <doc type = "scenario"> - Send a number of messages with mixed priorities to a queue, so - that all priority values from 0 to 9 are exercised. A good - scenario would be ten messages in low-to-high priority. - Consume from queue and verify how many priority levels emerge. - </doc> - </rule> - - <rule name = "08"> - <doc> - The server MUST deliver messages of the same priority in order - irrespective of their individual persistence. - </doc> - <doc type = "scenario"> - Send a set of messages with the same priority but different - persistence settings to a queue. Consume and verify that - messages arrive in same order as originally published. - </doc> - </rule> - - <rule name = "09"> - <doc> - The server MUST support automatic acknowledgements on - messages, i.e. consumers with the no-ack field set to FALSE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using automatic - acknowledgements. Publish a set of messages to the queue. - Consume the messages and verify that all messages are - received. - </doc> - </rule> - - <rule name = "10"> - <doc> - The server MUST support explicit acknowledgements on messages, - i.e. consumers with the no-ack field set to TRUE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using explicit acknowledgements. - Publish a set of messages to the queue. Consume the messages - but acknowledge only half of them. Disconnect and reconnect, - and consume from the queue. Verify that the remaining messages - are received. - </doc> - </rule> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "transfer" index = "10" label = "[WORK IN PROGRESS] transfer a message"> - <doc> - [WORK IN PROGRESS] This method transfers a message between two peers. When a - client uses this method to publish a message to a broker, the - destination identifies a specific exchange. The message will - then be routed to queues as defined by the exchange - configuration and distributed to any active consumers when the - transaction, if any, is committed. - - In the asynchronous message delivery model, the client starts - a consumer using the Consume method and passing in a - destination, then the broker responds with transfer methods to - the specified destination as and when messages arrive for that - consumer. - - If synchronous message delivery is required, the client may - issue a get request which on success causes a single message - to be transferred to the specified destination. - - Message acknowledgement is signalled by the return result of - this method. - </doc> - - <rule name = "01"> - <doc> - The recipient MUST NOT return ok before the message has been - processed as defined by the QoS settings. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - <response name = "reject" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - </rule> - </field> - - <field name = "destination" domain = "destination"> - <doc> - Specifies the destination to which the message is to be - transferred. The destination can be empty, meaning the - default exchange or consumer. If the destination is - specified, and that exchange or consumer does not exist, the - peer must raise a channel exception. - </doc> - - <rule name = "01"> - <doc> - The server MUST accept a blank destination to mean the - default exchange. - </doc> - </rule> - - <rule name = "02"> - <doc> - If the destination refers to an internal exchange, the - server MUST raise a channel exception with a reply code - 403 (access refused). - </doc> - </rule> - - <rule name = "03"> - <doc> - A destination MAY refuse message content in which case it - MUST raise a channel exception with reply code 540 (not - implemented). - </doc> - </rule> - </field> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message - cannot be routed to a queue consumer immediately. If this - flag is set, the server will reject the message. If this - flag is zero, the server will queue the message, but with no - guarantee that it will ever be consumed. - </doc> - <rule name = "01"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <field name = "ttl" domain = "duration" label = "time to live"> - <doc> - If this is set to a non zero value then a message expiration - time will be computed based on the current time plus this - value. Messages that live longer than their expiration time - will be discarded (or dead lettered). - </doc> - <rule name = "01"> - <doc> - If a message is transfered between brokers before delivery - to a final consumer the ttl should be decremented before - peer to peer transfer and both timestamp and expiration - should be cleared. - </doc> - </rule> - </field> - - <!-- begin headers --> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp"> - <doc> - Set on arrival by the broker. - </doc> - </field> - <field name = "delivery-mode" domain = "octet" label = "non-persistent (1) or persistent (2)" /> - <field name = "expiration" domain = "timestamp" label = "message expiration time"> - <doc> - The expiration header assigned by the broker. After - receiving the message the broker sets expiration to the sum - of the ttl specified in the publish method and the current - time. (ttl = expiration - timestamp) - </doc> - </field> - <field name = "exchange" domain = "exchange-name" label = "originating exchange" /> - <field name = "routing-key" domain = "shortstr" label = "message routing key" /> - <field name = "message-id" domain = "shortstr" label = "application message identifier" /> - <field name = "correlation-id" domain = "shortstr" label = "application correlation identifier" /> - <field name = "reply-to" domain = "shortstr" label = "destination to reply to" /> - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "user-id" domain = "shortstr" label = "creating user id" /> - <field name = "app-id" domain = "shortstr" label = "creating application id" /> - <field name = "transaction-id" domain = "shortstr" label = "distributed transaction id" /> - <field name = "security-token" domain = "security-token" /> - <field name = "application-headers" domain = "table" label = "application specific headers table" /> - <!-- end headers --> - - <field name = "body" domain = "content" label = "message body" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" index = "20" label = "[WORK IN PROGRESS] start a queue consumer"> - <doc> - [WORK IN PROGRESS] This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, and ideally, impose - no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - Create a queue and create consumers on that queue until the server closes the - connection. Verify that the number of consumers created was at least sixteen - and report the total number. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an invalid (non-zero) access ticket. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - If the queue name is empty the client MUST have previously declared a - queue using this channel. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an empty queue name and no previously - declared queue on the channel. - </doc> - </rule> - </field> - - <field name = "destination" domain = "destination" label = "incoming message destination"> - <doc> - Specifies the destination for the consumer. The destination is local to a - connection, so two clients can use the same destination. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - The client MUST NOT specify a destination that refers to an existing consumer. - </doc> - <doc type = "scenario"> - Attempt to create two consumers with the same non-empty destination. - </doc> - </rule> - <rule name = "02" on-failure = "not-allowed"> - <doc> - The destination is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in one - channel and then use it in another. - </doc> - <doc type = "scenario"> - Attempt to create a consumer in one channel, then use in another channel, - in which consumers have also been created (to test that the server uses - unique destinations). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "no-ack" domain = "no-ack" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MAY NOT gain exclusive access to a queue that already has - active consumers. - </doc> - <doc type = "scenario"> - Open two connections to a server, and in one connection create a shared - (non-exclusive) queue and then consume from the queue. In the second - connection attempt to consume from the same queue using the exclusive - option. - </doc> - </rule> - </field> - - <field name = "filter" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" index = "30" label = "[WORK IN PROGRESS] end a queue consumer"> - <doc> - [WORK IN PROGRESS] This method cancels a consumer. This does not affect already delivered - messages, but it does mean the server will not send any more messages for - that consumer. The client may receive an arbitrary number of messages in - between sending the cancel method and receiving the cancel-ok reply. - </doc> - - <rule name = "01"> - <doc> - If the queue does not exist the server MUST ignore the cancel method, so - long as the consumer tag is valid for that channel. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "destination" domain = "destination"/> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "get" index = "40" label = "[WORK IN PROGRESS] direct access to a queue"> - <doc> - [WORK IN PROGRESS] This method provides a direct access to the messages in a queue using a synchronous - dialogue that is designed for specific types of application where synchronous - functionality is more important than performance. - </doc> - - <response name = "ok" /> - <response name = "empty" /> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - </rule> - </field> - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "destination" domain = "destination"> - <doc> - On normal completion of the get request (i.e. a response of - ok). A message will be transferred to the supplied destination. - </doc> - </field> - - <field name = "no-ack" domain = "no-ack" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "recover" index = "50" label = "[WORK IN PROGRESS] redeliver unacknowledged messages"> - <doc> - [WORK IN PROGRESS] This method asks the broker to redeliver all unacknowledged - messages on a specified channel. Zero or more messages may be - redelivered. This method is only allowed on non-transacted - channels. - </doc> - - <rule name = "01"> - <doc> - The server MUST set the redelivered flag on all messages - that are resent. - </doc> - </rule> - - <rule name = "02"> - <doc> - The server MUST raise a channel exception if this is called - on a transacted channel. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be redelivered to - the original recipient. If this bit is 1, the server will - attempt to requeue the message, potentially then delivering - it to an alternative subscriber. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" index = "60" label = "[WORK IN PROGRESS] create a reference to an empty message body"> - <doc> - [WORK IN PROGRESS] This method creates a reference. A references provides a means - to send a message body into a temporary area at the recipient - end and then deliver the message by referring to this - temporary area. This is how the protocol handles large message - transfers. - - The scope of a ref is defined to be between calls to - open (or resume) and close. Between these points it is valid - for a ref to be used from any content data type, and so the - receiver must hold onto its contents. Should the channel be - closed when a ref is still in scope, the receiver may discard - its contents (unless it is checkpointed). A ref that is in - scope is considered open. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - - <field name = "reference" domain = "reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - currently open (in scope). - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "close" index = "70" label = "[WORK IN PROGRESS] close a reference"> - <doc> - [WORK IN PROGRESS] This method signals the recipient that no more data will be - appended to the reference. - </doc> - - <rule name = "01"> - <doc> - A recipient CANNOT acknowledge a message until its reference - is closed (not in scope). - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <response name = "ok" /> - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference was - not previously open (in scope). - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "append" index = "80" label = "[WORK IN PROGRESS] append to a reference"> - <doc> - [WORK IN PROGRESS] This method appends data to a reference. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - not open (not in scope). - </doc> - </rule> - </field> - <field name = "bytes" domain = "longstr" label = "data to append" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "checkpoint" index = "90" label = "[WORK IN PROGRESS] checkpoint a message body"> - <doc> - [WORK IN PROGRESS] This method provides a means to checkpoint large message - transfer. The sender may ask the recipient to checkpoint the - contents of a reference using the supplied identifier. The - sender may then resume the transfer at a later point. It is at - the discretion of the recipient how much data to save with the - checkpoint, and the sender MUST honour the offset returned by - the resume method. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - not open (not in scope). - </doc> - </rule> - </field> - <field name = "identifier" domain = "shortstr" label = "checkpoint identifier"> - <doc> - This is the checkpoint identifier. This is an arbitrary - string chosen by the sender. For checkpointing to work - correctly the sender must use the same checkpoint identifier - when resuming the message. A good choice for the checkpoint - identifier would be the SHA1 hash of the message properties - data (including the original filename, revised time, etc.). - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "resume" index = "100" label = "[WORK IN PROGRESS] open and resume a checkpointed message"> - <doc> - [WORK IN PROGRESS] This method resumes a reference from the last checkpoint. A - reference is considered to be open (in scope) after a resume - even though it will not have been opened via the open method - during this session. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "offset" /> - - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - currently open (in scope). - </doc> - </rule> - </field> - <field name = "identifier" domain = "shortstr" label = "checkpoint identifier" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" index = "110" label = "[WORK IN PROGRESS] specify quality of service"> - <doc> - [WORK IN PROGRESS] This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. The server - will send a message in advance if it is equal to or smaller in size than the - available prefetch size (and also falls into other prefetch limits). May be set - to zero, meaning "no specific limit", although other prefetch limits may still - apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - <rule name = "01"> - <doc> - The server MUST ignore this setting when the client is not processing any - messages - i.e. the prefetch size does not limit the transfer of single - messages to a client, only the sending in advance of more messages while - the client still has one or more unacknowledged messages. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and send a single message that exceeds - that limit. Verify that the message arrives correctly. - </doc> - </rule> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used - in combination with the prefetch-size field; a message will only be sent in - advance if both prefetch windows (and those at the channel and connection level) - allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - <rule name = "01"> - <doc> - The server may send less data in advance than allowed by the client's - specified prefetch windows but it MUST NOT send more. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and a prefetch-count limit greater than - one. Send multiple messages that exceed the prefetch size. Verify that - no more than one message arrives at once. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <!-- === Responses === --> - - <method name = "ok" index = "500" label = "[WORK IN PROGRESS] normal completion"> - <doc> - [WORK IN PROGRESS] Signals the normal completion of a method. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "empty" index = "510" label = "[WORK IN PROGRESS] empty queue"> - <doc> - [WORK IN PROGRESS] Signals that a queue does not contain any messages. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "reject" index = "520" label = "[WORK IN PROGRESS] reject a message"> - <doc> - [WORK IN PROGRESS] This response rejects a message. A message may be rejected for - a number of reasons. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <field name = "code" domain = "reject-code" /> - <field name = "text" domain = "reject-text" /> - </method> - - <method name = "offset" index = "530" label = "[WORK IN PROGRESS] return an offset"> - <doc> - [WORK IN PROGRESS] Returns the data offset into a reference body. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <field name = "value" domain = "offset" label = "offset into a reference body" /> - </method> - - </class> - -</amqp> diff --git a/qpid/python/qpid/specs_config.py b/qpid/python/qpid/specs_config.py index 58021320f6..d991e8b084 100644 --- a/qpid/python/qpid/specs_config.py +++ b/qpid/python/qpid/specs_config.py @@ -20,6 +20,7 @@ import os AMQP_SPEC_DIR=os.path.join(os.path.dirname(os.path.abspath(__file__)), "specs") -amqp_spec = os.path.join(AMQP_SPEC_DIR, "amqp-0-10-qpid-errata.xml") -amqp_spec_0_8 = os.path.join(AMQP_SPEC_DIR, "amqp-0-8.xml") -amqp_spec_0_9 = os.path.join(AMQP_SPEC_DIR, "amqp-0-9.xml") +amqp_spec = os.path.join(AMQP_SPEC_DIR, "amqp-0-10-qpid-errata-stripped.xml") +amqp_spec_0_8 = os.path.join(AMQP_SPEC_DIR, "amqp-0-8-qpid-stripped.xml") +amqp_spec_0_9 = os.path.join(AMQP_SPEC_DIR, "amqp-0-9-qpid-stripped.xml") +amqp_spec_0_9_1 = os.path.join(AMQP_SPEC_DIR, "amqp-0-9-1-stripped.xml") diff --git a/qpid/python/setup.py b/qpid/python/setup.py index 10e3e3417e..8daa9c807c 100755 --- a/qpid/python/setup.py +++ b/qpid/python/setup.py @@ -279,7 +279,7 @@ class install_lib(_install_lib): outputs = _install_lib.get_outputs(self) extra = [] for of in outputs: - if os.path.basename(of) == "amqp-0-10-qpid-errata.xml": + if os.path.basename(of) == "amqp-0-10-qpid-errata-stripped.xml": extra.append(pclfile(of)) return outputs + extra @@ -287,7 +287,7 @@ class install_lib(_install_lib): outfiles = _install_lib.install(self) extra = [] for of in outfiles: - if os.path.basename(of) == "amqp-0-10-qpid-errata.xml": + if os.path.basename(of) == "amqp-0-10-qpid-errata-stripped.xml": tgt = pclfile(of) if self.force or newer(of, tgt): log.info("caching %s to %s" % (of, os.path.basename(tgt))) diff --git a/qpid/specs/LICENSE b/qpid/specs/LICENSE index f8c0d5d1ba..d645695673 100644 --- a/qpid/specs/LICENSE +++ b/qpid/specs/LICENSE @@ -1,6 +1,3 @@ -========================================================================= -== Apache License == -========================================================================= Apache License Version 2.0, January 2004 @@ -203,123 +200,3 @@ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -========================================================================= -== AMQP License == -========================================================================= -Copyright Notice - ================ - (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., - iMatix Corporation, IONA\ufffd Technologies, Red Hat, Inc., - TWIST Process Innovations, and 29West Inc. 2006. All rights reserved. - - License - ======= - JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix - Corporation, IONA Technologies, Red Hat, Inc., TWIST Process Innovations, and - 29West Inc. (collectively, the "Authors") each hereby grants to you a worldwide, - perpetual, royalty-free, nontransferable, nonexclusive license to - (i) copy, display, distribute and implement the Advanced Messaging Queue Protocol - ("AMQP") Specification and (ii) the Licensed Claims that are held by - the Authors, all for the purpose of implementing the Advanced Messaging - Queue Protocol Specification. Your license and any rights under this - Agreement will terminate immediately without notice from - any Author if you bring any claim, suit, demand, or action related to - the Advanced Messaging Queue Protocol Specification against any Author. - Upon termination, you shall destroy all copies of the Advanced Messaging - Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or - patent application, throughout the world, excluding design patents and - design registrations, owned or controlled, or that can be sublicensed - without fee and in compliance with the requirements of this - Agreement, by an Author or its affiliates now or at any - future time and which would necessarily be infringed by implementation - of the Advanced Messaging Queue Protocol Specification. A claim is - necessarily infringed hereunder only when it is not possible to avoid - infringing it because there is no plausible non-infringing alternative - for implementing the required portions of the Advanced Messaging Queue - Protocol Specification. Notwithstanding the foregoing, Licensed Claims - shall not include any claims other than as set forth above even if - contained in the same patent as Licensed Claims; or that read solely - on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging - Queue Protocol Specification, or that, if licensed, would require a - payment of royalties by the licensor to unaffiliated third parties. - Moreover, Licensed Claims shall not include (i) any enabling technologies - that may be necessary to make or use any Licensed Product but are not - themselves expressly set forth in the Advanced Messaging Queue Protocol - Specification (e.g., semiconductor manufacturing technology, compiler - technology, object oriented technology, networking technology, operating - system technology, and the like); or (ii) the implementation of other - published standards developed elsewhere and merely referred to in the - body of the Advanced Messaging Queue Protocol Specification, or - (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced - Messaging Queue Protocol Specification. For purposes of this definition, - the Advanced Messaging Queue Protocol Specification shall be deemed to - include both architectural and interconnection requirements essential - for interoperability and may also include supporting source code artifacts - where such architectural, interconnection requirements and source code - artifacts are expressly identified as being required or documentation to - achieve compliance with the Advanced Messaging Queue Protocol Specification. - - As used hereunder, "Licensed Products" means only those specific portions - of products (hardware, software or combinations thereof) that implement - and are compliant with all relevant portions of the Advanced Messaging - Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any - use you may make of the Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," - AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE - CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE - SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY - PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, - INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY - USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED MESSAGING QUEUE - PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, - including advertising or publicity pertaining to the Advanced Messaging - Queue Protocol Specification or its contents without specific, written - prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you - shall destroy all copies of the Advanced Messaging Queue Protocol - Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the - Octagon Symbol are trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA - Technologies PLC and/or its subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered - trademarks of Red Hat, Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of - Sun Microsystems, Inc. in the United States, other countries, or both. - - Other company, product, or service names may be trademarks or service - marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp diff --git a/qpid/specs/amqp.0-10-preview.xml b/qpid/specs/amqp.0-10-preview.xml deleted file mode 100644 index 5af956e75d..0000000000 --- a/qpid/specs/amqp.0-10-preview.xml +++ /dev/null @@ -1,7170 +0,0 @@ -<?xml version="1.0"?> - -<!-- - EDITORS: (PH) Pieter Hintjens <ph@imatix.com> - (KvdR) Kim van der Riet <kim.vdriet@redhat.com> - - These editors have been assigned by the AMQP working group. Please do not edit/commit this file - without consulting with one of the above editors. - ======================================================== - - TODOs - - see TODO comments in the text ---> - -<!-- - Copyright Notice - ================ - (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix - Corporation, IONA\ufffd Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. - 2006. All rights reserved. - - License - ======= - JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA - Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. (collectively, the - "Authors") each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable, - nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue - Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for - the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and - any rights under this Agreement will terminate immediately without notice from any Author if you - bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol - Specification against any Author. Upon termination, you shall destroy all copies of the Advanced - Messaging Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or patent application, - throughout the world, excluding design patents and design registrations, owned or controlled, or - that can be sublicensed without fee and in compliance with the requirements of this Agreement, by - an Author or its affiliates now or at any future time and which would necessarily be infringed by - implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily - infringed hereunder only when it is not possible to avoid infringing it because there is no - plausible non-infringing alternative for implementing the required portions of the Advanced - Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not - include any claims other than as set forth above even if contained in the same patent as Licensed - Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging Queue Protocol - Specification, or that, if licensed, would require a payment of royalties by the licensor to - unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling - technologies that may be necessary to make or use any Licensed Product but are not themselves - expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor - manufacturing technology, compiler technology, object oriented technology, networking technology, - operating system technology, and the like); or (ii) the implementation of other published - standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue - Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced Messaging Queue Protocol - Specification. For purposes of this definition, the Advanced Messaging Queue Protocol - Specification shall be deemed to include both architectural and interconnection requirements - essential for interoperability and may also include supporting source code artifacts where such - architectural, interconnection requirements and source code artifacts are expressly identified as - being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol - Specification. - - As used hereunder, "Licensed Products" means only those specific portions of products (hardware, - software or combinations thereof) that implement and are compliant with all relevant portions of - the Advanced Messaging Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any use you may make of the - Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS MAKE NO - REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS - OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE - IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD - PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL - DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, including advertising or - publicity pertaining to the Advanced Messaging Queue Protocol Specification or its contents - without specific, written prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you shall destroy all copies of - the Advanced Messaging Queue Protocol Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the Octagon Symbol are - trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA Technologies PLC and/or its - subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered trademarks of Red Hat, - Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of Sun Microsystems, Inc. in the - United States, other countries, or both. - - Other company, product, or service names may be trademarks or service marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp ---> - -<!-- - XML Notes - ========= - - We use entities to indicate repetition; attributes to indicate properties. - - We use the "name" attribute as an identifier, usually within the context of the surrounding - entities. - - We use hyphens (minus char '-') to seperate words in names. - - We do not enforce any particular validation mechanism but we support all mechanisms. The protocol - definition conforms to a formal grammar that is published seperately in several technologies. - ---> - -<!-- - -<!DOCTYPE amqp SYSTEM "amqp.dtd"> - ---> - -<amqp xmlns="http://www.amqp.org/schema/amqp.xsd" - major="99" minor="0" port="5672" comment="AMQ Protocol (Working version)"> - - <!-- - ====================================================== - == CONSTANTS - ====================================================== - --> - <!-- Frame types --> - <constant name="frame-method" value="1" /> - <constant name="frame-header" value="2" /> - <constant name="frame-body" value="3" /> - <constant name="frame-trace" value="7" /> - <constant name="frame-heartbeat" value="8" /> - - <!-- Protocol constants --> - <constant name="frame-min-size" value="4096" /> - <constant name="frame-end" value="206" /> - - <!-- Reply codes --> - <constant name="reply-success" value="200"> - <doc> - Indicates that the method completed successfully. This reply code is reserved for future use - - the current protocol design does not use positive confirmation and reply codes are sent only - in case of an error. - </doc> - </constant> - - <constant name="not-delivered" value="310" class="soft-error"> - <doc> - The client asked for a specific message that is no longer available. The message was delivered - to another client, or was purged from the queue for some other reason. - </doc> - </constant> - - <constant name="content-too-large" value="311" class="soft-error"> - <doc> - The client attempted to transfer content larger than the server could accept at the present - time. The client may retry at a later time. - </doc> - </constant> - - <constant name="no-route" value="312" class="soft-error"> - <doc> - When the exchange cannot route the result of a .Publish, most likely due to an invalid routing - key. Only when the mandatory flag is set. - </doc> - </constant> - - <constant name="no-consumers" value="313" class="soft-error"> - <doc> - When the exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </constant> - - <constant name="connection-forced" value="320" class="hard-error"> - <doc> - An operator intervened to close the connection for some reason. The client may retry at some - later date. - </doc> - </constant> - - <constant name="invalid-path" value="402" class="hard-error"> - <doc> - The client tried to work with an unknown virtual host. - </doc> - </constant> - - <constant name="access-refused" value="403" class="soft-error"> - <doc> - The client attempted to work with a server entity to which it has no access due to security - settings. - </doc> - </constant> - - <constant name="not-found" value="404" class="soft-error"> - <doc> - The client attempted to work with a server entity that does not exist. - </doc> - </constant> - - <constant name="resource-locked" value="405" class="soft-error"> - <doc> - The client attempted to work with a server entity to which it has no access because another - client is working with it. - </doc> - </constant> - - <constant name="precondition-failed" value="406" class="soft-error"> - <doc> - The client requested a method that was not allowed because some precondition failed. - </doc> - </constant> - - <constant name="session-busy" value="407" class="soft-error"> - <doc> - A session.resume was attempted for a session already attached to another channel. - </doc> - </constant> - - <constant name="frame-error" value="501" class="hard-error"> - <doc> - The client sent a malformed frame that the server could not decode. This strongly implies a - programming error in the client. - </doc> - </constant> - - <constant name="syntax-error" value="502" class="hard-error"> - <doc> - The client sent a frame that contained illegal values for one or more fields. This strongly - implies a programming error in the client. - </doc> - </constant> - - <constant name="command-invalid" value="503" class="hard-error"> - <doc> - The client sent an invalid sequence of frames, attempting to perform an operation that was - considered invalid by the server. This usually implies a programming error in the client. - </doc> - </constant> - - <!-- TODO: Should this be renamed to "session-error" since class channel has been replaced by - class session? --> - <constant name="channel-error" value="504" class="hard-error"> - <doc> - The client attempted to work with a channel that had not been correctly opened. This most - likely indicates a fault in the client layer. - </doc> - </constant> - - <constant name="resource-error" value="506" class="hard-error"> - <doc> - The server could not complete the method because it lacked sufficient resources. This may be - due to the client creating too many of some type of entity. - </doc> - </constant> - - <constant name="not-allowed" value="530" class="hard-error"> - <doc> - The client tried to work with some entity in a manner that is prohibited by the server, due to - security settings or by some other criteria. - </doc> - </constant> - - <constant name="not-implemented" value="540" class="hard-error"> - <doc> - The client tried to use functionality that is not implemented in the server. - </doc> - </constant> - - <constant name="internal-error" value="541" class="hard-error"> - <doc> - The server could not complete the method because of an internal error. The server may require - intervention by an operator in order to resume normal operations. - </doc> - </constant> - - <constant name="invalid-argument" value="542" class="hard-error"> - <doc> - An invalid or illegal argument was passed to a method, and the operation could not proceed. - </doc> - </constant> - - <constant name="channel-busy" value="543" class="hard-error"> - <doc> - A session.open was sent on a channel that was already attached to a session. - </doc> - </constant> - - <!-- XA constants --> - - <constant name="xa-ok" value="0"> - <doc> - XA return code: Normal execution completion (no error). - </doc> - </constant> - - <constant name="xa-rbrollback" value="1"> - <doc> - XA return code: The rollback was caused for an unspecified reason. - </doc> - </constant> - - <constant name="xa-rbtimeout" value="2"> - <doc> - XA return code: A transaction branch took too long. - </doc> - </constant> - - <constant name="xa-heurhaz" value="3"> - <doc> - XA return code: The transaction branch may have been heuristically completed. - </doc> - </constant> - - <constant name="xa-heurcom" value="4"> - <doc> - XA return code: The transaction branch has been heuristically committed. - </doc> - </constant> - - <constant name="xa-heurrb" value="5"> - <doc> - XA return code: The transaction branch has been heuristically rolled back. - </doc> - </constant> - - <constant name="xa-heurmix" value="6"> - <doc> - XA return code: The transaction branch has been heuristically committed and rolled back. - </doc> - </constant> - - <constant name="xa-rdonly" value="7"> - <doc> - XA return code: The transaction branch was read-only and has been committed. - </doc> - </constant> - - <!-- - ================================ - == Field Table type constants == - ================================ - --> - - <!-- - 0x00 - 0x0f: Fixed width, 1 octet - --> - - <constant name="field-table-octet" value="0x00" width="1" datatype="binary" - class="field-table-type"> - <doc> - Octet of unspecified encoding - </doc> - </constant> - - <constant name="field-table-signed-byte" value="0x01" width="1" datatype="signed-integer" - class="field-table-type"> - <doc> - 8-bit signed integral value (-128 - 127) - </doc> - </constant> - - <constant name="field-table-unsigned-byte" value="0x02" width="1" datatype="unsigned-integer" - class="field-table-type"> - <doc> - 8-bit unsigned integral value (0 - 255) - </doc> - </constant> - - <constant name="field-table-char" value="0x04" width="1" datatype="char" - class="field-table-type"> - <doc> - 8-bit representation of single character in the iso-8859-15 character set - </doc> - </constant> - - <constant name="field-table-boolean" value="0x08" width="1" datatype="boolean" - class="field-table-type"> - <doc> - Boolean value (0 represents false, 1 represents true) - </doc> - </constant> - - <!-- - 0x10 - 0x1f: Fixed width, 2 octets - --> - - <constant name="field-table-two-octets" value="0x10" width="2" datatype="binary" - class="field-table-type"> - <doc> - Two octets of unspecified binary encoding - </doc> - </constant> - - <constant name="field-table-signed-short" value="0x11" width="2" datatype="signed-integer" - class="field-table-type"> - <doc> - 16-bit signed integral value - </doc> - </constant> - - <constant name="field-table-unsigned-short" value="0x12" width="2" datatype="unsigned-integer" - class="field-table-type"> - <doc> - 16-bit unsigned integral value - </doc> - </constant> - - <!-- - 0x20 - 0x2f: Fixed width, 4 octets - --> - - <constant name="field-table-four-octets" value="0x20" width="4" datatype="binary" - class="field-table-type"> - <doc> - Four octets of unspecified binary encoding - </doc> - </constant> - - <constant name="field-table-signed-int" value="0x21" width="4" datatype="signed-integer" - class="field-table-type"> - <doc> - 32-bit signed integral value - </doc> - </constant> - - <constant name="field-table-unsigned-int" value="0x22" width="4" datatype="unsigned-integer" - class="field-table-type"> - <doc> - 32-bit unsigned integral value - </doc> - </constant> - - <constant name="field-table-float" value="0x23" width="4" datatype="ieee-float" - class="field-table-type"> - <doc> - Single precision IEEE 754 32-bit floating point - </doc> - </constant> - - <constant name="field-table-utf32-char" value="0x27" width="4" datatype="char" - class="field-table-type"> - <doc> - Single unicode character in UTF-32 encoding - </doc> - </constant> - - <!-- - 0x30 - 0x3f: Fixed width types - 8 octets - --> - - <constant name="field-table-eight-octets" value="0x30" width="8" datatype="binary" - class="field-table-type"> - <doc> - Eight octets of unspecified binary encoding - </doc> - </constant> - - <constant name="field-table-signed-long" value="0x31" width="8" datatype="signed-integer" - class="field-table-type"> - <doc> - 64-bit signed integral value - </doc> - </constant> - - <constant name="field-table-unsigned-long" value="0x32" width="8" datatype="unsigned-integer" - class="field-table-type"> - <doc> - 64-bit unsigned integral value - </doc> - </constant> - - <constant name="field-table-double" value="0x33" width="8" datatype="ieee-float" - class="field-table-type"> - <doc> - Double precision IEEE 754 floating point - </doc> - </constant> - - <constant name="field-table-datetime" value="0x38" width="8" datatype="special" - class="field-table-type"> - <doc> - Datetime in POSIX time_t format - </doc> - </constant> - - <!-- - 0x40 - 0x4f: Fixed width types - 16 octets - --> - - <constant name="field-table-sixteen-octets" value="0x40" width="16" datatype="binary" - class="field-table-type"> - <doc> - Sixteen octets of unspecified binary encoding - </doc> - </constant> - - <constant name="field-table-uuid" value="0x48" width="16" datatype="special" - class="field-table-type"> - <doc> - UUID as defined by RFC4122 - </doc> - </constant> - - <!-- - 0x50 - 0x5f: Fixed width types - 32 octets - --> - - <constant name="field-table-thirty-two-octets" value="0x50" width="32" datatype="binary" - class="field-table-type"> - <doc> - Thirty two octets of unspecified binary encoding - </doc> - </constant> - - <!-- - 0x60 - 0x6f: Fixed width types - 64 octets - --> - - <constant name="field-table-sixty-four-octets" value="0x60" width="64" datatype="binary" - class="field-table-type"> - <doc> - Sixty four octets of unspecified binary encoding - </doc> - </constant> - - <!-- - 0x70 - 0x7f: Fixed width types - 128 octets - --> - - <constant name="field-table-128-octets" value="0x70" width="128" datatype="binary" - class="field-table-type"> - <doc> - One hundred and twenty eight octets of unspecified binary encoding - </doc> - </constant> - - <!-- - 0x80 - 0x8f: Variable length - one byte length field (up to 255 octets) - --> - - <constant name="field-table-short-binary" value="0x80" lfwidth="1" datatype="binary" - class="field-table-type"> - <doc> - A sequence of up to 255 octets representing opaque binary data - </doc> - </constant> - - <constant name="field-table-short-string" value="0x84" lfwidth="1" datatype="string" - class="field-table-type"> - <doc> - A sequence of up to 255 characters in the iso-8859-15 character set - </doc> - </constant> - - <constant name="field-table-short-utf8-string" value="0x85" lfwidth="1" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most - 255 bytes - </doc> - </constant> - - <constant name="field-table-short-utf16-string" value="0x86" lfwidth="1" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most - 255 bytes - </doc> - </constant> - - <constant name="field-table-short-utf32-string" value="0x87" lfwidth="1" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most - 255 bytes (i.e. of 0-63 utf32 characters) - </doc> - </constant> - - <!-- - 0x90 - 0x9f: Variable length types - two byte length field (up to 65535 octets) - --> - - <constant name="field-table-binary" value="0x90" lfwidth="2" datatype="binary" - class="field-table-type"> - <doc> - A sequence of up to 65535 octets representing opaque binary data - </doc> - </constant> - - <constant name="field-table-string" value="0x94" lfwidth="2" datatype="string" - class="field-table-type"> - <doc> - A sequence of up to 65535 characters in the iso-8859-15 character set - </doc> - </constant> - - <constant name="field-table-utf8-string" value="0x95" lfwidth="2" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most - 65535 bytes - </doc> - </constant> - - <constant name="field-table-utf16-string" value="0x96" lfwidth="2" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most - 65535 bytes - </doc> - </constant> - - <constant name="field-table-utf32-string" value="0x97" lfwidth="2" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most - 65535 bytes (i.e. of 0-16383 utf32 characters) - </doc> - </constant> - - <!-- - 0xa0 - 0xaf: Variable length types - four byte length field (up to 4294967295 octets) - --> - - <constant name="field-table-long-binary" value="0xa0" lfwidth="4" datatype="binary" - class="field-table-type"> - <doc> - A sequence of up to 4294967295 octets representing opaque binary data - </doc> - </constant> - - <constant name="field-table-long-string" value="0xa4" lfwidth="4" datatype="string" - class="field-table-type"> - <doc> - A sequence of up to 4294967295 characters in the iso-8859-15 character set - </doc> - </constant> - - <constant name="field-table-long-utf8-string" value="0xa5" lfwidth="4" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf8 encoding which is able to be encoded in at most - 4294967295 bytes - </doc> - </constant> - - <constant name="field-table-long-utf16-string" value="0xa6" lfwidth="4" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf16 encoding which is able to be encoded in at most - 4294967295 bytes - </doc> - </constant> - - <constant name="field-table-long-utf32-string" value="0xa7" lfwidth="4" datatype="string" - class="field-table-type"> - <doc> - A sequence of unicode characters in the utf32 encoding which is able to be encoded in at most - 4294967295 bytes (i.e. of 0-1073741823 utf32 characters) - </doc> - </constant> - - <constant name="field-table-table" value="0xa8" lfwidth="4" datatype="field-table" - class="field-table-type"> - <doc> - A field table following the encoding specification given here - </doc> - </constant> - - <constant name="field-table-sequence" value="0xa9" lfwidth="4" datatype="sequence" - class="field-table-type"> - <doc> - A sequence is a series of consecutive type-value pairs; using the same type designators as the - field table - </doc> - </constant> - - <constant name="field-table-array" value="0xaa" lfwidth="4" datatype="array" - class="field-table-type"> - <doc> - An array represents a collection of values of the same type. The array is encoded as a single - octet type designator (using the same system as given here for the field table), followed by a - four-octet unsigned integer which represents the number of elements in the collection, - followed by the encoding of that number of values of the given type - </doc> - </constant> - - <!-- - 0xb0 - 0xbf: Reserved - --> - - <!-- - 0xc0 - 0xcf:Fixed width types - 5 octets - --> - - <constant name="field-table-five-octets" value="0xc0" width="5" datatype="binary" - class="field-table-type"> - <doc> - Five octets of unspecified binary encoding - </doc> - </constant> - - <constant name="field-table-decimal" value="0xc8" width="5" datatype="decimal" - class="field-table-type"> - <doc> - Encoded as an octet representing the number of decimal places followed by a signed 4 octet - integer. The 'decimals' octet is not signed - </doc> - </constant> - - <!-- - 0xd0 - 0xdf: Fixed width types - 9 octets - --> - - <constant name="field-table-nine-octets" value="0xd0" width="9" datatype="binary" - class="field-table-type"> - <doc> - Eight octets of unspecified binary encoding - </doc> - </constant> - - <constant name="field-table-long-decimal" value="0xd8" width="9" datatype="decimal" - class="field-table-type"> - <doc> - Encoded as an octet representing the number of decimal places followed by a signed 8 octet - integer. The 'decimals' octet is not signed - </doc> - </constant> - - <!-- - 0xe0 - 0xef: Reserved - --> - - <!-- - 0xf0 - 0xff: Zero-length types - --> - - <constant name="field-table-void" value="0xf0" width="0" datatype="void" - class="field-table-type"> - <doc> - The void type - </doc> - </constant> - - <!-- - ====================================================== - == DOMAIN TYPES - ====================================================== - --> - - <domain name="access-ticket" type="short" label="access ticket granted by server"> - <doc> - An access ticket granted by the server for a certain set of access rights within a specific - realm. Access tickets are valid within the session where they were created, and expire when - the session closes. - </doc> - <assert check="ne" value="0" /> - </domain> - - <domain name="class-id" type="short"> - <doc> - <!-- TODO: Description required for docs --> - </doc> - </domain> - - <domain name="method-id" type="short"> - <doc> - <!-- TODO: Description required for docs --> - </doc> - </domain> - - <domain name="consumer-tag" type="shortstr" label="consumer tag"> - <doc> - Identifier for the consumer, valid within the current connection. - </doc> - </domain> - - <domain name="delivery-tag" type="longlong" label="server-assigned delivery tag"> - <doc> - The server-assigned and session-specific delivery tag - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. i.e. - A client MUST NOT receive a message on one session and then acknowledge it on another. - </doc> - </rule> - <rule name="non-zero"> - <doc> - The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, - meaning "all messages so far received". - </doc> - </rule> - <assert check="ne" value="0" /> - </domain> - - <domain name="exchange-name" type="shortstr" label="exchange name"> - <doc> - The exchange name is a client-selected string that identifies the exchange for publish - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - </doc> - <assert check="regexp" value="[a-zA-Z0-9_]{1,127}"> - <doc> - This regular expression checks that all characters are one of a-z (lower case), A-Z (upper - case), 0-9 (any digit) and the underscore character. There may be between 1 and 127 of these - characters. - </doc> - </assert> - </domain> - - <domain name="known-hosts" type="shortstr" label="list of known hosts"> - <doc> - Specifies the list of equivalent or alternative hosts that the server knows about, which will - normally include the current server itself. Clients can cache this information and use it when - reconnecting to a server after a failure. This field may be empty. - </doc> - </domain> - - <domain name="message-id" type="uuid"> - <doc> - Message-id is an optional property of UUID type which uniquly identifies a message within the - message system. The message producer is usually responsible for setting the message-id. Note - that the server may discard a message as a duplicate if the value of the message-id matches - that of a previously received message. - </doc> - <rule name="unique"> - <doc> - A message MUST be unique within a given server instance. A message SHOULD be globally unique - (i.e. across different systems). - </doc> - </rule> - <rule name="immutable"> - <doc> - A message ID is immutable. Once set, a message-id MUST NOT be changed or reassigned, even if - the message is replicated, resent or sent to multiple queues. - </doc> - </rule> - </domain> - - <domain name="no-ack" type="bit" label="no acknowledgement needed"> - <doc> - If this field is set the server does not expect acknowledgements for messages. That is, when a - message is delivered to the client the server automatically and silently acknowledges it on - behalf of the client. This functionality increases performance but at the cost of reliability. - Messages can get lost if a client dies before it can deliver them to the application. - </doc> - </domain> - - <domain name="no-local" type="bit" label="do not deliver own messages"> - <doc> - If the no-local field is set the server will not send messages to the connection that - published them. - </doc> - </domain> - - <domain name="path" type="shortstr"> - <doc> - Must start with a slash "/" and continue with path names separated by slashes. A path name - consists of any combination of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. - </doc> - <assert check="notnull" /> - <assert check="syntax" rule="path" /> - <assert check="length" value="127" /> - </domain> - - <domain name="peer-properties" type="table"> - <doc> - This string provides a set of peer properties, used for identification, debugging, and general - information. - </doc> - </domain> - - <domain name="queue-name" type="shortstr" label="queue name"> - <doc> - The queue name identifies the queue within the vhost. Queue names must have a length of - between 1 and 255 chatacters inclusive, must start with a digit, letter or underscores ('_') - character, and must be otherwise encoded in UTF-8. - </doc> - <assert check="regexp" value="[a-zA-Z0-9_].{0,254}"> - <doc> - This regular expression checks that the first character is one of a-z (lower case), A-Z - (upper case), 0-9 (any digit) and the underscore character. Following may be between 0 and - 254 characters of any value. - </doc> - </assert> - </domain> - - <domain name="redelivered" type="bit" label="message is being redelivered"> - <doc> - This indicates that the message has been previously delivered to this or another client. - </doc> - <rule name="implementation"> - <doc> - The server SHOULD try to signal redelivered messages when it can. When redelivering a - message that was not successfully acknowledged, the server SHOULD deliver it to the original - client if possible. - </doc> - <doc type="scenario"> - Create a shared queue and publish a message to the queue. Consume the message using explicit - acknowledgements, but do not acknowledge the message. Close the connection, reconnect, and - consume from the queue again. The message should arrive with the redelivered flag set. - </doc> - </rule> - <rule name="hinting"> - <doc> - The client MUST NOT rely on the redelivered field but should take it as a hint that the - message may already have been processed. A fully robust client must be able to track - duplicate received messages on non-transacted, and locally-transacted sessions. - </doc> - </rule> - </domain> - - <domain name="rfc1982-long" type="long" label="serial number with arithmetic per RFC1982"> - <doc> - Serial number defined in RFC1982 which defines the arithmatic, operators and ranges of such - numbers. - </doc> - </domain> - - <domain name="reply-code" type="short" label="reply code from server"> - <doc> - The reply code. The AMQ reply codes are defined as constants at the start of this formal - specification. - </doc> - <assert check="notnull" /> - </domain> - - <domain name="reply-text" type="shortstr" label="localised reply text"> - <doc> - The localised reply text. This text can be logged as an aid to resolving issues. - </doc> - <assert check="notnull" /> - </domain> - - <!-- Domains for the message class --> - - <domain name="duration" type="longlong" label="duration in milliseconds"> - <doc> - Duration of an event or process measured in milliseconds. - </doc> - </domain> - - <domain name="offset" type="longlong" label="offset into a message body"> - <doc> - Offset in bytes into a message body. - </doc> - </domain> - - <domain name="reference" type="longstr" label="pointer to a message body"> - <doc> - Identifier to be used as a reference to a message body. - </doc> - </domain> - - <domain name="destination" type="shortstr" label="destination for a message"> - <doc> - Specifies the destination to which the message is to be transferred. The destination can be - empty, meaning the default exchange or consumer. - </doc> - </domain> - - <domain name="reject-code" type="short" label="reject code for transfer"> - <doc> - Code specifying the reason for a message reject. - </doc> - <rule name="allowed-values"> - <doc> - The reject code must be one of 0 (generic) or 1 (immediate delivery was attempted but - failed). - </doc> - </rule> - </domain> - - <domain name="reject-text" type="shortstr" label="informational text for message reject"> - <doc> - String describing the reason for a message transfer rejection. - </doc> - </domain> - - <domain name="security-token" type="longstr" label="security token"> - <doc> - A security token used for authentication, replay prevention, and encrypted message bodies. - </doc> - </domain> - - <domain name="reply-to"> - <struct size="short" pack="short"> - <field name="exchange-name" domain="exchange-name" /> - <field name="routing-key" domain="shortstr" /> - </struct> - </domain> - - <domain name="confirm-mode" type="octet" label="indicates a confirmation mode"> - <doc> - Controls whether message transfer needs to be confirmed. - - One of: - - off (0): confirmation is not required, once a message has been transferred in pre-acquire - mode (or once acquire has been sent in no-acquire mode) the message is considered - transferred - - - on (1): an acquired message (whether acquisition was implicit as in pre-acquire mode or - explicit as in no-acquire mode) is not considered transferred until the original - transfer is complete (signaled via execution.complete) - </doc> - </domain> - - <domain name="acquire-mode" type="octet" label="indicates the transfer mode"> - <doc> - Indicates whether a transferred message can be considered as automatically acquired or whether - an explicit request is necessary in order to acquire it. - - One of: - - no-acquire (0): the message must be explicitly acquired - - - pre-acquire (1): the message is acquired when the transfer starts - </doc> - </domain> - - <!-- message header domains --> - - <domain name="delivery-properties"> - <struct size="long" pack="short" type="0"> - <field name="discard-unroutable" domain="bit" label="controls discard of unroutable messages"> - <doc> - If set on a message that is not routable the broker can discard it. If not set unroutable - should be handled by reject when confirmation is on or by routing to the - alternate-exchange if defined when confirmation is off. - </doc> - </field> - - <field name="redelivered" domain="redelivered" label="redelivery flag"> - <doc> - This boolean flag indicates that the message has been previously delivered to this or - another client. - </doc> - </field> - - <field name="priority" domain="octet" label="message priority, 0 to 9"> - <doc> - Message priority, which can be between 0 and 9. Messages with higher priorities may be - delivered before those with lower priorities. - </doc> - </field> - - <field name="delivery-mode" domain="octet" label="message persistence"> - <doc> - The delivery mode may be non-persistent (1) or persistent (2). A persistent message is one - which must be stored on a persistent medium (usually hard drive) at every stage of - delivery so that it will not be lost in event of failure (other than the medium itself). - This is normally accomplished with some additional overhead. A persistent message may be - delivered more than once if there is uncertainty about the state of its delivery after a - failure and recovery. - - Conversely, a non-persistent message may be lost in event of a failure, but the nature of - the communication is such that an occasional message loss is tolerable. This is the lowest - overhead mode. Non-persistent messages are delivered at most once only. - </doc> - </field> - - <field name="ttl" domain="duration" label="time to live"> - <doc> - If this is set to a non zero value then a message expiration time will be computed based - on the current time plus this value. Messages that live longer than their expiration time - will be discarded (or dead lettered). - </doc> - <rule name="ttl-decrement"> - <doc> - If a message is transferred between brokers before delivery to a final consumer the ttl - should be decremented before peer to peer transfer and both timestamp and expiration - should be cleared. - </doc> - </rule> - </field> - - <field name="timestamp" domain="timestamp" label="message timestamp"> - <doc> - The timestamp is set by the broker on arrival of the message. - </doc> - </field> - - <field name="expiration" domain="timestamp" label="message expiration time"> - <doc> - The expiration header assigned by the broker. After receiving the message the broker sets - expiration to the sum of the ttl specified in the publish method and the current time. - (ttl=expiration - timestamp) - </doc> - </field> - - <field name="exchange" domain="exchange-name" label="originating exchange"> - <doc> - The exchange name is a client-selected string that identifies the exchange for transfer - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="message routing key"> - <doc> - The value of the key determines to which queue the exchange will send the message. The way - in which keys are used to make this routing decision depends on the type of exchange to - which the message is sent. For example, a direct exchange will route a message to a queue - if that queue is bound to the exchange with an identical key to that of the message. - </doc> - </field> - </struct> - </domain> - - <domain name="message-properties"> - <struct size="long" pack="short" type="1"> - <field name="content-length" domain="longlong" label="length of content in bytes"> - <doc> - The length of the message content in bytes. - </doc> - </field> - - <field name="message-id" domain="shortstr" label="application message identifier"> - <doc> - This is a unique identifier for the message that is guaranteed to be unique across - multiple instances, sessions and in time. This allows duplicate messages to be detected. - This may be a UUID. Note that this is usually set by the server when it first receives a - message. - - If a client wishes to identify a message, it should use the correlation-id instead. - </doc> - </field> - - <field name="correlation-id" domain="shortstr" label="application correlation identifier"> - <doc> - This is a client-specific id that may be used to mark or identify messages between - clients. The server ignores this field. - </doc> - </field> - - <field name="reply-to" domain="reply-to" label="destination to reply to"> - <doc> - The destination of any message that is sent in reply to this message. - </doc> - </field> - - <field name="content-type" domain="shortstr" label="MIME content type"> - <doc> - The RFC-2046 MIME type for the message content (such as "text/plain"). This is set by the - originating client. - </doc> - </field> - - <field name="content-encoding" domain="shortstr" label="MIME content encoding"> - <doc> - The encoding for character-based message content. This is set by the originating client. - Examples include UTF-8 and ISO-8859-16. - </doc> - </field> - - <field name="type" domain="shortstr" label="message type name"> - <doc> - The JMS message type. - </doc> - </field> - - <field name="user-id" domain="shortstr" label="creating user id"> - <doc> - The identity of the user responsible for producing the message. - </doc> - </field> - - <field name="app-id" domain="shortstr" label="creating application id"> - <doc> - The identity of the client application responsible for producing the message. - </doc> - </field> - - <field name="transaction-id" domain="shortstr" label="distributed transaction id"> - <doc> - An identifier that links this message to a distributed transaction. - </doc> - </field> - - <field name="security-token" domain="security-token" label="security token"> - <doc> - A security token used for authentication, replay prevention, and encrypted message bodies. - </doc> - </field> - - <field name="application-headers" domain="table" label="application specific headers table"> - <doc> - This is a collection of user-defined headers or properties which may be set by the - producing client and retrieved by the consuming client. Similar to JMS Properties. - </doc> - </field> - </struct> - </domain> - - <!-- Domians for DTX --> - - <domain name="xid" type="longstr" label="Dtx branch identifier"> - <doc> - An xid uniquely identifies a transaction branch. - </doc> - - <rule name="implementation"> - <doc> - xid contains a format identifier, two length fields and a data field: - - format_id long - - gtrid_length octet - - bqual_length octet - - data gtrid_length + bqual_length - </doc> - <doc type="picture"> - 4 1 1 g b - +---+---+---+---+---+---+---+- -+---+---+- -+---+ - | format_id | g | b | txn-id | br-id | - +---+---+---+---+---+---+---+- -+---+---+- -+---+ - 0 4 5 6 6+g 6+g+b - </doc> - <doc> - format_id: an implementation specific format identifier - - gtrid_length: how many bytes of this form the transaction id - - bqual_length: how many bytes of this form the branch id - - data: a sequence of octets of at most 128 bytes containing the txn id and the - branch id - - Note - The sum of the two lengths must equal the length of the data field. - </doc> - </rule> - </domain> - - <!-- Domains for session class --> - - <domain name="detached-lifetime" type="long" label="possibly unbounded duration in seconds"> - <doc> - Detached-lifetime is an integer encoded as follows: - - * the maximum representable value means unbounded - the maximum length permitted by the peer - - * otherwise, any other value (including zero) is the number of seconds the session's state - is retained during periods when no channel (or equivalent) is attached to the session - (DetachedLifetimeFinite above). - </doc> - </domain> - - <domain name="session-id" type="uuid" label="session identifier" /> - - <!-- Domains for the execution class --> - - <domain name="correlation" type="rfc1982-long-set"> - <doc> - Identifies a set of commands inside the window of open conversations. - </doc> - </domain> - <domain name="command-id" type="long"/> - <domain name="long-struct" type="long-struct"> - <doc> - Any typed struct whose size width is long. - </doc> - </domain> - - <domain name="execution-header"> - <doc> - The execution header appears on commands after the class and method id, but prior to method - arguments. - </doc> - <struct size="octet" pack="octet"> - <field name="sync" domain="bit" label="request notification of completion for a specific command"> - <doc> - Indicates that the peer sending the request wants to be notified when this command is - completed. - </doc> - </field> - </struct> - </domain> - - <!-- Elementary domains --> - <domain name="bit" type="bit" label="single bit" /> - <domain name="octet" type="octet" label="single octet" /> - <domain name="short" type="short" label="16-bit integer" /> - <domain name="long" type="long" label="32-bit integer" /> - <domain name="longlong" type="longlong" label="64-bit integer" /> - <domain name="shortstr" type="shortstr" label="short string" /> - <domain name="longstr" type="longstr" label="long string" /> - <domain name="timestamp" type="timestamp" label="64-bit POSIX timestamp" /> - <domain name="table" type="table" label="field table" /> - <domain name="uuid" type="uuid" label="UUID (RFC4122 section 4.1.2) - 16 octets" /> - <domain name="array" type="array" label="array"/> - - <domain name="content" type="content" label="message content"> - <doc> - Content of a message. It should be considered opaque binary data. The length of the message is - determined from the context of this type (the message length field of the message.transfer - method). - </doc> - </domain> - - <domain name="rfc1982-long-set" type="rfc1982-long-set" label="ranged set representation"> - <doc> - Set of pairs of RFC-1982 numbers representing a discontinuous range. Each pair represents a - closed interval within the list. - - For example, the set (1,3), (6,6), (8,9) represents the sequence 1,2,3,6,8,9. - </doc> - </domain> - - <!-- == Class: connection ==================================================================== --> - - <class name="connection" index="10" label="work with socket connections"> - <doc> - The connection class provides methods for a client to establish a network connection to a - server, and for both peers to operate the connection thereafter. - </doc> - - <doc type="grammar"> - connection = open-connection - *use-connection - close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <!-- - Method: connection.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="start" synchronous="1" index="10" label="start connection negotiation"> - <doc> - This method starts the connection negotiation process by telling the client the protocol - version that the server proposes, along with a list of security mechanisms which the client - can use for authentication. - </doc> - - <rule name="protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, it MUST close - the socket connection without sending any response method. - </doc> - <doc type="scenario"> - The client sends a protocol header containing an invalid protocol name. The server must - respond by closing the connection. - </doc> - </rule> - - <rule name="server-support"> - <doc> - The server MUST provide a protocol version that is lower than or equal to that requested - by the client in the protocol header. - </doc> - <doc type="scenario"> - The client requests a protocol version that is higher than any valid implementation, e.g. - 9.0. The server must respond with a current protocol version, e.g. 1.0. - </doc> - </rule> - - <rule name="client-support"> - <doc> - If the client cannot handle the protocol version suggested by the server it MUST close the - socket connection. - </doc> - <doc type="scenario"> - The server sends a protocol version that is lower than any valid implementation, e.g. 0.1. - The client must respond by closing the connection. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - - <response name="start-ok" /> - - <field name="version-major" domain="octet" label="protocol major version"> - <doc> - The protocol version, major component, as transmitted in the AMQP protocol header. This, - combined with the protocol minor component fully describe the protocol version, which is - written in the format major-minor. Hence, with major=1, minor=3, the protocol version - would be "1-3". - </doc> - </field> - - <field name="version-minor" domain="octet" label="protocol minor version"> - <doc> - The protocol version, minor component, as transmitted in the AMQP protocol header. This, - combined with the protocol major component fully describe the protocol version, which is - written in the format major-minor. Hence, with major=1, minor=3, the protocol version - would be "1-3". - </doc> - </field> - - <field name="server-properties" domain="peer-properties" label="server properties"> - <rule name="required-fields"> - <doc> - The properties SHOULD contain at least these fields: "host", specifying the server host - name or address, "product", giving the name of the server product, "version", giving the - name of the server version, "platform", giving the name of the operating system, - "copyright", if appropriate, and "information", giving other general information. - </doc> - <doc type="scenario"> - Client connects to server and inspects the server properties. It checks for the presence - of the required fields. - </doc> - </rule> - </field> - - <field name="mechanisms" domain="longstr" label="available security mechanisms"> - <doc> - A list of the security mechanisms that the server supports, delimited by spaces. - </doc> - <assert check="notnull" /> - </field> - - <field name="locales" domain="longstr" label="available message locales"> - <doc> - A list of the message locales that the server supports, delimited by spaces. The locale - defines the language in which the server will send reply texts. - </doc> - - <rule name="required-support"> - <doc> - The server MUST support at least the en_US locale. - </doc> - <doc type="scenario"> - Client connects to server and inspects the locales field. It checks for the presence of - the required locale(s). - </doc> - </rule> - - <assert check="notnull" /> - </field> - </method> - - <!-- - Method: connection.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="start-ok" synchronous="1" index="11" - label="select security mechanism and locale"> - <doc> - This method selects a SASL security mechanism. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="client-properties" domain="peer-properties" label="client properties"> - <rule name="required-fields"> - <!-- This rule is not testable from the client side --> - <doc> - The properties SHOULD contain at least these fields: "product", giving the name of the - client product, "version", giving the name of the client version, "platform", giving the - name of the operating system, "copyright", if appropriate, and "information", giving - other general information. - </doc> - </rule> - </field> - - <field name="mechanism" domain="shortstr" label="selected security mechanism"> - <doc> - A single security mechanisms selected by the client, which must be one of those specified - by the server. - </doc> - - <rule name="security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it can handle - from the list provided by the server. - </doc> - </rule> - - <rule name="validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms proposed by the - server in the Start method, the server MUST close the connection without sending any - further data. - </doc> - <doc type="scenario"> - Client connects to server and sends an invalid security mechanism. The server must - respond by closing the connection (a socket close, with no connection close - negotiation). - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="response" domain="longstr" label="security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this data are - defined by the SASL security mechanism. - </doc> - <assert check="notnull" /> - </field> - - <field name="locale" domain="shortstr" label="selected message locale"> - <doc> - A single message locale selected by the client, which must be one of those specified by - the server. - </doc> - <assert check="notnull" /> - </field> - </method> - - <!-- - Method: connection.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="secure" synchronous="1" index="20" label="security mechanism challenge"> - <doc> - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This method challenges the - client to provide more information. - </doc> - - <chassis name="client" implement="MUST" /> - - <response name="secure-ok" /> - - <field name="challenge" domain="longstr" label="security challenge data"> - <doc> - Challenge information, a block of opaque binary data passed to the security mechanism. - </doc> - </field> - </method> - - <!-- - Method: connection.secure-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="secure-ok" synchronous="1" index="21" label="security mechanism response"> - <doc> - This method attempts to authenticate, passing a block of SASL data for the security - mechanism at the server side. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="response" domain="longstr" label="security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this data are - defined by the SASL security mechanism. - </doc> - <assert check="notnull" /> - </field> - </method> - - <!-- - Method: connection.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="tune" synchronous="1" index="30" label="propose connection tuning parameters"> - <doc> - This method proposes a set of connection configuration values to the client. The client can - accept and/or adjust these. - </doc> - - <chassis name="client" implement="MUST" /> - - <response name="tune-ok" /> - - <field name="channel-max" domain="short" label="proposed maximum channels"> - <doc> - The maximum total number of channels that the server allows per connection. Zero means - that the server does not impose a fixed limit, but the number of allowed channels may be - limited by available server resources. - </doc> - </field> - - <field name="frame-max" domain="long" label="proposed maximum frame size"> - <doc> - The largest frame size that the server proposes for the connection. The client can - negotiate a lower value. Zero means that the server does not impose any specific limit but - may reject very large frames if it cannot allocate resources for them. - </doc> - - <rule name="minimum"> - <doc> - Until the frame-max has been negotiated, both peers MUST accept frames of up to - frame-min-size octets large, and the minimum negotiated value for frame-max is also - frame-min-size. - </doc> - <doc type="scenario"> - Client connects to server and sends a large properties field, creating a frame of - frame-min-size octets. The server must accept this frame. - </doc> - </rule> - </field> - - <field name="heartbeat" domain="short" label="desired heartbeat delay"> - <!-- TODO 0.82 - the heartbeat negotiation mechanism was changed during implementation - because the model documented here does not actually work properly. The best model we - found is that the server proposes a heartbeat value to the client; the client can reply - with zero, meaning 'do not use heartbeats (as documented here), or can propose its own - heartbeat value, which the server should then accept. This is different from the model - here which is disconnected - e.g. each side requests a heartbeat independently. Basically - a connection is heartbeated in both ways, or not at all, depending on whether both peers - support heartbeating or not, and the heartbeat value should itself be chosen by the client - so that remote links can get a higher value. Also, the actual heartbeat mechanism needs - documentation, and is as follows: so long as there is activity on a connection - in or out - - both peers assume the connection is active. When there is no activity, each peer must - send heartbeat frames. When no heartbeat frame is received after N cycles (where N is at - least 2), the connection can be considered to have died. /PH 2006/07/19 - --> - <doc> - The delay, in seconds, of the connection heartbeat that the server wants. Zero means the - server does not want a heartbeat. - </doc> - </field> - </method> - - <!-- - Method: connection.tune-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="tune-ok" synchronous="1" index="31" - label="negotiate connection tuning parameters"> - <doc> - This method sends the client's connection tuning parameters to the server. Certain fields - are negotiated, others provide capability information. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="channel-max" domain="short" label="negotiated maximum channels"> - <doc> - The maximum total number of channels that the client will use per connection. - </doc> - - <rule name="upper-limit"> - <doc> - If the client specifies a channel max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementors. - </doc> - </rule> - - <assert check="notnull" /> - <assert check="le" value="channel-max" /> - </field> - - <field name="frame-max" domain="long" label="negotiated maximum frame size"> - <doc> - The largest frame size that the client and server will use for the connection. Zero means - that the client does not impose any specific limit but may reject very large frames if it - cannot allocate resources for them. Note that the frame-max limit applies principally to - content frames, where large contents can be broken into frames of arbitrary size. - </doc> - - <rule name="minimum"> - <doc> - Until the frame-max has been negotiated, both peers MUST accept frames of up to - frame-min-size octets large, and the minimum negotiated value for frame-max is also - frame-min-size. - </doc> - </rule> - - <rule name="upper-limit"> - <doc> - If the client specifies a frame max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementors. - </doc> - </rule> - </field> - - <field name="heartbeat" domain="short" label="desired heartbeat delay"> - <doc> - The delay, in seconds, of the connection heartbeat that the client wants. Zero means the - client does not want a heartbeat. - </doc> - </field> - </method> - - <!-- - Method: connection.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="open" synchronous="1" index="40" label="open connection to virtual host"> - <doc> - This method opens a connection to a virtual host, which is a collection of resources, and - acts to separate multiple application domains within a server. The server may apply - arbitrary limits per virtual host, such as the number of each type of entity that may be - used, per connection and/or in total. - </doc> - - <chassis name="server" implement="MUST" /> - - <response name="open-ok" /> - <response name="redirect" /> - - <field name="virtual-host" domain="path" label="virtual host name"> - <!-- TODO 0.82 - the entire vhost model needs review. This concept was prompted by the HTTP - vhost concept but does not fit very well into AMQP. Currently we use the vhost as a - "cluster identifier" which is inaccurate usage. /PH 2006/07/19 - --> - <doc> - The name of the virtual host to work with. - </doc> - - <rule name="separation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full separation of - exchanges, queues, and all associated entities per virtual host. An application, - connected to a specific virtual host, MUST NOT be able to access resources of another - virtual host. - </doc> - </rule> - - <rule name="security"> - <doc> - The server SHOULD verify that the client has permission to access the specified virtual - host. - </doc> - </rule> - <assert check="regexp" value="^[a-zA-Z0-9/-_]+$" /> - </field> - - <field name="capabilities" domain="shortstr" label="required capabilities"> - <doc> - The client can specify zero or more capability names, delimited by spaces. The server can - use this string to how to process the client's connection request. - </doc> - </field> - - <field name="insist" domain="bit" label="insist on connecting to server"> - <doc> - In a configuration with multiple collaborating servers, the server may respond to a - Connection.Open method with a Connection.Redirect. The insist option tells the server that - the client is insisting on a connection to the specified server. - </doc> - <rule name="behaviour"> - <doc> - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect method. If it cannot accept the client's connection request it - should respond by closing the connection with a suitable reply code. - </doc> - </rule> - </field> - </method> - - <!-- - Method: connection.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="open-ok" synchronous="1" index="41" label="signal that connection is ready"> - <doc> - This method signals to the client that the connection is ready for use. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="known-hosts" domain="known-hosts" /> - </method> - - <!-- - Method: connection.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="redirect" synchronous="1" index="42" label="redirects client to other server"> - <doc> - This method redirects the client to another server, based on the requested virtual host - and/or capabilities. - </doc> - - <rule name="usage"> - <doc> - When getting the Connection.Redirect method, the client SHOULD reconnect to the host - specified, and if that host is not present, to any of the hosts specified in the - known-hosts list. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - - <field name="host" domain="shortstr" label="server to connect to"> - <doc> - Specifies the server to connect to. This is an IP address or a DNS name, optionally - followed by a colon and a port number. If no port number is specified, the client should - use the default port number for the protocol. - </doc> - <assert check="notnull" /> - </field> - - <field name="known-hosts" domain="known-hosts" /> - </method> - - <!-- - Method: connection.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="close" synchronous="1" index="50" label="request a connection close"> - <doc> - This method indicates that the sender wants to close the connection. This may be due to - internal conditions (e.g. a forced shut-down) or due to an error handling a specific method, - i.e. an exception. When a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - </doc> - <!-- TODO: The connection close mechanism needs to be reviewed from the ODF documentation and - better expressed as rules here. /PH 2006/07/20 - --> - - <rule name="stability"> - <doc> - After sending this method any received method except the Close-OK method MUST be - discarded. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - <chassis name="server" implement="MUST" /> - - <response name="close-ok" /> - - <field name="reply-code" domain="reply-code" /> - <field name="reply-text" domain="reply-text" /> - - <field name="class-id" domain="class-id" label="failing method class"> - <doc> - When the close is provoked by a method exception, this is the class of the method. - </doc> - </field> - - <field name="method-id" domain="method-id" label="failing method ID"> - <doc> - When the close is provoked by a method exception, this is the ID of the method. - </doc> - </field> - </method> - - <!-- - Method: connection.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="close-ok" synchronous="1" index="51" label="confirm a connection close"> - <doc> - This method confirms a Connection.Close method and tells the recipient that it is safe to - release resources for the connection and close the socket. - </doc> - - <rule name="reporting"> - <doc> - A peer that detects a socket closure without having received a Close-Ok handshake method - SHOULD log the error. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - <chassis name="server" implement="MUST" /> - </method> - - </class> - - <!-- == Class: session ======================================================================= --> - - <class name="session" index="20" label="session control methods"> - <doc> - The session class provides methods for a client to establish a session with a server and for - both peers to operate the session thereafter. - </doc> - - <doc type="grammar"> - session = open-session - *use-session - close-session - open-session = C:OPEN S:ATTACHED - / C:RESUME S:ATTACHED - use-session = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:PING - / C:PONG - / C:PING - / S:PONG - close-session = C:SUSPEND S:DETACHED - / C:CLOSE S:CLOSED - / S:CLOSED - / S:CLOSE C:CLOSED - / C:CLOSED - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <!-- - Method: session.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="open" synchronous="1" index="10" label="open a session for use"> - <doc> - This method opens a session with the server. - - When the responding peer creates the session, it MUST create a new, appropriately-unique - name for the session and return this to the creator with the rest of the session details. - - Note that the timer controlling a session's automatic expiry, if any, counts down - immediately from the moment of its creation, unless simultaneously with that moment a - channel (or equivalent) is attached to the session. For this reason, it is recommended that - network protocol mappings create sessions simultaneously with the creation and attachment of - their channel-equivalents, since a zero lease time is perfectly valid and indicates that the - session should be destroyed as soon as it first finds itself inactive. - - During the period that a channel (or equivalent) is attached to a session, the session has - no deletion timer. Every time a channel is detached from a session such that the session is - left without any attached network-level entities, the timer is created, set to its declared - value and started. - - Note that if the peer decides that the requested detached-lifetime timeout is too long, - either because the replying peer does not support sessions with non-zero requested timeouts, - or because the requested timeout exceeds some peer-specific limitation, it may substitute an - acceptable value for the detached-lifetime parameter in its reply to the creation request. - An exception is not required. - </doc> - - <rule name="expiration"> - <doc> - Whether the detachment is explicit or implicit, as a result of application action or of - application error, the channel (or equivalent) is detached from its session and the - session timer MUST start counting down as defined in session.open. - </doc> - </rule> - - <rule name="channel-busy"> - <!-- TODO: Figure out how to make this error conditional to stateful network mappings with - channels. - --> - <doc> - The client MUST NOT send session.open on a channel that is already associated with a - session. A "channel busy" connection exception will occur if the channel down which the - open request was sent was already attached to a session. - </doc> - <doc type="scenario"> - Client sends session.open twice down the same channel. - </doc> - </rule> - - <!-- - <throws name="out-of-resources"/> - --> - - <chassis name="server" implement="MUST" /> - - <response name="attached" /> - - <field name="detached-lifetime" domain="detached-lifetime"> - <doc> - The number of seconds the session's state is retained during periods when no channel (or - equivalent) is attached to the session. - </doc> - </field> - </method> - - <!-- - Method: session.attached - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="attached" synchronous="1" index="11" label="signal that the session is ready"> - <doc> - This method signals to the client that the session is ready for use. - - Once a session.attached is received by the client, everything is in place for normal - transmission of frames. However, depending on the network protocol mapping in use, the - frame-id be undefined until certain control frames have been sent. Please see the specific - details for each protocol mapping. - - If the attached session was freshly created, the session-id here will be a freshly-generated - UUID. - - Note that the actual session detached-lifetime value, as decided by the peer, is returned - using this method. The value returned may not be the same as that requested in the - corresponding session creation request. In particular, a request for an unbounded - detached-lifetime of may be fulfilled by creation of a session with a bounded actual - lifetime parameter. The requesting peer SHOULD take the lifetime value returned as - authoritative for its own session-related record-keeping. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="session-id" domain="session-id"> - <doc> - The session identifier (a UUID) used to identify this session. - </doc> - </field> - - <field name="detached-lifetime" domain="detached-lifetime"> - <doc> - The number of seconds the session's state is retained during periods when no channel (or - equivalent) is attached to the session. - </doc> - </field> - </method> - - <!-- - Method: session.flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="flow" synchronous="1" index="20" label="enable/disable flow from peer"> - <doc> - This method asks the peer to pause or restart the flow of content data. This is a simple - flow-control mechanism that a peer can use to avoid overflowing its queues or otherwise - finding itself receiving more messages than it can process. Note that this method is not - intended for window control. The peer that receives a disable flow method should finish - sending the current content frame, if any, then pause. - </doc> - - <rule name="initial-state"> - <doc> - When a new session is opened, it is active (flow is active). Some applications assume that - sessions are inactive until started. To emulate this behaviour a client MAY open the - session, then pause it. - </doc> - </rule> - - <rule name="bidirectional"> - <doc> - When sending content frames, a peer SHOULD monitor the session for incoming methods and - respond to a Session.Flow as rapidly as possible. - </doc> - </rule> - - <rule name="throttling"> - <doc> - A peer MAY use the Session.Flow method to throttle incoming content data for internal - reasons, for example, when exchanging data over a slower connection. - </doc> - </rule> - - <rule name="expected-behaviour"> - <doc> - The peer that requests a Session.Flow method MAY disconnect and/or ban a peer that does - not respect the request. This is to prevent badly-behaved clients from overwhelming a - broker. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <response name="flow-ok" /> - - <field name="active" domain="bit" label="start/stop content frames"> - <doc> - If true (1), the peer starts sending content frames. If false (0), the peer stops sending - content frames. - </doc> - </field> - </method> - - <!-- - Method: session.flow-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="flow-ok" index="21" label="confirm a flow method"> - <doc> - Confirms to the peer that a flow command was received and processed. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="active" domain="bit" label="current flow setting"> - <doc> - Confirms the setting of the processed flow method: true (1) means the peer will start - sending or continue to send content frames; false (0) means it will not. - </doc> - </field> - </method> - - <!-- - Method: session.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="close" index="40" label="request a session close"> - <doc> - Requests that the receiving peer destroy a session, implicitly detaching any attached - channels or channel-equivalents. - - Note that the reply, session.closed, is also used for asynchronous exception notifications. - For normal closure, such as in response to a session.close request, reason code 200 ("ok") - is to be used. - </doc> - - <chassis name="client" implement="MUST" /> - <chassis name="server" implement="MUST" /> - - <!-- - <response name="closed" /> - --> - </method> - - <!-- - Method: session.closed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="closed" index="41" label="notify of a session close"> - <doc> - Notifies the receiver that not only has the current channel been detached from its - underlying session, but that the session itself has been destroyed. - - This method confirms a session.close method and tells the recipient that it is safe to - release resources for the channel. - - Note also that for normal closure, reason code 200 ("ok") is to be used. - </doc> - - <chassis name="client" implement="MUST" /> - <chassis name="server" implement="MUST" /> - - <field name="reply-code" domain="reply-code"> - <doc> - The numeric reply code. - </doc> - </field> - - <field name="reply-text" domain="reply-text"> - <doc> - The localised reply text. - </doc> - </field> - </method> - - <!-- - Method: session.resume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="resume" index="50" label="resume an interrupted session"> - <doc> - Attaches to an already-existing session. - </doc> - - <rule name="session-busy"> - <doc> - A "session busy" exception is returned if the session exists, but is not in a condition - where it can accept the requested attachment. Peers receiving this exception may wish to - retain their session state and retry the session.resume operation after a delay. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <response name="attached" /> - - <field name="session-id" domain="session-id"> - <doc> - The session identifier (a UUID) used to identify this session. - </doc> - </field> - </method> - - <!-- - Method: session.suspend - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="suspend" index="90" label="suspend the session"> - <doc> - Indicates the sending peer wishes to detach from this session, but not necessarily to - destroy it. - </doc> - - <!-- TODO: Ratify the inclusion of the chassis element in the XML. --> - <chassis name="server" implement="MAY" /> - - <response name="detached"/> - </method> - - <!-- - Method: session.detached - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="detached" index="100" label="signal detachment of the session"> - <doc> - Signal detachment from the session. - </doc> - <!-- TODO: Ratify the inclusion of the chassis element in the XML. --> - <chassis name="client" implement="MAY" /> - </method> - - <!-- - Method: session.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <!-- TODO: This method does not appear in any grammar as yet... --> - <method name="ack" index="110" label="acknowledge receipt of frames"> - <doc> - Signals receipt of all frames such that frame-id <= cumulative-seen-mark, or frame-id is - in the set defined by seen-frame-set. This can be sent spontaneously, or in response to - either session.solicit-ack or session.high-water-mark. - - Note that an encoded acknowledgement frame carried over the TCP network mapping (in the - absence of cross-protocol use of a session) will never have any entries in its - seen-frame-set. - - <!-- TODO: See chapter (TBD here) for how frame ids are computed. --> - </doc> - - <rule name="unique-encoding"> - <doc> - In order to ensure a canonical wire representation, the value cumulative-seen-mark + - 1 must not be covered by the seen-frame-set. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="cumulative-seen-mark" domain="rfc1982-long" label="Low-water mark for seen ids"> - <doc> - The low-water mark for seen frame-ids. All ids below this mark have been seen; above this - mark, there are gaps containing unseen ids (i.e. discontinuous). By definition, the first - frame-id above this mark (if it exists) is an unseen id. - </doc> - </field> - - <field name="seen-frame-set" domain="rfc1982-long-set" - label="Set of discontinuous seen ids above cumulative-seen-mark"> - <doc> - This set contains a sequence of discontinuous seen-frame-ids above the low-water mark - (i.e. above the first gap of unseen ids). In some transports where out-of-order delivery - is not possible (such as TCP), this set will always be empty. - </doc> - </field> - </method> - - <!-- - Method: session.high-water-mark - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="high-water-mark" index="120" label="Inform the peer of most recent sent frame-id"> - <doc> - Carries information about the highest (most recent) frame-id number that the sending peer - has sent through this session so far. - - The receiver should issue a session.ack at the earliest possible opportunity. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="last-sent-mark" domain="rfc1982-long" label="Frame-id of last sent frame"> - <doc> - Highest frame-id sent by the sending peer through this session so far. - </doc> - </field> - </method> - - <!-- - Method: session.solicit-ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="solicit-ack" index="130" label="request an ack"> - <doc> - Requests a session.ack from the peer. The peer should issue one at the earliest possible - opportunity. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - </method> - - </class> - - <!-- == Class: access ======================================================================== --> - - <!-- TODO 0.82 - this class must be implemented by two teams before we can consider it matured. - --> - - <class name="access" index="30" label="work with access tickets"> - <doc> - The protocol control access to server resources using access tickets. A client must explicitly - request access tickets before doing work. An access ticket grants a client the right to use a - specific set of resources - called a "realm" - in specific ways. - </doc> - - <doc type="grammar"> - access = C:REQUEST S:REQUEST-OK - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <!-- - Method: access.request - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="request" synchronous="1" index="10" label="request an access ticket"> - <doc> - This method requests an access ticket for an access realm. The server responds by granting - the access ticket. If the client does not have access rights to the requested realm this - causes a connection exception. Access tickets are a per-session resource. - </doc> - - <chassis name="server" implement="MUST" /> - - <response name="request-ok" /> - - <field name="realm" domain="shortstr" label="name of requested realm"> - <doc> - Specifies the name of the realm to which the client is requesting access. The realm is a - configured server-side object that collects a set of resources (exchanges, queues, etc.). - If the session has already requested an access ticket onto this realm, the previous ticket - is destroyed and a new ticket is created with the requested access rights, if allowed. - </doc> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST specify a realm that is known to the server. The server makes an - identical response for undefined realms as it does for realms that are defined but - inaccessible to this client. - </doc> - <doc type="scenario"> - Client specifies an undefined realm. - </doc> - </rule> - </field> - - <field name="exclusive" domain="bit" label="request exclusive access"> - <doc> - Request exclusive access to the realm, meaning that this will be the only session that - uses the realm's resources. - </doc> - <rule name="in-use" on-failure="access-refused"> - <doc> - The client MUST NOT request exclusive access to a realm that has active access tickets, - unless the same session already had the only access ticket onto that realm. - </doc> - <doc type="scenario"> - Client opens two sessions and requests exclusive access to the same realm. - </doc> - </rule> - </field> - - <field name="passive" domain="bit" label="request passive access"> - <doc> - Request message passive access to the specified access realm. Passive access lets a client - get information about resources in the realm but not to make any changes to them. - </doc> - </field> - - <field name="active" domain="bit" label="request active access"> - <doc> - Request message active access to the specified access realm. Active access lets a client - get create and delete resources in the realm. - </doc> - </field> - - <field name="write" domain="bit" label="request write access"> - <doc> - Request write access to the specified access realm. Write access lets a client publish - messages to all exchanges in the realm. - </doc> - </field> - - <field name="read" domain="bit" label="request read access"> - <doc> - Request read access to the specified access realm. Read access lets a client consume - messages from queues in the realm. - </doc> - </field> - </method> - - <!-- - Method: access.request-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="request-ok" synchronous="1" index="11" label="grant access to server resources"> - <doc> - This method provides the client with an access ticket. The access ticket is valid within the - current session and for the lifespan of the session. - </doc> - - <rule name="per-session" on-failure="not-allowed"> - <doc> - The client MUST NOT use access tickets except within the same session as originally - granted. - </doc> - <doc type="scenario"> - Client opens two sessions, requests a ticket on one session and then tries to use that - ticket in a second session. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <doc> - A valid access ticket to be used for gaining access to the server. - </doc> - </field> - </method> - - </class> - - <!-- == Class: exchange ====================================================================== --> - - <class name="exchange" index="40" label="work with exchanges"> - <doc> - Exchanges match and distribute messages across queues. Exchanges can be configured in the - server or created at runtime. - </doc> - - <doc type="grammar"> - exchange = C:DECLARE - / C:DELETE - </doc> - - <rule name="required-types"> - <doc> - The server MUST implement these standard exchange types: fanout, direct. - </doc> - <doc type="scenario"> - Client attempts to declare an exchange with each of these standard types. - </doc> - </rule> - - <rule name="recommended-types"> - <doc> - The server SHOULD implement these standard exchange types: topic, headers. - </doc> - <doc type="scenario"> - Client attempts to declare an exchange with each of these standard types. - </doc> - </rule> - - <rule name="required-instances"> - <doc> - The server MUST, in each virtual host, pre-declare an exchange instance for each standard - exchange type that it implements, where the name of the exchange instance, if defined, is - "amq." followed by the exchange type name. - - The server MUST, in each virtual host, pre-declare at least two direct exchange instances: - one named "amq.direct", the other with no public name that serves as a default exchange for - publish methods (such as message.transfer). - </doc> - <doc type="scenario"> - Client creates a temporary queue and attempts to bind to each required exchange instance - ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" if those types are defined). - </doc> - </rule> - - <rule name="default-exchange"> - <doc> - The server MUST pre-declare a direct exchange with no public name to act as the default - exchange for content publish methods (such as message.transfer) and for default queue - bindings. - </doc> - <doc type="scenario"> - Client checks that the default exchange is active by publishing a message with a suitable - routing key but without specifying the exchange name, then ensuring that the message arrives - in the queue correctly. - </doc> - </rule> - - <rule name="default-access"> - <doc> - The default exchange MUST NOT be accessible to the client except by specifying an empty - exchange name in a content publish method (such as message.transfer). That is, the server - must not let clients explicitly bind, unbind, delete, or make any other reference to this - exchange. - </doc> - </rule> - - <rule name="extensions"> - <doc> - The server MAY implement other exchange types as wanted. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <!-- - Method: exchange.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="declare" synchronous="1" index="10" - label="verify exchange exists, create if needed"> - <doc> - This method creates an exchange if it does not already exist, and if the exchange exists, - verifies that it is of the correct and expected class. - </doc> - - <rule name="minimum"> - <doc> - The server SHOULD support a minimum of 16 exchanges per virtual host and ideally, impose - no limit except as defined by available resources. - </doc> - <doc type="scenario"> - The client creates as many exchanges as it can until the server reports an error; the - number of exchanges successfully created must be at least sixteen. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <doc> - When a client defines a new exchange, this belongs to the access realm of the ticket used. - All further work done with that exchange must be done with an access ticket for the same - realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access to the realm in - which the exchange exists or will be created, or "passive" access if the if-exists flag - is set. - </doc> - <doc type="scenario"> - Client creates access ticket with wrong access rights and attempts to use in this - method. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="exchange" domain="exchange-name"> - <rule name="reserved-names" on-failure="access-refused"> - <doc> - Exchange names starting with "amq." are reserved for pre-declared and standardised - exchanges. The client MUST NOT attempt to create an exchange starting with "amq.". - </doc> - </rule> - - <rule name="exchange-name-required" on-failure="not-allowed"> - <doc> - The name of the exchange MUST NOT be a blank or empty string. - </doc> - </rule> - </field> - - <field name="type" domain="shortstr" label="exchange type"> - <doc> - Each exchange belongs to one of a set of exchange types implemented by the server. The - exchange types define the functionality of the exchange - i.e. how messages are routed - through it. It is not valid or meaningful to attempt to change the type of an existing - exchange. - </doc> - - <rule name="typed" on-failure="not-allowed"> - <doc> - Exchanges cannot be redeclared with different types. The client MUST not attempt to - redeclare an existing exchange with a different type than used in the original - Exchange.Declare method. - </doc> - </rule> - - <rule name="support" on-failure="command-invalid"> - <doc> - The client MUST NOT attempt to create an exchange with a type that the server does not - support. - </doc> - </rule> - - <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$" /> - </field> - - <field name="alternate-exchange" domain="exchange-name" - label= "exchange-name for unroutable messages"> - <doc> - In the event that a message cannot be routed, this is the name of the exchange to which - the message will be sent. - </doc> - - <rule name="empty-name"> - <doc> - If alternate-exchange is not set (its name is an empty string), unroutable messages MUST - be dropped silently. - </doc> - </rule> - - <rule name="pre-existing-exchange" on-failure="channel-error"> - <doc> - If the alternate-exchange is not empty and if the exchange already exists with a - different alternate-exchange, then the declaration MUST result in a channel error. - </doc> - </rule> - - <rule name="double-failure"> - <doc> - A message which is being routed to a alternate exchange, MUST NOT be re-routed to a - secondary alternate exchange if it fails to route in the primary alternate exchange. - After such a failure, the message MUST be dropped. This prevents looping. - </doc> - </rule> - </field> - - <field name="passive" domain="bit" label="do not create exchange"> - <doc> - If set, the server will not create the exchange. The client can use this to check whether - an exchange exists without modifying the server state. - </doc> - <rule name="not-found" on-failure="not-found"> - <doc> - If set, and the exchange does not already exist, the server MUST raise a channel - exception with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name="durable" domain="bit" label="request a durable exchange"> - <doc> - If set when creating a new exchange, the exchange will be marked as durable. Durable - exchanges remain active when a server restarts. Non-durable exchanges (transient - exchanges) are purged if/when a server restarts. - </doc> - - <rule name="support"> - <doc> - The server MUST support both durable and transient exchanges. - </doc> - </rule> - - <rule name="sticky"> - <doc> - The server MUST ignore the durable field if the exchange already exists. - </doc> - </rule> - </field> - - <field name="auto-delete" domain="bit" label="auto-delete when unused"> - <doc> - If set, the exchange is deleted when all queues have finished using it. - </doc> - <rule name="sticky"> - <doc> - The server MUST ignore the auto-delete field if the exchange already exists. - </doc> - </rule> - </field> - - <field name="arguments" domain="table" label="arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these arguments - depends on the server implementation. This field is ignored if passive is 1. - </doc> - </field> - </method> - - <!-- - Method: exchange.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="delete" synchronous="1" index="20" label="delete an exchange"> - <doc> - This method deletes an exchange. When an exchange is deleted all queue bindings on the - exchange are cancelled. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to the - exchange's access realm. - </doc> - <doc type="scenario"> - Client creates access ticket with wrong access rights and attempts to use in this - method. - </doc> - </rule> - </field> - - <field name="exchange" domain="exchange-name"> - <rule name="exists" on-failure="not-found"> - <doc> - The client MUST NOT attempt to delete an exchange that does not exist. - </doc> - </rule> - - <rule name="exchange-name-required" on-failure="not-allowed"> - <doc> - The name of the exchange MUST NOT be a blank or empty string. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <!-- TODO 0.82 - discuss whether this option is useful or not. I don't have any real use case - for it. /PH 2006-07-23. - --> - <field name="if-unused" domain="bit" label="delete only if unused"> - <doc> - If set, the server will only delete the exchange if it has no queue bindings. If the - exchange has queue bindings the server does not delete it but raises a channel exception - instead. - </doc> - </field> - </method> - - <!-- - Method: exchange.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="query" synchronous="1" index="30" label="request information about an exchange"> - <doc> - This method is used to request information on a particular exchange. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - exchange's access realm. - </doc> - </rule> - </field> - - <field name="name" domain="shortstr" label="the exchange name"> - <doc> - The name of the exchange for which information is requested. If not specified explicitly - the default exchange is implied. - </doc> - </field> - - <result> - <struct size="long" type="31"> - <doc> - This is sent in response to a query request and conveys information on a particular - exchange. - </doc> - - <field name="type" domain="shortstr" label="indicate the exchange type"> - <doc> - The type of the exchange. Will be empty if the exchange is not found. - </doc> - </field> - - <field name="durable" domain="bit" label="indicate the durability"> - <doc> - The durability of the exchange, i.e. if set the exchange is durable. Will not be set if - the exchange is not found. - </doc> - </field> - - <field name="not-found" domain="bit" label="indicate an unknown exchange"> - <doc> - If set, the exchange for which information was requested is not known. - </doc> - </field> - - <field name="arguments" domain="table" label="other unspecified exchange properties"> - <doc> - A set of properties of the exchange whose syntax and semantics depends on the server - implementation. Will be empty if the exchange is not found. - </doc> - </field> - </struct> - </result> - </method> - - </class> - - <!-- == Class: queue ========================================================================= --> - - <class name="queue" index="50" label="work with queues"> - <doc> - Queues store and forward messages. Queues can be configured in the server or created at - runtime. Queues must be attached to at least one exchange in order to receive messages from - publishers. - </doc> - - <doc type="grammar"> - queue = C:DECLARE - / C:BIND - / C:PURGE - / C:DELETE - / C:QUERY - / C:UNBIND - </doc> - - <rule name="any-content"> - <doc> - A server MUST allow any content class to be sent to any queue, in any mix, and queue and - deliver these content classes independently. Note that all methods that fetch content off - queues are specific to a given content class. - </doc> - <doc type="scenario"> - Client creates an exchange of each standard type and several queues that it binds to each - exchange. It must then successfully send each of the standard content types to each of the - available queues. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <!-- - Method: queue.declare - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="declare" synchronous="1" index="10" label="declare queue, create if needed"> - <doc> - This method creates or checks a queue. When creating a new queue the client can specify - various properties that control the durability of the queue and its contents, and the level - of sharing for the queue. - </doc> - - <rule name="default-binding"> - <doc> - The server MUST create a default binding for a newly-created queue to the default - exchange, which is an exchange of type 'direct' and use the queue name as the routing key. - </doc> - <doc type="scenario"> - Client creates a new queue, and then without explicitly binding it to an exchange, - attempts to send a message through the default exchange binding, i.e. publish a message to - the empty exchange, with the queue name as routing key. - </doc> - </rule> - - <rule name="minimum-queues"> - <doc> - The server SHOULD support a minimum of 256 queues per virtual host and ideally, impose no - limit except as defined by available resources. - </doc> - <doc type="scenario"> - Client attempts to create as many queues as it can until the server reports an error. The - resulting count must at least be 256. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <doc> - When a client defines a new queue, this belongs to the access realm of the ticket used. - All further work done with that queue must be done with an access ticket for the same - realm. - </doc> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access to the realm in - which the queue exists or will be created. - </doc> - <doc type="scenario"> - Client creates access ticket with wrong access rights and attempts to use in this - method. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <rule name="reserved-prefix" on-failure="not-allowed"> - <doc> - Queue names starting with "amq." are reserved for pre-declared and standardised server - queues. A client MUST NOT attempt to declare a queue with a name that starts with "amq." - and the passive option set to zero. - </doc> - <doc type="scenario"> - A client attempts to create a queue with a name starting with "amq." and with the - passive option set to zero. - </doc> - </rule> - </field> - - <field name="alternate-exchange" domain="exchange-name" - label= "exchange-name for messages with exceptions"> - <doc> - If a message is rejected by a queue, then it is sent to the alternate-exchange. A message - may be rejected by a queue for the following reasons: - 1. The queue is deleted when it is not empty; - 2. Immediate delivery of a message is requested, but there are no consumers connected to - the queue. - </doc> - - <rule name="empty"> - <doc> - If alternate-exchange is not set (its name is an empty string), rejected messages MUST - be dropped silently. - </doc> - </rule> - - <rule name="pre-existing-exchange" on-failure="channel-error"> - <doc> - If the alternate-exchange is not empty and if the queue already exists with a different - alternate-exchange, then the declaration MUST result in a channel error. - </doc> - </rule> - - <rule name="delete-exchange" on-failure="channel-error"> - <doc> - The alternate-exchange MUST NOT be deleted while a queue bound to it still exists. Such - an attempt MUST result in a channel exception. - </doc> - </rule> - </field> - - <field name="passive" domain="bit" label="do not create queue"> - <doc> - If set, the server will not create the queue. This field allows the client to assert the - presence of a queue without modifying the server state. - </doc> - - <rule name="passive" on-failure="not-found"> - <doc> - The client MAY ask the server to assert that a queue exists without creating the queue - if not. If the queue does not exist, the server treats this as a failure. - </doc> - <doc type="scenario"> - Client declares an existing queue with the passive option and expects the command to - succeed. Client then attempts to declare a non-existent queue with the passive option, - and the server must close the channel with the correct reply-code. - </doc> - </rule> - </field> - - <field name="durable" domain="bit" label="request a durable queue"> - <doc> - If set when creating a new queue, the queue will be marked as durable. Durable queues - remain active when a server restarts. Non-durable queues (transient queues) are purged - if/when a server restarts. Note that durable queues do not necessarily hold persistent - messages, although it does not make sense to send persistent messages to a transient - queue. - </doc> - - <rule name="persistence"> - <doc> - The server MUST recreate the durable queue after a restart. - </doc> - <doc type="scenario"> - Client creates a durable queue; server is then restarted. Client then attempts to send - message to the queue. The message should be successfully delivered. - </doc> - </rule> - - <rule name="types"> - <doc> - The server MUST support both durable and transient queues. - </doc> - <doc type="scenario"> - A client creates two named queues, one durable and one transient. - </doc> - </rule> - - <rule name="pre-existence"> - <doc> - The server MUST ignore the durable field if the queue already exists. - </doc> - <doc type="scenario"> - A client creates two named queues, one durable and one transient. The client then - attempts to declare the two queues using the same names again, but reversing the value - of the durable flag in each case. Verify that the queues still exist with the original - durable flag values. - <!-- TODO: but how? --> - </doc> - </rule> - </field> - - <field name="exclusive" domain="bit" label="request an exclusive queue"> - <doc> - Exclusive queues can only be used from one connection at a time. Once a connection - declares an exclusive queue, that queue cannot be used by any other connections until the - declaring connection closes. - </doc> - - <rule name="types"> - <doc> - The server MUST support both exclusive (private) and non-exclusive (shared) queues. - </doc> - <doc type="scenario"> - A client creates two named queues, one exclusive and one non-exclusive. - </doc> - </rule> - - <rule name="in-use" on-failure="resource-locked"> - <doc> - If the server receives a declare, bind, consume or get request for a queue that has been - declared as exclusive by an existing client connection, it MUST raise a channel - exception. - </doc> - <doc type="scenario"> - A client declares an exclusive named queue. A second client on a different connection - attempts to declare a queue of the same name. - </doc> - </rule> - </field> - - <field name="auto-delete" domain="bit" label="auto-delete queue when unused"> - <doc> - If this field is set and the exclusive field is also set, then the queue MUST be deleted - when the connection closes. - - If this field is set and the exclusive field is not set the queue is deleted when all - the consumers have finished using it. Last consumer can be cancelled either explicitly - or because its channel is closed. If there was no consumer ever on the queue, it won't - be deleted. - </doc> - - <rule name="pre-existence"> - <doc> - The server MUST ignore the auto-delete field if the queue already exists. - </doc> - <doc type="scenario"> - A client creates two named queues, one as auto-delete and one explicit-delete. The - client then attempts to declare the two queues using the same names again, but reversing - the value of the auto-delete field in each case. Verify that the queues still exist with - the original auto-delete flag values. - <!-- TODO: but how? --> - </doc> - </rule> - </field> - - <field name="arguments" domain="table" label="arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these arguments - depends on the server implementation. This field is ignored if passive is 1. - </doc> - </field> - </method> - - <!-- - Method: queue.bind - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="bind" synchronous="1" index="20" label="bind queue to an exchange"> - <doc> - This method binds a queue to an exchange. Until a queue is bound it will not receive any - messages. In a classic messaging model, store-and-forward queues are bound to a direct - exchange and subscription queues are bound to a topic exchange. - </doc> - - <rule name="duplicates"> - <doc> - A server MUST allow ignore duplicate bindings - that is, two or more bind methods for a - specific queue, with identical arguments - without treating these as an error. - </doc> - <doc type="scenario"> - A client binds a named queue to an exchange. The client then repeats the bind (with - identical arguments). - </doc> - </rule> - - <rule name="failure"> - <!-- - TODO: Find correct on-failure code. The on-failure code returned should depend on why the - bind failed. Assuming that failures owing to bad parameters are covered in the rules - relating to those parameters, the only remaining reason for a failure would be the lack of - server resorces or some internal error - such as too many queues open. Would these cases - qualify as "resource error" 506 or "internal error" 541? - --> - <doc> - If a bind fails, the server MUST raise a connection exception. - </doc> - </rule> - - <rule name="transient-exchange" on-failure="not-allowed"> - <doc> - The server MUST NOT allow a durable queue to bind to a transient exchange. - </doc> - <doc type="scenario"> - A client creates a transient exchange. The client then declares a named durable queue and - then attempts to bind the transient exchange to the durable queue. - </doc> - </rule> - - <rule name="durable-exchange"> - <doc> - Bindings for durable queues are automatically durable and the server SHOULD restore such - bindings after a server restart. - </doc> - <doc type="scenario"> - A server creates a named durable queue and binds it to a durable exchange. The server is - restarted. The client then attempts to use the queue/exchange combination. - </doc> - </rule> - - <rule name="internal-exchange" on-failure="not-allowed"> - <doc> - If the client attempts to bind to an exchange that was declared as internal, the server - MUST raise a connection exception with reply code 530 (not allowed). - </doc> - <doc type="scenario"> - A client attempts to bind a named queue to an internal exchange. - </doc> - </rule> - - <rule name="binding-count"> - <doc> - The server SHOULD support at least 4 bindings per queue, and ideally, impose no limit - except as defined by available resources. - </doc> - <doc type="scenario"> - A client creates a named queue and attempts to bind it to 4 different non-internal - exchanges. - </doc> - </rule> - - <rule name="multiple-bindings"> - <doc> - Where more than one binding exists between a particular exchange instance and a particular - queue instance any given message published to that exchange should be delivered to that - queue at most once, regardless of how many distinct bindings match. - </doc> - <doc type="scenario"> - A client creates a named queue and binds it to the same topic exchange at least three - times using intersecting routing keys (for example, "animals.*", "animals.dogs.*", - "animal.dogs.chihuahua"). Verify that a message matching all the bindings (using previous - example, routing key = "animal.dogs.chihuahua") is delivered once only. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client provides a valid access ticket giving "active" access rights to the queue's - access realm. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to bind. If the queue name is empty, refers to the current - queue for the session, which is the last declared queue. - </doc> - - <rule name="empty-queue" on-failure="not-allowed"> - <doc> - A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. empty queue - name) to an exchange. - </doc> - <doc type="scenario"> - A client attempts to bind with an unnamed (empty) queue name to an exchange. - </doc> - </rule> - - <rule name="queue-existence" on-failure="not-found"> - <doc> - A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously declared) - to an exchange. - </doc> - <doc type="scenario"> - A client attempts to bind an undeclared queue name to an exchange. - </doc> - </rule> - </field> - - <field name="exchange" domain="exchange-name" label="name of the exchange to bind to"> - <rule name="exchange-existence" on-failure="not-found"> - <doc> - A client MUST NOT be allowed to bind a queue to a non-existent exchange. - </doc> - <doc type="scenario"> - A client attempts to bind a named queue to a undeclared exchange. - </doc> - </rule> - - <rule name="exchange-name-required" on-failure="not-allowed"> - <doc> - The name of the exchange MUST NOT be a blank or empty string. - </doc> - </rule> - </field> - - <field name="routing-key" domain="shortstr" label="message routing key"> - <doc> - Specifies the routing key for the binding. The routing key is used for routing messages - depending on the exchange configuration. Not all exchanges use a routing key - refer to - the specific exchange documentation. If the queue name is empty, the server uses the last - queue declared on the session. If the routing key is also empty, the server uses this - queue name for the routing key as well. If the queue name is provided but the routing key - is empty, the server does the binding with that empty routing key. The meaning of empty - routing keys depends on the exchange implementation. - </doc> - <rule name="direct-exchange-key-matching"> - <doc> - If a message queue binds to a direct exchange using routing key K and a publisher sends - the exchange a message with routing key R, then the message MUST be passed to the - message queue if K = R. - </doc> - </rule> - </field> - - <field name="arguments" domain="table" label="arguments for binding"> - <doc> - A set of arguments for the binding. The syntax and semantics of these arguments depends on - the exchange class. - </doc> - </field> - </method> - - <!-- - Method: queue.unbind - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="unbind" synchronous="1" index="50" label="unbind a queue from an exchange"> - <doc> - This method unbinds a queue from an exchange. - </doc> - - <rule name="failure"> - <doc> - If a unbind fails, the server MUST raise a connection exception. - <!-- TODO: define failure code --> - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client provides a valid access ticket giving "active" access rights to the queue's - access realm. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to unbind. - </doc> - <rule name="non-existent-queue" on-failure="not-found"> - <doc> - If the queue does not exist the server MUST raise a channel exception with reply code - 404 (not found). - </doc> - </rule> - </field> - - <field name="exchange" domain="exchange-name"> - <doc> - The name of the exchange to unbind from. - </doc> - - <rule name="non-existent-exchange" on-failure="not-found"> - <doc> - If the exchange does not exist the server MUST raise a channel exception with reply code - 404 (not found). - </doc> - </rule> - - <rule name="exchange-name-required" on-failure="not-allowed"> - <doc> - The name of the exchange MUST NOT be a blank or empty string. - </doc> - </rule> - </field> - - <field name="routing-key" domain="shortstr" label="routing key of binding"> - <doc> - Specifies the routing key of the binding to unbind. - </doc> - </field> - - <field name="arguments" domain="table" label="arguments of binding"> - <doc> - Specifies the arguments of the binding to unbind. - </doc> - </field> - </method> - - <!-- - Method: queue.purge - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="purge" synchronous="1" index="30" label="purge a queue"> - <doc> - This method removes all messages from a queue. It does not cancel consumers. Purged messages - are deleted without any formal "undo" mechanism. - </doc> - - <rule name="empty"> - <doc> - A call to purge MUST result in an empty queue. - </doc> - </rule> - - <rule name="tx-exception"> - <doc> - On transacted sessions the server MUST not purge messages that have already been sent to a - client but not yet acknowledged. - </doc> - </rule> - - <rule name="purge-recovery"> - <doc> - The server MAY implement a purge queue or log that allows system administrators to recover - accidentally-purged messages. The server SHOULD NOT keep purged messages in the same - storage spaces as the live messages since the volumes of purged messages may get very - large. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the queue's - access realm. Note that purging a queue is equivalent to reading all messages and - discarding them. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to purge. If the queue name is empty, refers to the - current queue for the session, which is the last declared queue. - </doc> - - <rule name="empty-name" on-failure="not-allowed"> - <doc> - If the client did not previously declare a queue, and the queue name in this method is - empty, the server MUST raise a connection exception with reply code 530 (not allowed). - </doc> - </rule> - - <rule name="queue-exists" on-failure="not-found"> - <doc> - The queue MUST exist. Attempting to purge a non-existing queue MUST cause a channel - exception with reply code 404 (not found). - </doc> - </rule> - </field> - </method> - - <!-- - Method: queue.delete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="delete" synchronous="1" index="40" label="delete a queue"> - <doc> - This method deletes a queue. When a queue is deleted any pending messages are sent to a - dead-letter queue if this is defined in the server configuration, and all consumers on the - queue are cancelled. - </doc> - - <rule name="dead-letter-queue"> - <doc> - The server SHOULD use a dead-letter queue to hold messages that were pending on a deleted - queue, and MAY provide facilities for a system administrator to move these messages back - to an active queue. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client provides a valid access ticket giving "active" access rights to the queue's - access realm. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to delete. If the queue name is empty, refers to the - current queue for the session, which is the last declared queue. - </doc> - - <rule name="empty-name" on-failure="not-allowed"> - <doc> - If the client did not previously declare a queue, and the queue name in this method is - empty, the server MUST raise a connection exception with reply code 530 (not allowed). - </doc> - </rule> - - <rule name="queue-exists" on-failure="not-found"> - <doc> - The queue must exist. If the client attempts to delete a non-existing queue the server - MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name="if-unused" domain="bit" label="delete only if unused"> - <doc> - If set, the server will only delete the queue if it has no consumers. If the queue has - consumers the server does does not delete it but raises a channel exception instead. - </doc> - - <rule name="if-unused-flag"> - <doc> - The server MUST respect the if-unused flag when deleting a queue. - </doc> - </rule> - </field> - - <field name="if-empty" domain="bit" label="delete only if empty"> - <doc> - If set, the server will only delete the queue if it has no messages. - </doc> - <rule name="not-empty" on-failure="precondition-failed"> - <doc> - If the queue is not empty the server MUST raise a channel exception with reply code 406 - (precondition failed). - </doc> - </rule> - </field> - </method> - - <!-- - Method: queue.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="query" synchronous="1" index="60" label="request information about a queue"> - <doc> - This method requests information about a queue. - </doc> - - <chassis name="server" implement="MUST" /> - - - <field name="queue" domain="queue-name" label="the queried queue"> - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="61"> - <doc> - This is sent in response to queue.query, and conveys the requested information about a - queue. - </doc> - - <field name="queue" domain="queue-name"> - <doc> - Reports the name of the queue. - </doc> - <assert check="notnull" /> - </field> - - <field name="alternate-exchange" domain="exchange-name" /> - - <field name="durable" domain="bit" /> - - <field name="exclusive" domain="bit" /> - - <field name="auto-delete" domain="bit" /> - - <field name="arguments" domain="table" /> - - <field name="message-count" domain="long" label="number of messages in queue"> - <doc> - Reports the number of messages in the queue. - </doc> - </field> - - <field name="consumer-count" domain="long" label="number of consumers"> - <doc> - Reports the number of active consumers for the queue. Note that consumers can suspend - activity (Session.Flow) in which case they do not appear in this count. - </doc> - </field> - </struct> - </result> - </method> - - </class> - - <!-- == Class: basic ========================================================================= --> - - <class name="basic" index="60" label="[DEPRECATED] work with basic content"> - <doc> - [DEPRECATED: replaced by message class.] The Basic class provides methods that support an - industry-standard messaging model. - </doc> - - <doc type="grammar"> - basic = C:QOS - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT - </doc> - - <rule name="persistence"> - <doc> - The server SHOULD respect the persistent property of basic messages and SHOULD make a - best-effort to hold persistent basic messages on a reliable storage mechanism. - </doc> - <doc type="scenario"> - Send a persistent message to queue, stop server, restart server and then verify whether - message is still present. Assumes that queues are durable. Persistence without durable - queues makes no sense. - </doc> - </rule> - - <rule name="persistent-overflow"> - <doc> - The server MUST NOT discard a persistent basic message in case of a queue overflow. - </doc> - <doc type="scenario"> - Create a queue overflow situation with persistent messages and verify that messages do not - get lost (presumably the server will write them to disk). - </doc> - </rule> - - <rule name="throttling"> - <doc> - The server MAY use the Session.Flow method to slow or stop a basic message publisher when - necessary. - </doc> - <doc type="scenario"> - Create a queue overflow situation with non-persistent messages and verify whether the server - responds with Session.Flow or not. Repeat with persistent messages. - </doc> - </rule> - - <rule name="non-persistent-overflow"> - <doc> - The server MAY overflow non-persistent basic messages to persistent storage. - </doc> - <!-- Test scenario: untestable --> - </rule> - - <rule name="dead-letter-overflow"> - <doc> - The server MAY discard or dead-letter non-persistent basic messages on a priority basis if - the queue size exceeds some configured limit. - </doc> - <!-- Test scenario: untestable --> - </rule> - - <rule name="min-priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for basic messages, where priorities - 0-4 and 5-9 are treated as two distinct levels. - </doc> - <doc type="scenario"> - Send a number of priority 0 messages to a queue. Send one priority 9 message. Consume - messages from the queue and verify that the first message received was priority 9. - </doc> - </rule> - - <rule name="max-priority-levels"> - <doc> - The server MAY implement up to 10 priority levels. - </doc> - <doc type="scenario"> - Send a number of messages with mixed priorities to a queue, so that all priority values from - 0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume - from queue and verify how many priority levels emerge. - </doc> - </rule> - - <rule name="priority"> - <doc> - The server MUST deliver messages of the same priority in order irrespective of their - individual persistence. - </doc> - <doc type="scenario"> - Send a set of messages with the same priority but different persistence settings to a queue. - Consume and verify that messages arrive in same order as originally published. - </doc> - </rule> - - <rule name="automatic-acknowledgement"> - <doc> - The server MUST support automatic acknowledgements on Basic content, i.e. consumers with the - no-ack field set to FALSE. - </doc> - <doc type="scenario"> - Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to - the queue. Consume the messages and verify that all messages are received. - </doc> - </rule> - - <rule name="explicit-acknowledgement"> - <doc> - The server MUST support explicit acknowledgements on Basic content, i.e. consumers with the - no-ack field set to TRUE. - </doc> - <doc type="scenario"> - Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to - the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect, - and consume from the queue. Verify that the remaining messages are received. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MAY" /> - - <!-- These are the properties for a Basic content --> - - <field name="content-type" domain="shortstr" label="MIME content type" /> - <field name="content-encoding" domain="shortstr" label="MIME content encoding" /> - <field name="headers" domain="table" label="message header field table" /> - <field name="delivery-mode" domain="octet" label="non-persistent (1) or persistent (2)" /> - <field name="priority" domain="octet" label="message priority, 0 to 9" /> - <field name="correlation-id" domain="shortstr" label="application correlation identifier" /> - <field name="reply-to" domain="shortstr" label="destination to reply to" /> - <field name="expiration" domain="shortstr" label="message expiration specification" /> - <field name="message-id" domain="shortstr" label="application message identifier" /> - <field name="timestamp" domain="timestamp" label="message timestamp" /> - <field name="type" domain="shortstr" label="message type name" /> - <field name="user-id" domain="shortstr" label="creating user id" /> - <field name="app-id" domain="shortstr" label="creating application id" /> - - <!-- - Method: basic.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="qos" synchronous="1" index="10" label="[DEPRECATED] specify quality of service"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method requests a specific quality of - service. The QoS can be specified for the current session or for all sessions on the - connection. The particular properties and semantics of a qos method always depend on the - content class semantics. Though the qos method could in principle apply to both peers, it is - currently meaningful only for the server. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="prefetch-size" domain="long" label="prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. The server will send a message in advance if - it is equal to or smaller in size than the available prefetch size (and also falls into - other prefetch limits). May be set to zero, meaning "no specific limit", although other - prefetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - - <rule name="ignore"> - <doc> - The server MUST ignore this setting when the client is not processing any messages - - i.e. the prefetch size does not limit the transfer of single messages to a client, only - the sending in advance of more messages while the client still has one or more - unacknowledged messages. - </doc> - <doc type="scenario"> - Define a QoS prefetch-size limit and send a single message that exceeds that limit. - Verify that the message arrives correctly. - </doc> - </rule> - </field> - - <field name="prefetch-count" domain="short" label="prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - prefetch windows (and those at the session and connection level) allow it. The - prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name="prefetch"> - <doc> - The server may send less data in advance than allowed by the client's specified prefetch - windows but it MUST NOT send more. - </doc> - <doc type="scenario"> - Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send - multiple messages that exceed the prefetch size. Verify that no more than one message - arrives at once. - </doc> - </rule> - </field> - - <field name="global" domain="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </method> - - <!-- - Method: basic.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="consume" synchronous="1" index="20" label="[DEPRECATED] start a queue consumer"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method asks the server to start a - "consumer", which is a transient request for messages from a specific queue. Consumers last - as long as the session they were created on, or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, and ideally, impose no limit - except as defined by available resources. - </doc> - <doc type="scenario"> - Create a queue and create consumers on that queue until the server closes the connection. - Verify that the number of consumers created was at least sixteen and report the total - number. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <response name="consume-ok" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - </doc> - <doc type="scenario"> - Attempt to create a consumer with an invalid (non-zero) access ticket. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - </doc> - <rule name="queue-exists-if-empty" on-failure="not-allowed"> - <doc> - If the queue name is empty the client MUST have previously declared a queue using this - session. - </doc> - <doc type="scenario"> - Attempt to create a consumer with an empty queue name and no previously declared queue - on the session. - </doc> - </rule> - </field> - - <field name="consumer-tag" domain="consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. If this field is empty the server will - generate a unique tag. - </doc> - - <rule name="not-existing-consumer" on-failure="not-allowed"> - <doc> - The client MUST NOT specify a tag that refers to an existing consumer. - </doc> - <doc type="scenario"> - Attempt to create two consumers with the same non-empty tag. - </doc> - </rule> - - <rule name="session-bound" on-failure="not-allowed"> - <doc> - The consumer tag is valid only within the session from which the consumer was created. - i.e. A client MUST NOT create a consumer in one session and then use it in another. - </doc> - <doc type="scenario"> - Attempt to create a consumer in one session, then use in another session, in which - consumers have also been created (to test that the server uses unique consumer tags). - </doc> - </rule> - </field> - - <field name="no-local" domain="no-local" /> - - <field name="no-ack" domain="no-ack" /> - - <field name="exclusive" domain="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <rule name="in-use" on-failure="access-refused"> - <doc> - The client MUST NOT gain exclusive access to a queue that already has active consumers. - </doc> - <doc type="scenario"> - Open two connections to a server, and in one connection create a shared (non-exclusive) - queue and then consume from the queue. In the second connection attempt to consume from - the same queue using the exclusive option. - </doc> - </rule> - </field> - - <field name="nowait" domain="bit" label="do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait for a reply - method. If the server could not complete the method it will raise a channel or connection - exception. - </doc> - </field> - - <field name="arguments" domain="table" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </method> - - <!-- - Method: basic.consume-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="consume-ok" synchronous="1" index="21" - label="[DEPRECATED] confirm a new consumer"> - <doc> - [DEPRECATED: Basic replaced by message class.] The server provides the client with a - consumer tag, which is used by the client for methods called on the consumer at a later - stage. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </method> - - <!-- - Method: basic.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="cancel" synchronous="1" index="30" label="[DEPRECATED] end a queue consumer"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method cancels a consumer. This does not - affect already delivered messages, but it does mean the server will not send any more - messages for that consumer. The client may receive an arbitrary number of messages in - between sending the cancel method and receiving notification of the completion of the cancel command. - </doc> - - <rule name="non-existent"> - <doc> - If the queue does not exist the server MUST ignore the cancel method, so long as the - consumer tag is valid for that session. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag" /> - </method> - - <!-- - Method: basic.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="publish" content="1" index="40" label="[DEPRECATED] publish a message"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method publishes a message to a specific - exchange. The message will be routed to queues as defined by the exchange configuration and - distributed to any active consumers when the transaction, if any, is committed. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - </doc> - </rule> - </field> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise a channel exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name="internal" on-failure="access-refused"> - <doc> - If the exchange was declared as an internal exchange, the server MUST raise a channel - exception with a reply code 403 (access refused). - </doc> - </rule> - - <rule name="refusal" on-failure="not-implemented"> - <doc> - The exchange MAY refuse basic content in which case it MUST raise a channel exception - with reply code 540 (not implemented). - </doc> - </rule> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="reject-unroutable" domain="bit" label="reject message if unroutable flag"> - <doc> - If the reject-unroutable flag is set, then at the time of publishing the broker - determines if the message will be routed to any queues. If it will not be routed to any - queue then the broker responds with a basic.reject. - </doc> - </field> - - <field name="immediate" domain="bit" label="Request immediate delivery"> - <doc> - If this flag is set, and the resulting message is delivered to a queue with no - consumers, the message will not be queued but will instead be routed to the - alternate-exchange for that queue. If no such exchange is defined the message will be - silently dropped. - </doc> - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - </method> - - <!-- - Method: basic.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="deliver" content="1" index="60" - label="[DEPRECATED] notify the client of a consumer message"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method delivers a message to the client, - via a consumer. In the asynchronous message delivery model, the client starts a consumer - using the Consume method, then the server responds with Deliver methods as and when messages - arrive for that consumer. - </doc> - - <rule name="redelivery-tracking"> - <doc> - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be unprocessable (possibly causing - client applications to abort), and move the message to a dead letter queue. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="redelivered" domain="redelivered" /> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - </method> - - <!-- - Method: basic.get - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="get" synchronous="1" index="70" label="[DEPRECATED] direct access to a queue"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method provides a direct access to the - messages in a queue using a synchronous dialogue that is designed for specific types of - application where synchronous functionality is more important than performance. - </doc> - - <chassis name="server" implement="MUST" /> - - <response name="get-ok" /> - <response name="get-empty" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be obtained. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - </doc> - <rule name="queue-exists-if-empty"> - <doc> - If the client did not previously declare a queue, and the queue name in this method is - empty, the server MUST raise a connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name="no-ack" domain="no-ack" /> - </method> - - <!-- - Method: basic.get-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="get-ok" synchronous="1" content="1" index="71" - label="[DEPRECATED] provide client with a message"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method delivers a message to the client - following a get method. A message delivered by 'get-ok' must be acknowledged unless the - no-ack option was set in the get method. - </doc> - - <chassis name="client" implement="MAY" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="redelivered" domain="redelivered" /> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. If empty, - the message was published to the default exchange. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <field name="message-count" domain="long" label="number of messages pending"> - <doc> - This field reports the number of messages pending on the queue, excluding the message - being delivered. Note that this figure is indicative, not reliable, and can change - arbitrarily as messages are added to the queue and removed by other clients. - </doc> - </field> - </method> - - <!-- - Method: basic.get-empty - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="get-empty" synchronous="1" index="72" - label="[DEPRECATED] indicate no messages available"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method tells the client that the queue - has no messages available for the client. - </doc> - - <chassis name="client" implement="MAY" /> - - <!-- This field is deprecated pending review --> - <field name="cluster-id" domain="shortstr" label="Cluster id"> - <doc> - For use by cluster applications, should not be used by client applications. - </doc> - </field> - </method> - - <!-- - Method: basic.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="ack" index="80" label="[DEPRECATED] acknowledge one or more messages"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method acknowledges one or more messages - delivered via the Deliver or Get-Ok methods. The client can ask to confirm a single message - or a set of messages up to and including a specific message. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="multiple" domain="bit" label="acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages with a single method. If set to zero, the delivery tag - refers to a single message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding messages. - </doc> - - <rule name="validation"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to a delivered message, and - raise a channel exception if this is not the case. - </doc> - </rule> - </field> - </method> - - <!-- - Method: basic.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="reject" index="90" label="[DEPRECATED] reject an incoming message"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method allows a client to reject a - message. It can be used to interrupt and cancel large incoming messages, or return - untreatable messages to their original queue. - </doc> - - <rule name="concurrent-processing"> - <doc> - The server SHOULD be capable of accepting and processing the Reject method while sending - message content with a Deliver or Get-Ok method. i.e. The server should read and process - incoming methods while sending output frames. To cancel a partially-send content, the - server sends a content body frame of size 1 (i.e. with no data except the frame-end - octet). - </doc> - </rule> - - <rule name="server-interpretation"> - <doc> - The server SHOULD interpret this method as meaning that the client is unable to process - the message at this time. - </doc> - </rule> - - <rule name="not-selection"> - <doc> - A client MUST NOT use this method as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="requeue" domain="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - </doc> - - <rule name="requeue-strategy"> - <doc> - The server MUST NOT deliver the message to the same client within the context of the - current session. The recommended strategy is to attempt to deliver the message to an - alternative consumer, and if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold the message on the queue - and redeliver it to the same client at a later stage. - </doc> - </rule> - </field> - </method> - - <!-- - Method: basic.recover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="recover" index="100" label="[DEPRECATED] redeliver unacknowledged messages"> - <doc> - [DEPRECATED: Basic replaced by message class.] This method asks the broker to redeliver all - unacknowledged messages on a specified session. Zero or more messages may be redelivered. - This method is only allowed on non-transacted sessions. - </doc> - - <rule name="redelivered-flag"> - <doc> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - </rule> - - <rule name="non-transacted-session"> - <doc> - The server MUST raise a channel exception if this is called on a transacted session. - <!-- TODO: define failure code --> - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="requeue" domain="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be redelivered to the original recipient. If this - bit is 1, the server will attempt to requeue the message, potentially then delivering it - to an alternative subscriber. - </doc> - </field> - </method> - - </class> - - <!-- == Class: file ========================================================================== --> - - <class name="file" index="70" label="work with file content"> - <doc> - The file class provides methods that support reliable file transfer. File messages have a - specific set of properties that are required for interoperability with file transfer - applications. File messages and acknowledgements are subject to session transactions. Note - that the file class does not provide message browsing methods; these are not compatible with - the staging model. Applications that need browsable file transfer should use Basic content and - the Basic class. - </doc> - - <doc type="grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - </doc> - - <rule name="reliable-storage"> - <doc> - The server MUST make a best-effort to hold file messages on a reliable storage mechanism. - </doc> - </rule> - - <!-- TODO Rule implement attr inverse? --> - - <rule name="no-discard"> - <doc> - The server MUST NOT discard a file message in case of a queue overflow. The server MUST use - the Session.Flow method to slow or stop a file message publisher when necessary. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for file messages, where priorities 0-4 - and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST support both automatic and explicit acknowledgements on file content. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - <chassis name="client" implement="MAY" /> - - <!-- These are the properties for a File content --> - - <field name="content-type" domain="shortstr" label="MIME content type" /> - <field name="content-encoding" domain="shortstr" label="MIME content encoding" /> - <field name="headers" domain="table" label="message header field table" /> - <field name="priority" domain="octet" label="message priority, 0 to 9" /> - <field name="reply-to" domain="shortstr" label="destination to reply to" /> - <field name="message-id" domain="shortstr" label="application message identifier" /> - <field name="filename" domain="shortstr" label="message filename" /> - <field name="timestamp" domain="timestamp" label="message timestamp" /> - <!-- This field is deprecated pending review --> - <field name="cluster-id" domain="shortstr" label="intra-cluster routing identifier" /> - - <!-- - Method: file.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="qos" synchronous="1" index="10" label="specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the current - session or for all sessions on the connection. The particular properties and semantics of a - qos method always depend on the content class semantics. Though the qos method could in - principle apply to both peers, it is currently meaningful only for the server. - </doc> - - <chassis name="server" implement="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" domain="long" label="prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other prefetch limits may still apply. The prefetch-size is ignored if - the no-ack option is set. - </doc> - </field> - - <field name="prefetch-count" domain="short" label="prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This is compatible with some file - API implementations. This field may be used in combination with the prefetch-size field; a - message will only be sent in advance if both prefetch windows (and those at the session - and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name="prefetch-discretion"> - <doc> - The server MAY send less data in advance than allowed by the client's specified prefetch - windows but it MUST NOT send more. - </doc> - </rule> - </field> - - <field name="global" domain="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </method> - - <!-- - Method: file.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="qos-ok" synchronous="1" index="11" label="confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <chassis name="client" implement="MUST" /> - </method> - - <!-- - Method: file.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="consume" synchronous="1" index="20" label="start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for messages - from a specific queue. Consumers last as long as the session they were created on, or until - the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <response name="consume-ok" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - </doc> - - <rule name="queue-exists-if-empty" on-failure="not-allowed"> - <doc> - If the client did not previously declare a queue, and the queue name in this method is - empty, the server MUST raise a connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name="consumer-tag" domain="consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. If this field is empty the server will - generate a unique tag. - </doc> - - <rule name="not-existing-consumer" on-failure="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise a connection exception with - reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name="no-local" domain="no-local" /> - - <field name="no-ack" domain="no-ack" /> - - <field name="exclusive" domain="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <rule name="in-use" on-failure="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise a channel exception with return code 405 - (resource locked). - </doc> - </rule> - </field> - - <field name="nowait" domain="bit" label="do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait for a reply - method. If the server could not complete the method it will raise a channel or connection - exception. - </doc> - </field> - - <field name="filter" domain="table" label="arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics of these filters depends on the - providers implementation. - </doc> - </field> - </method> - - <method name="consume-ok" synchronous="1" index="21" label="confirm a new consumer"> - <doc> - This method provides the client with a consumer tag which it MUST use in methods that work - with the consumer. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </method> - - <!-- - Method: file.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="cancel" synchronous="1" index="30" label="end a queue consumer"> - <doc> - This method cancels a consumer. This does not affect already delivered messages, but it does - mean the server will not send any more messages for that consumer. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag" /> - </method> - - <!-- - Method: file.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="open" synchronous="1" index="40" label="request to start staging"> - <doc> - This method requests permission to start staging a message. Staging means sending the - message into a temporary area at the recipient end and then delivering the message by - referring to this temporary area. Staging is how the protocol handles partial file transfers - - if a message is partially staged and the connection breaks, the next time the sender - starts to stage it, it can restart from where it left off. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <response name="open-ok" /> - - <field name="identifier" domain="shortstr" label="staging identifier"> - <doc> - This is the staging identifier. This is an arbitrary string chosen by the sender. For - staging to work correctly the sender must use the same staging identifier when staging the - same message a second time after recovery from a failure. A good choice for the staging - identifier would be the SHA1 hash of the message properties data (including the original - filename, revised time, etc.). - </doc> - </field> - - <field name="content-size" domain="longlong" label="message content size"> - <doc> - The size of the content in octets. The recipient may use this information to allocate or - check available space in advance, to avoid "disk full" errors during staging of very large - messages. - </doc> - - <rule name="content-size"> - <doc> - The sender MUST accurately fill the content-size field. Zero-length content is - permitted. - </doc> - </rule> - </field> - </method> - - <!-- - Method: file.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="open-ok" synchronous="1" index="41" label="confirm staging ready"> - <doc> - This method confirms that the recipient is ready to accept staged data. If the message was - already partially-staged at a previous time the recipient will report the number of octets - already staged. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <response name="stage" /> - - <field name="staged-size" domain="longlong" label="already staged amount"> - <doc> - The amount of previously-staged content in octets. For a new message this will be zero. - </doc> - - <rule name="behaviour"> - <doc> - The sender MUST start sending data from this octet offset in the message, counting from - zero. - <!-- TODO: review this text, it seems ambiguous or confusing... --> - </doc> - </rule> - - <rule name="staging"> - <doc> - The recipient MAY decide how long to hold partially-staged content and MAY implement - staging by always discarding partially-staged content. However if it uses the file - content type it MUST support the staging methods. - </doc> - </rule> - </field> - </method> - - <!-- - Method: file.stage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="stage" content="1" index="50" label="stage message content"> - <doc> - This method stages the message, sending the message content to the recipient from the octet - offset specified in the Open-Ok method. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - </method> - - <!-- - Method: file.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="publish" index="60" label="publish a message"> - <doc> - This method publishes a staged file message to a specific exchange. The file message will be - routed to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - </doc> - </rule> - </field> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise a channel exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name="internal" on-failure="access-refused"> - <doc> - If the exchange was declared as an internal exchange, the server MUST respond with a - reply code 403 (access refused) and raise a channel exception. - </doc> - </rule> - - <rule name="refusal" on-failure="not-implemented"> - <doc> - The exchange MAY refuse file content in which case it MUST respond with a reply code 540 - (not implemented) and raise a channel exception. - </doc> - </rule> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" domain="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return method. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" domain="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return method. If this flag is zero, the server will queue the message, but with no - guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <field name="identifier" domain="shortstr" label="staging identifier"> - <doc> - This is the staging identifier of the message to publish. The message must have been - staged. Note that a client can send the Publish method asynchronously without waiting for - staging to finish. - </doc> - </field> - </method> - - <!-- - Method: file.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="return" content="1" index="70" label="return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="reply-code" domain="reply-code" /> - - <field name="reply-text" domain="reply-text" /> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - </method> - - <!-- - Method: file.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="deliver" index="80" label="notify the client of a consumer message"> - <doc> - This method delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the Consume method, - then the server responds with Deliver methods as and when messages arrive for that consumer. - </doc> - - <rule name="redelivery-tracking"> - <doc> - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be unprocessable (possibly causing - client applications to abort), and move the message to a dead letter queue. - </doc> - </rule> - - <chassis name="client" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="redelivered" domain="redelivered" /> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <field name="identifier" domain="shortstr" label="staging identifier"> - <doc> - This is the staging identifier of the message to deliver. The message must have been - staged. Note that a server can send the Deliver method asynchronously without waiting for - staging to finish. - </doc> - </field> - </method> - - <!-- - Method: file.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="ack" index="90" label="acknowledge one or more messages"> - <doc> - This method acknowledges one or more messages delivered via the Deliver method. The client - can ask to confirm a single message or a set of messages up to and including a specific - message. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="multiple" domain="bit" label="acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages with a single method. If set to zero, the delivery tag - refers to a single message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding messages. - </doc> - - <rule name="validation"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered message, - and raise a channel exception if this is not the case. - </doc> - </rule> - </field> - </method> - - <!-- - Method: file.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="reject" index="100" label="reject an incoming message"> - <doc> - This method allows a client to reject a message. It can be used to return untreatable - messages to their original queue. Note that file content is staged before delivery, so the - client will not use this method to interrupt delivery of a large message. - </doc> - - <rule name="server-interpretation"> - <doc> - The server SHOULD interpret this method as meaning that the client is unable to process - the message at this time. - </doc> - </rule> - - <rule name="not-selection"> - <doc> - A client MUST NOT use this method as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="requeue" domain="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - </doc> - - <rule name="requeue-strategy"> - <doc> - The server MUST NOT deliver the message to the same client within the context of the - current session. The recommended strategy is to attempt to deliver the message to an - alternative consumer, and if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold the message on the queue - and redeliver it to the same client at a later stage. - </doc> - </rule> - </field> - </method> - - </class> - - <!-- == Class: stream ======================================================================== --> - - <class name="stream" index="80" label="work with streaming content"> - <doc> - The stream class provides methods that support multimedia streaming. The stream class uses the - following semantics: one message is one packet of data; delivery is unacknowledged and - unreliable; the consumer can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favour of high priority messages. - </doc> - - <doc type="grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - </doc> - - <rule name="overflow-discard"> - <doc> - The server SHOULD discard stream messages on a priority basis if the queue size exceeds some - configured limit. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for stream messages, where priorities - 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST implement automatic acknowledgements on stream content. That is, as soon as - a message is delivered to a client via a Deliver method, the server must remove it from the - queue. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - <chassis name="client" implement="MAY" /> - - <!-- These are the properties for a Stream content --> - - <field name="content-type" domain="shortstr" label="MIME content type" /> - <field name="content-encoding" domain="shortstr" label="MIME content encoding" /> - <field name="headers" domain="table" label="message header field table" /> - <field name="priority" domain="octet" label="message priority, 0 to 9" /> - <field name="timestamp" domain="timestamp" label="message timestamp" /> - - <!-- - Method: stream.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="qos" synchronous="1" index="10" label="specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the current - session or for all sessions on the connection. The particular properties and semantics of a - qos method always depend on the content class semantics. Though the qos method could in - principle apply to both peers, it is currently meaningful only for the server. - </doc> - - <chassis name="server" implement="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" domain="long" label="prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other prefetch limits may still apply. - </doc> - </field> - - <field name="prefetch-count" domain="short" label="prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - prefetch windows (and those at the session and connection level) allow it. - </doc> - </field> - - <field name="consume-rate" domain="long" label="transfer rate in octets/second"> - <doc> - Specifies a desired transfer rate in octets per second. This is usually determined by the - application that uses the streaming data. A value of zero means "no limit", i.e. as - rapidly as possible. - </doc> - - <rule name="ignore-prefetch"> - <doc> - The server MAY ignore the prefetch values and consume rates, depending on the type of - stream and the ability of the server to queue and/or reply it. - </doc> - </rule> - - <rule name="drop-by-priority"> - <doc> - The server MAY drop low-priority messages in favour of high-priority messages. - </doc> - </rule> - </field> - - <field name="global" domain="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </method> - - <!-- - Method: stream.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="qos-ok" synchronous="1" index="11" label="confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <chassis name="client" implement="MUST" /> - </method> - - <!-- - Method: stream.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="consume" synchronous="1" index="20" label="start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for messages - from a specific queue. Consumers last as long as the session they were created on, or until - the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <rule name="priority-based-delivery"> - <doc> - Streaming applications SHOULD use different sessions to select different streaming - resolutions. AMQP makes no provision for filtering and/or transforming streams except on - the basis of priority-based selective delivery of individual messages. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <response name="consume-ok" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - </doc> - - <rule name="queue-exists-if-empty" on-failure="not-allowed"> - <doc> - If the client did not previously declare a queue, and the queue name in this method is - empty, the server MUST raise a connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name="consumer-tag" domain="consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. If this field is empty the server will - generate a unique tag. - </doc> - - <rule name="not-existing-consumer" on-failure="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise a connection exception with - reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name="no-local" domain="no-local" /> - - <field name="exclusive" domain="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <rule name="in-use" on-failure="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise a channel exception with return code 405 - (resource locked). - </doc> - </rule> - </field> - - <field name="nowait" domain="bit" label="do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait for a reply - method. If the server could not complete the method it will raise a channel or connection - exception. - </doc> - </field> - - <field name="filter" domain="table" label="arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics of these filters depends on the - providers implementation. - </doc> - </field> - </method> - - <!-- - Method: stream.consume-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="consume-ok" synchronous="1" index="21" label="confirm a new consumer"> - <doc> - This method provides the client with a consumer tag which it may use in methods that work - with the consumer. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </method> - - <!-- - Method: stream.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="cancel" synchronous="1" index="30" label="end a queue consumer"> - <doc> - This method cancels a consumer. Since message delivery is asynchronous the client may - continue to receive messages for a short while after cancelling a consumer. It may process - or discard these as appropriate. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag" /> - </method> - - <!-- - Method: stream.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="publish" content="1" index="40" label="publish a message"> - <doc> - This method publishes a message to a specific exchange. The message will be routed to queues - as defined by the exchange configuration and distributed to any active consumers as - appropriate. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - </doc> - </rule> - </field> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise a channel exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name="internal" on-failure="access-refused"> - <doc> - If the exchange was declared as an internal exchange, the server MUST respond with a - reply code 403 (access refused) and raise a channel exception. - </doc> - </rule> - - <rule name="refusal" on-failure="not-implemented"> - <doc> - The exchange MAY refuse stream content in which case it MUST respond with a reply code - 540 (not implemented) and raise a channel exception. - </doc> - </rule> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" domain="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return method. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" domain="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return method. If this flag is zero, the server will queue the message, but with no - guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - </method> - - <!-- - Method: stream.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="return" content="1" index="50" label="return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="reply-code" domain="reply-code" /> - - <field name="reply-text" domain="reply-text" /> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - </method> - - <!-- - Method: stream.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="deliver" content="1" index="60" label="notify the client of a consumer message"> - <doc> - This method delivers a message to the client, via a consumer. In the asynchronous message - delivery model, the client starts a consumer using the Consume method, then the server - responds with Deliver methods as and when messages arrive for that consumer. - </doc> - - <chassis name="client" implement="MUST" /> - - <field name="consumer-tag" domain="consumer-tag" /> - - <field name="delivery-tag" domain="delivery-tag" /> - - <field name="exchange" domain="exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue that the message came from. Note that a single session can - start many consumers on different queues. - </doc> - <assert check="notnull" /> - </field> - </method> - - </class> - - <!-- == Class: tx ============================================================================ --> - - <class name="tx" index="90" label="work with standard transactions"> - <doc> - Standard transactions provide so-called "1.5 phase commit". We can ensure that work is never - lost, but there is a chance of confirmations being lost, so that messages may be resent. - Applications that use standard transactions must be able to detect and ignore duplicate - messages. - </doc> - - <doc type="grammar"> - tx = C:SELECT - / C:COMMIT - / C:ROLLBACK - </doc> - - <rule name="duplicate-tracking"> - <doc> - An client using standard transactions SHOULD be able to track all messages received within a - reasonable period, and thus detect and reject duplicates of the same message. It SHOULD NOT - pass these to the application layer. - </doc> - </rule> - - <chassis name="server" implement="SHOULD" /> - <chassis name="client" implement="MAY" /> - - <!-- - Method: tx.select - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="select" synchronous="1" index="10" label="select standard transaction mode"> - <doc> - This method sets the session to use standard transactions. The client must use this method - at least once on a session before using the Commit or Rollback methods. - </doc> - <chassis name="server" implement="MUST" /> - </method> - - <!-- - Method: tx.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="commit" synchronous="1" index="20" label="commit the current transaction"> - <doc> - This method commits all messages published and acknowledged in the current transaction. A - new transaction starts immediately after a commit. - </doc> - <chassis name="server" implement="MUST" /> - </method> - - <!-- - Method: tx.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="rollback" synchronous="1" index="30" label="abandon the current transaction"> - <doc> - This method abandons all messages published and acknowledged in the current transaction. A - new transaction starts immediately after a rollback. - </doc> - <chassis name="server" implement="MUST" /> - </method> - - </class> - - <!-- == Class: dtx-demarcation =============================================================== --> - - <!-- NOTE: (TODO) Comments on AMQP-4 JIRA made since the proposed XML was posted on June 1 have - not yet been incorporated here. - --> - - <class name="dtx-demarcation" index="100" label="Demarcates dtx branches"> - <doc> - This class is part of the X-Open XA distributed transaction protocol support. It allows a - session to be selected for use with distributed transactions and the transactional boundaries - for work on that session to be demarcated. - </doc> - - <doc type="grammar"> - dtx-demarcation = C:SELECT *demarcation - demarcation = C:START C:END - </doc> - - <rule name="access-control"> - <doc> - Access-tickets are propagated with XA association methods with the aim of restricting which - users are allowed to control which transactions. The server MAY restrict transaction - association to a particular identity. - </doc> - </rule> - - <rule name="transactionality"> - <doc> - Enabling XA transaction support on a session implies that the server MUST manage - transactions demarcated by start-end blocks. That is to say that on this XA-enabled session, - work undergone within transactional blocks is performed on behalf a transaction branch - whereas work performed outside of transactional blocks is NOT transactional. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - <chassis name="client" implement="MAY" /> - - - <!-- - Method: dtx-demarcation.select - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="select" synchronous="1" index="10" label="Select dtx mode"> - <doc> - This method sets the session to use distributed transactions. The client must use this - method at least once on a session before using XA demarcation operations. - </doc> - - <chassis name="server" implement="MAY" /> - </method> - - <!-- - Method: dtx-demarcation.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="start" synchronous="1" index="20" label="Start a dtx branch"> - <doc> - This method is called when messages should be produced and consumed on behalf a transaction - branch identified by xid. - </doc> - - <rule name="command-invalid" on-failure="command-invalid"> - <doc> - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <rule name="already-known" on-failure="not-allowed"> - <doc> - If neither join nor resume is specified is specified and the transaction branch specified - by xid has previously been seen then the server MUST raise a channel exception with reply - code 530 (not allowed). - </doc> - </rule> - - <rule name="join-and-resume" on-failure="command-invalid"> - <doc> - If join and resume are specified then the server MUST raise a channel exception with reply - code 503 (command invalid). - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch to be started. - </doc> - - <rule name="unknown-xid" on-failure="not-allowed"> - <doc> - If xid is already known by the broker then the server MUST raise a channel exception - with reply code 530 (not allowed). - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="join" domain="bit" label="Join with existing xid flag"> - <doc> - Indicate whether this is joining an already associated xid. Indicate that the start - applies to joining a transaction previously seen. - </doc> - - <rule name="unsupported" on-failure="not-implemented"> - <doc> - If the broker does not support join the server MUST raise a channel exception with reply - code 540 (not implemented). - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="resume" domain="bit" label="Resume flag"> - <doc> - Indicate that the start applies to resuming a suspended transaction branch specified. - </doc> - - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="21"> - <doc> - This confirms to the client that the transaction branch is started or specify the error - condition. - </doc> - - <field name="status" domain="short" label="Status code"> - <doc> - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - <!-- - Method: dtx-demarcation.end - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="end" synchronous="1" index="30" label="End a dtx branch"> - <doc> - This method is called when the work done on behalf a transaction branch finishes or needs to - be suspended. - </doc> - - <rule name="command-invalid" on-failure="command-invalid"> - <doc> - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid). - </doc> - </rule> - - <rule name="suspend-and-fail" on-failure="command-invalid"> - <doc> - If suspend and fail are specified then the server MUST raise a channel exception with - reply code 503 (command invalid). - </doc> - </rule> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in ending the transaction branch then the server MUST raise a channel - exception with reply code 541 (internal error). - </doc> - </rule> - - <rule name="success"> - <doc> - If neither fail nor suspend are specified then the portion of work has completed - successfully. - </doc> - </rule> - - <rule name="session-closed"> - <doc> - When a session is closed then the currently associated transaction branches MUST be marked - rollback-only. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch to be ended. - </doc> - - <rule name="not-associated" on-failure="command-invalid"> - <doc> - The channel MUST be currently associated with the given xid (through an earlier start - call with the same xid). - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="fail" domain="bit" label="Failure flag"> - <doc> - If set, indicates that this portion of work has failed; otherwise this portion of work has - completed successfully. - </doc> - - <rule name="failure"> - <doc> - An implementation MAY elect to roll a transaction back if this failure notification is - recieved. Should an implementation elect to implement this behaviour, and this bit is - set, then then the transaction branch SHOULD be marked as rollback-only and the end - result SHOULD have the xa-rbrollback status set. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="suspend" domain="bit" label="Temporary suspension flag"> - <doc> - Indicates that the transaction branch is temporarily suspended in an incomplete state. - </doc> - - <rule name="resume"> - <doc> - The transaction context is in a suspended state and must be resumed via the start method - with resume specified. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="31"> - <doc> - This method confirms to the client that the transaction branch is ended or specify the - error condition. - </doc> - - <field name="status" domain="short" label="Status code"> - <doc> - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. If an implementation chooses to implement rollback-on-failure behaviour, then - this value should be selected if the dtx-demarcation.end.fail bit was set. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - </class> - - - <!-- == Class: dtx-coordination ============================================================== --> - - <class name="dtx-coordination" index="105" label="Coordinate dtx outcomes"> - <doc> - This class is part of the X-Open XA distributed transaction protocol support. It allows the - transaction manager to coordinate transaction outcomes. - </doc> - - <doc type="grammar"> - dtx-coordination = *coordination - coordination = command - / outcome - / recovery - command = C:SET-TIMEOUT - / C:GET-TIMEOUT - outcome = one-phase-commit - / one-phase-rollback - / two-phase-commit - / two-phase-rollback - one-phase-commit = C:COMMIT - one-phase-rollback = C:ROLLBACK - two-phase-commit = C:PREPARE C:COMMIT - two-phase-rollback = C:PREPARE C:ROLLBACK - recovery = C:RECOVER *recovery-outcome - recovery-outcome = one-phase-commit - / one-phase-rollback - / C:FORGET - </doc> - - <rule name="security"> - <doc> - Access-tickets are propagated with XA demarcation methods with the aim of restricting which - users are allowed to control which transactions. The server MAY restrict transaction - coordination to a particular identity. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - <chassis name="client" implement="MAY" /> - - <!-- - Method: dtx-coordination.commit - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="commit" synchronous="1" index="10" label="Commit work on dtx branch"> - <doc> - Commit the work done on behalf a transaction branch. This method commits the work associated - with xid. Any produced messages are made available and any consumed messages are discarded. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in committing the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error) - </doc> - </rule> - - <rule name="command-invalid" on-failure="command-invalid"> - <doc> - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch to be committed. - </doc> - - <rule name="unknown-xid" on-failure="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - - <rule name="not-disassociated" on-failure="command-invalid"> - <doc> - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="one-phase" domain="bit" label="One-phase optimization flag"> - <doc> - When set then one-phase commit optimization is used. - </doc> - - <rule name="prerequisite" on-failure="command-invalid"> - <doc> - This bit MUST be set if a commit is sent without a preceding prepare. - </doc> - </rule> - - <rule name="validity" on-failure="command-invalid"> - <doc> - This bit MUST NOT be set if a preceding prepare has been sent. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="11"> - <doc> - This confirms to the client that the transaction branch is committed or specify the - error condition. - </doc> - - <field name="status" domain="short" label="Status code"> - <doc> - The value of this field may be one of the following constants: - - xa-ok: Normal execution - - xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction - branch may have been heuristically completed. - - xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was committed. - - xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was rolled back. - - xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was partially committed and partially rolled back. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - <!-- - Method: dtx-coordination.forget - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="forget" synchronous="1" index="20" label="Discard dtx branch"> - <doc> - This method is called to forget about a heuristically completed transaction branch. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in forgetting the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error) - </doc> - </rule> - - <rule name="command-invalid" on-failure="command-invalid"> - <doc> - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch to be forgotten. - </doc> - - <rule name="unknown-xid" on-failure="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - - <rule name="not-disassociated" on-failure="command-invalid"> - <doc> - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid). - </doc> - </rule> - - <assert check="notnull" /> - </field> - </method> - - <!-- - Method: dtx-coordination.get-timeout - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="get-timeout" synchronous="1" index="30" label="Obtain dtx timeout in seconds"> - <doc> - This method obtains the current transaction timeout value in seconds. If set-timeout was not - used prior to invoking this method, the return value is the default timeout; otherwise, the - value used in the previous set-timeout call is returned. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in setting the transaction timeout then the server MUST raise a channel - exception with reply code 541 (internal error). - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch for getting the timeout. - </doc> - - <rule name="unknown-xid" on-failure="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="31"> - <doc> - Returns the value of the timeout last specified through set-timeout. - </doc> - - <field name="timeout" domain="long" label="The current transaction timeout value"> - <doc> - The current transaction timeout value in seconds. - </doc> - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - <!-- - Method: dtx-coordination.prepare - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="prepare" synchronous="1" index="40" label="Prepare a dtx branch"> - <doc> - This method prepares for commitment any message produced or consumed on behalf of xid. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in preparing the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error). The specified xid may or may not - have been prepared. - </doc> - </rule> - - <rule name="command-invalid" on-failure="command-invalid"> - <doc> - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <rule name="obligation-1"> - <doc> - Once this method successfully returns it is guaranteed that the transaction branch may be - either committed or rolled back regardless of failures. - </doc> - </rule> - - <rule name="obligation-2"> - <doc> - The knowledge of xid cannot be erased before commit or rollback complete the branch. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch that can be prepared. - </doc> - - <rule name="unknown-xid" on-failure="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - - <rule name="not-disassociated" on-failure="command-invalid"> - <doc> - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="41"> - <doc> - This method confirms to the client that the transaction branch is prepared or specify the - error condition. - </doc> - - <field name="status" domain="short" label="Status code"> - <doc> - The value of this field may be one of the following constants: - - xa-ok: Normal execution. - - xa-rdonly: The transaction branch was read-only and has been committed. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - <!-- - Method: dtx-coordination.recover - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="recover" synchronous="1" index="50" label="Get prepared or completed xids"> - <doc> - This method is called to obtain a list of transaction branches that are in a prepared or - heuristically completed state. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in recovering then the server MUST raise a channel exception with reply - code 541 (internal error) - </doc> - </rule> - - <rule name="start-end"> - <doc> - If this endscan is used in conjunction with startscan then a single call starts and then - ends a scan. - </doc> - </rule> - - <rule name="must-be-started" on-failure="command-invalid"> - <doc> - If none of endscan and startscan are set then a recovery scan must already be started - otherwise the server MUST raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="startscan" domain="bit" label="Start recovery scan flag"> - <doc> - Indicates that recovery scan should start. - </doc> - - <rule name="recovery-already-open"> - <doc> - If a recovery scan is already open, the effect is as if the recovery scan were ended and - then restarted. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="endscan" domain="bit" label="Flag indicating end scan on return of xids"> - <doc> - Indicates that the recovery scan should end after returning the xids. - </doc> - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="51"> - <doc> - Returns to the client a table with single item that is a sequence of transaction xids that - are in a prepared or heuristically completed state. - </doc> - - <field name="in-doubt" domain="array" label="array of xids to be recovered"> - <doc> - xids to be recovered (xids that are in a prepared or heuristically completed state). - </doc> - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - <!-- - Method: dtx-coordination.rollback - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="rollback" synchronous="1" index="60" label="Rollback a dtx branch"> - <doc> - This method rolls back the work associated with xid. Any produced messages are discarded and - any consumed messages are re-enqueued. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in rolling back the transaction branch then the server MUST raise a - channel exception with reply code 541 (internal error) - </doc> - </rule> - - <rule name="command-invalid" on-failure="command-invalid"> - <doc> - If the method is invoked in an improper context (see class grammar) then the server MUST - raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch that can be rolled back. - </doc> - - <rule name="unknown-xid" on-failure="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - - <rule name="not-disassociated" on-failure="command-invalid"> - <doc> - If this method is called when xid is still associated with a session then the server - MUST raise a channel exception with reply code 503 (command invalid) - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <result> - <struct size="long" type="61"> - <doc> - This method confirms to the client that the transaction branch is rolled back or specify the - error condition. - </doc> - - <field name="status" domain="short" label="Status code"> - <doc> - The value of this field may be one of the following constants: - - xa-ok: Normal execution - - xa-heurhaz: Due to some failure, the work done on behalf of the specified transaction - branch may have been heuristically completed. - - xa-heurcom: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was committed. - - xa-heurrb: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was rolled back. - - xa-heurmix: Due to a heuristic decision, the work done on behalf of the specified - transaction branch was partially committed and partially rolled back. - - xa-rbrollback: The broker marked the transaction branch rollback-only for an unspecified - reason. - - xa-rbtimeout: The work represented by this transaction branch took too long. - </doc> - <assert check="notnull" /> - </field> - </struct> - </result> - </method> - - <!-- - Method: dtx-coordination.set-timeout - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="set-timeout" synchronous="1" index="70" label="Set dtx timeout value"> - <doc> - Sets the specified transaction branch timeout value in seconds. - </doc> - - <rule name="internal-error" on-failure="internal-error"> - <doc> - If an error occurs in setting the transaction timeout then the server MUST raise a channel - exception with reply code 541 (internal error) - </doc> - </rule> - - <rule name="effective"> - <doc> - Once set, this timeout value is effective until this method is reinvoked with a different - value. - </doc> - </rule> - - <rule name="reset"> - <doc> - A value of zero resets the timeout value to the default value. - </doc> - </rule> - - <chassis name="server" implement="MAY" /> - - <field name="ticket" domain="access-ticket" label="Access-ticket for specific realm"> - <doc> - Access-ticket granted by the server for a specific realm. - </doc> - - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access rights to all the - realms touched by this transaction. - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="xid" domain="xid" label="Transaction xid"> - <doc> - Specifies the xid of the transaction branch for setting the timeout. - </doc> - - <rule name="unknown-xid" on-failure="not-found"> - <doc> - If xid is unknown (the transaction branch has not been started or has already been - ended) then the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - - <assert check="notnull" /> - </field> - - <field name="timeout" domain="long" label="Dtx timeout in seconds"> - <doc> - The transaction timeout value in seconds. - </doc> - <assert check="notnull" /> - </field> - </method> - - </class> - - - <!-- == Class: tunnel ========================================================================= --> - - <class name="tunnel" index="110" label="methods for protocol tunnelling"> - <doc> - The tunnel methods are used to send blocks of binary data - which can be serialised AMQP - methods or other protocol frames - between AMQP peers. - </doc> - - <doc type="grammar"> - tunnel = C:REQUEST - / S:REQUEST - </doc> - - <chassis name="server" implement="MAY" /> - <chassis name="client" implement="MAY" /> - - <field name="headers" domain="table" label="message header field table" /> - <field name="proxy-name" domain="shortstr" label="identity of tunnelling proxy" /> - <field name="data-name" domain="shortstr" label="name or type of message being tunnelled" /> - <field name="durable" domain="octet" label="message durability indicator" /> - <field name="broadcast" domain="octet" label="message broadcast mode" /> - - <!-- - Method: tunnel.request - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="request" content="1" index="10" label="sends a tunnelled method"> - <doc> - This method tunnels a block of binary data, which can be an encoded AMQP method or other - data. The binary data is sent as the content for the Tunnel.Request method. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="meta-data" domain="table" label="meta data for the tunnelled block"> - <doc> - This field table holds arbitrary meta-data that the sender needs to pass to the recipient. - </doc> - </field> - </method> - - </class> - - <!-- == Class: message ======================================================================= --> - - <class name="message" index="120" label="message transfer"> - <doc> - The message class provides methods that support an industry-standard messaging model. - </doc> - - <doc type="grammar"> - message = C:QOS - / C:CONSUME - / C:CANCEL - / C:TRANSFER [ S:REJECT ] - / S:TRANSFER [ C:REJECT ] - / C:GET [ S:EMPTY ] - / C:RECOVER - / C:OPEN - / S:OPEN - / C:APPEND - / S:APPEND - / C:CLOSE - / S:CLOSE - / C:CHECKPOINT - / S:CHECKPOINT - / C:RESUME S:OFFSET - / S:RESUME C:OFFSET - </doc> - - <rule name="persistent-message"> - <doc> - The server SHOULD respect the persistent property of messages and SHOULD make a best-effort - to hold persistent mess ages on a reliable storage mechanism. - </doc> - <doc type="scenario"> - Send a persistent message to queue, stop server, restart server and then verify whether - message is still present. Assumes that queues are durable. Persistence without durable - queues makes no sense. - </doc> - </rule> - - <rule name="no-persistent-message-discard"> - <doc> - The server MUST NOT discard a persistent message in case of a queue overflow. - </doc> - <doc type="scenario"> - Create a queue overflow situation with persistent messages and verify that messages do not - get lost (presumably the server will write them to disk). - </doc> - </rule> - - <rule name="throttling"> - <doc> - The server MAY use the Session.Flow method to slow or stop a message publisher when - necessary. - </doc> - <doc type="scenario"> - Create a queue overflow situation with non-persistent messages and verify whether the server - responds with Session.Flow or not. Repeat with persistent messages. - </doc> - </rule> - - <rule name="non-persistent-message-overflow"> - <doc> - The server MAY overflow non-persistent messages to persistent storage. - </doc> - </rule> - - <rule name="non-persistent-message-discard"> - <doc> - The server MAY discard or dead-letter non-persistent messages on a priority basis if the - queue size exceeds some configured limit. - </doc> - </rule> - - <rule name="min-priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for messages, where priorities 0-4 and - 5-9 are treated as two distinct levels. - </doc> - <doc type="scenario"> - Send a number of priority 0 messages to a queue. Send one priority 9 message. Consume - messages from the queue and verify that the first message received was priority 9. - </doc> - </rule> - - <rule name="max-priority-levels"> - <doc> - The server MAY implement up to 10 priority levels. - </doc> - <doc type="scenario"> - Send a number of messages with mixed priorities to a queue, so that all priority values from - 0 to 9 are exercised. A good scenario would be ten messages in low-to-high priority. Consume - from queue and verify how many priority levels emerge. - </doc> - </rule> - - <rule name="priority-delivery"> - <doc> - The server MUST deliver messages of the same priority in order irrespective of their - individual persistence. - </doc> - <doc type="scenario"> - Send a set of messages with the same priority but different persistence settings to a queue. - Consume and verify that messages arrive in same order as originally published. - </doc> - </rule> - - <rule name="automatic-acknowledgements"> - <doc> - The server MUST support automatic acknowledgements on messages, i.e. consumers with the - no-ack field set to FALSE. - </doc> - <doc type="scenario"> - Create a queue and a consumer using automatic acknowledgements. Publish a set of messages to - the queue. Consume the messages and verify that all messages are received. - </doc> - </rule> - - <rule name="explicit-acknowledgements"> - <doc> - The server MUST support explicit acknowledgements on messages, i.e. consumers with the - no-ack field set to TRUE. - </doc> - <doc type="scenario"> - Create a queue and a consumer using explicit acknowledgements. Publish a set of messages to - the queue. Consume the messages but acknowledge only half of them. Disconnect and reconnect, - and consume from the queue. Verify that the remaining messages are received. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <!-- - Method: message.transfer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="transfer" content="1" index="10" label="transfer a message"> - <doc> - This method transfers a message between two peers. When a client uses this method to publish - a message to a broker, the destination identifies a specific exchange. The message will then - be routed to queues as defined by the exchange configuration and distributed to any active - subscriptions when the transaction, if any, is committed. - - The client may initiate transfers from the broker by starting a subscription using the - subscribe method and passing in a destination, then the broker responds with transfer - methods to the specified destination as and when messages arrive in the subscribed queue. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="ticket" domain="access-ticket" label="access ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - </doc> - </rule> - </field> - - <field name="destination" domain="destination" label="message destination"> - <doc> - Specifies the destination to which the message is to be transferred. The destination can - be empty, meaning the default exchange or subscription. If the destination is specified, - and that exchange or subscription does not exist, the peer must raise a channel exception. - </doc> - - <rule name="blank-destination"> - <doc> - The server MUST accept a blank destination to mean the default exchange. - </doc> - </rule> - - <rule name="internal-exchange"> - <doc> - If the destination refers to an internal exchange, the server MUST raise a channel - exception with a reply code 403 (access refused). - </doc> - </rule> - - <rule name="message-refusal"> - <doc> - A destination MAY refuse message content in which case it MUST raise a channel exception - with reply code 540 (not implemented). - </doc> - </rule> - </field> - - <field name="confirm-mode" domain="confirm-mode" /> - <field name="acquire-mode" domain="acquire-mode" /> - </method> - - <!-- - Method: message.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="reject" index="160" label="reject a message"> - <doc> - Indicates that the message transfers are un-processable in some way. A message may be - rejected for a number of reasons. A server may reject a message if it is unroutable. A - client may reject a message if it is invalid. - </doc> - - <rule name="alternate-exchange"> - <doc> - When a client rejects a message, the server MUST deliver that message to the - alternate-exchange on the queue from which it was delivered. If no alternate-exchange is - defined for that queue the broker MAY discard the message. - </doc> - </rule> - - <rule name="acquisition"> - <doc> - The recipient MUST have acquired a message in order to reject it. If the message is not - acquired any reject MUST be ignored. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MAY" /> - - <field name="transfers" domain="correlation" /> - <field name="code" domain="reject-code" /> - <field name="text" domain="reject-text" /> - </method> - - <!-- - Method: message.acquire - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="acquire" index="170" label="acquire messages for consumption"> - <doc> - Acquires previously transferred messages for consumption. The acquired ids (if any) are - sent via message.acquired. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="transfers" domain="correlation" /> - <!-- do we need this field? --> - <field name="mode" domain="octet"> - <doc> - One of: - - any (0): acquire any available messages for consumption - - all (1): only acquire messages if all are available for consumption - </doc> - </field> - </method> - - <!-- - Method: message.acquired - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="acquired" index="180" label="indicates acquired messages"> - <doc> - Identifies a set of previously transferred messages now available for consumption. - </doc> - - <chassis name="client" implement="MAY" /> - - <field name="transfers" domain="correlation" /> - </method> - - <!-- - Method: message.release - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="release" index="190" label="release a message"> - <doc> - Release previously transferred messages that have been acquired for consumption (whether - implicitly or explicitly). Released messages will be available for acquisition by other - consumers. The order of released messages may be lost. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MAY" /> - - <field name="transfers" domain="correlation" /> - </method> - - <!-- - Method: message.subscribe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="subscribe" index="20" label="start a queue subscription"> - <doc> - This method asks the server to start a "subscription", which is a transient request for - messages from a specific queue. Subscriptions last as long as the session they were created - on, or until the client cancels them. - </doc> - - <rule name="simultaneous-subscriptions"> - <doc> - The server SHOULD support at least 16 subscriptions per queue, and ideally, impose no - limit except as defined by available resources. - </doc> - <doc type="scenario"> - Create a queue and create subscriptions on that queue until the server closes the - connection. Verify that the number of subscriptions created was at least sixteen and - report the total number. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the subscribed queue. - </doc> - <doc type="scenario"> - Attempt to create a subscription with an invalid (non-zero) access ticket. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the subscribed queue. - </doc> - </field> - - <field name="destination" domain="destination" label="incoming message destination"> - <doc> - Specifies the destination for the subscription. The destination is local to a connection, - so two clients can use the same destination. - </doc> - - <rule name="destination-non-existing-subscription" on-failure="not-allowed"> - <doc> - The client MUST NOT specify a destination that refers to an existing subscription. - </doc> - <doc type="scenario"> - Attempt to create two subscriptions with the same non-empty destination. - </doc> - </rule> - - <rule name="destination-session-bound" on-failure="not-allowed"> - <doc> - The destination is valid only within the session from which the subscription was - created. i.e. A client MUST NOT create a subscription in one session and then use it in - another. - </doc> - <doc type="scenario"> - Attempt to create a subscription in one session, then use in another session, in which - subscriptions have also been created (to test that the server uses unique destinations). - </doc> - </rule> - </field> - - <field name="no-local" domain="no-local" label="messages not returned to publisher"> - <doc> - If the no-local field is set the server will not send messages to the connection that - published them. - </doc> - </field> - - <field name="confirm-mode" domain="confirm-mode"> - <doc> - The default confirm-mode for this subscription. - </doc> - </field> - - <field name="acquire-mode" domain="acquire-mode"> - <doc> - The default acquire-mode for this subscription. - </doc> - </field> - - <field name="exclusive" domain="bit" label="request exclusive access"> - <doc> - Request exclusive subscription access, meaning only this subscription can access the queue. - </doc> - - <rule name="in-use" on-failure="access-refused"> - <doc> - The client MUST NOT gain exclusive access to a queue that already has active subscriptions. - </doc> - <doc type="scenario"> - Open two connections to a server, and in one connection create a shared (non-exclusive) - queue and then subscribe to the queue. In the second connection attempt to subscribe to - the same queue using the exclusive option. - </doc> - </rule> - </field> - - <field name="filter" domain="table" label="arguments for filtering"> - <doc> - A set of filters for the subscription. The syntax and semantics of these filters depends - on the providers implementation. - </doc> - </field> - </method> - - <!-- - Method: message.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="cancel" index="30" label="end a queue consumer"> - <doc> - This method cancels a consumer. This does not affect already delivered messages, but it does - mean the server will not send any more messages for that consumer. The client may receive an - arbitrary number of messages in between sending the cancel method and receiving the - notification of completion of the cancel command. - </doc> - - <rule name="ignore"> - <doc> - If the queue does not exist the server MUST ignore the cancel method, so long as the - consumer tag is valid for that session. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="destination" domain="destination" /> - </method> - - <!-- - Method: message.get - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="get" index="40" label="direct access to a queue"> - <doc> - This method provides a direct access to the messages in a queue using a synchronous dialogue - that is designed for specific types of application where synchronous functionality is more - important than performance. - </doc> - - <chassis name="server" implement="MUST" /> - - <response name="empty" /> - - <field name="ticket" domain="access-ticket"> - <rule name="ticket-required" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to the realm - for the queue from which the message will be consumed. - </doc> - </rule> - </field> - - <field name="queue" domain="queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, refers to the - current queue for the session, which is the last declared queue. - </doc> - <rule name="empty-name"> - <doc> - If the client did not previously declare a queue, and the queue name in this method is - empty, the server MUST raise a connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name="destination" domain="destination"> - <doc> - On normal completion of the get request (i.e. a response of ok). A message will be - transferred to the supplied destination. - </doc> - </field> - - <field name="no-ack" domain="no-ack" /> - </method> - - <!-- - Method: message.recover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="recover" index="50" label="redeliver unacknowledged messages"> - <doc> - This method asks the broker to redeliver all unacknowledged messages on a specified session. - Zero or more messages may be redelivered. This method is only allowed on non-transacted - sessions. - </doc> - - <rule name="redelivered-flag"> - <doc> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - </rule> - - <rule name="transacted-session"> - <doc> - The server MUST raise a channel exception if this is called on a transacted session. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - - <field name="requeue" domain="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be redelivered to the original recipient. If this - bit is 1, the server will attempt to requeue the message, potentially then delivering it - to an alternative subscriber. - </doc> - </field> - </method> - - <!-- - Method: message.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="open" index="60" label="create a reference to an empty message body"> - <doc> - This method creates a reference. A references provides a means to send a message body into a - temporary area at the recipient end and then deliver the message by referring to this - temporary area. This is how the protocol handles large message transfers. - - The scope of a ref is defined to be between calls to open (or resume) and close. Between - these points it is valid for a ref to be used from any content data type, and so the - receiver must hold onto its contents. Should the session be closed when a ref is still in - scope, the receiver may discard its contents (unless it is checkpointed). A ref that is in - scope is considered open. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="reference" domain="reference"> - <rule name="duplicate-reference"> - <doc> - The recipient MUST generate an error if the reference is currently open (in scope). - </doc> - </rule> - </field> - </method> - - <!-- - Method: message.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="close" index="70" label="close a reference"> - <doc> - This method signals the recipient that no more data will be appended to the reference. - </doc> - - <rule name="message-acknowledge-after-close"> - <doc> - A recipient MUST NOT acknowledge a message until its reference is closed (not in scope). - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="reference" domain="reference" label="target reference"> - <rule name="non-existent-reference"> - <doc> - The recipient MUST generate an error if the reference was not previously open (in - scope). - </doc> - </rule> - </field> - </method> - - <!-- - Method: message.append - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="append" index="80" label="append to a reference"> - <doc>This method appends data to a reference.</doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="reference" domain="reference" label="target reference"> - <rule name="non-existent-reference"> - <doc> - The recipient MUST generate an error if the reference is not open (not in scope). - </doc> - </rule> - </field> - - <field name="bytes" domain="longstr" label="data to append" /> - </method> - - <!-- - Method: message.checkpoint - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="checkpoint" index="90" label="checkpoint a message body"> - <doc> - This method provides a means to checkpoint large message transfer. The sender may ask the - recipient to checkpoint the contents of a reference using the supplied identifier. The - sender may then resume the transfer at a later point. It is at the discretion of the - recipient how much data to save with the checkpoint, and the sender MUST honour the offset - returned by the resume method. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="reference" domain="reference" label="target reference"> - <rule name="non-existent-reference"> - <doc> - The recipient MUST generate an error if the reference is not open (not in scope). - </doc> - </rule> - </field> - - <field name="identifier" domain="shortstr" label="checkpoint identifier"> - <doc> - This is the checkpoint identifier. This is an arbitrary string chosen by the sender. For - checkpointing to work correctly the sender must use the same checkpoint identifier when - resuming the message. A good choice for the checkpoint identifier would be the SHA1 hash - of the message properties data (including the original filename, revised time, etc.). - </doc> - </field> - </method> - - <!-- - Method: message.resume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="resume" index="100" label="open and resume a checkpointed message"> - <doc> - This method resumes a reference from the last checkpoint. A reference is considered to be - open (in scope) after a resume even though it will not have been opened via the open method - during this session. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <response name="offset" /> - - <field name="reference" domain="reference" label="target reference"> - <rule name="non-existent-reference"> - <doc> - The recipient MUST generate an error if the reference is currently open (in scope). - </doc> - </rule> - </field> - - <field name="identifier" domain="shortstr" label="checkpoint identifier" /> - </method> - - <!-- - Method: message.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="qos" index="110" label="specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the current - session or for all sessions on the connection. The particular properties and semantics of a - qos method always depend on the content class semantics. Though the qos method could in - principle apply to both peers, it is currently meaningful only for the server. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="prefetch-size" domain="long" label="prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Prefetching gives a performance improvement. This field - specifies the prefetch window size in octets. The server will send a message in advance if - it is equal to or smaller in size than the available prefetch size (and also falls into - other prefetch limits). May be set to zero, meaning "no specific limit", although other - prefetch limits may still apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - <rule name="non-responsive-client"> - <doc> - The server MUST ignore this setting when the client is not processing any messages - - i.e. the prefetch size does not limit the transfer of single messages to a client, only - the sending in advance of more messages while the client still has one or more - unacknowledged messages. - </doc> - <doc type="scenario"> - Define a QoS prefetch-size limit and send a single message that exceeds that limit. - Verify that the message arrives correctly. - </doc> - </rule> - </field> - - <field name="prefetch-count" domain="short" label="prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - prefetch windows (and those at the session and connection level) allow it. The - prefetch-count is ignored if the no-ack option is set. - </doc> - <rule name="prefetch-maximum"> - <doc> - The server may send less data in advance than allowed by the client's specified prefetch - windows but it MUST NOT send more. - </doc> - <doc type="scenario"> - Define a QoS prefetch-size limit and a prefetch-count limit greater than one. Send - multiple messages that exceed the prefetch size. Verify that no more than one message - arrives at once. - </doc> - </rule> - </field> - - <field name="global" domain="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </method> - - <!-- - Method: message.flow-mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="flow-mode" index="120" label="set the flow control mode"> - <doc> - Sets the mode of flow control used for a given destination. - - With credit based flow control, the sender of messages continually maintains its current - credit balance with the recipient. The credit balance consists of two values, a message - count, and a byte count. Whenever message data is sent, both counts must be decremented. - If either value reaches zero, the flow of message data must stop. Additional credit is - received via the message.flow method. - - The sender MUST NOT send partial framesets. This means that if there is not enough byte - credit available to send a complete message, the sender must either wait or use chunked - transfer to send the first part of the message data in a complete frameset. - - Window based flow control is identical to credit based flow control, however message - acknowledgment implicitly grants a single unit of message credit, and the size of the - message in byte credits for each acknowledged message. - </doc> - - <rule name="byte-accounting"> - <doc> - The byte count is decremented by the payload size of each transmitted frame with - segment type header or body appearing within a message.transfer command. Note that - the payload size is the frame size less the frame header size (frame-size - 12). - </doc> - </rule> - - <rule name="mode-switching"> - <doc> - Mode switching may only occur if both outstanding credit balances are zero. There are - three ways for a recipient of messages to be sure that the sender 's credit balance is - zero: - - 1) The recipient may send a message.stop command to the sender. When the recipient - receives confirmation of completion for the message.stop command, it knows that the - sender's credit is zero. - - 2) The recipient may perform the same steps described in (1) with the message.flush - command substituted for the message.stop command. - - 3) Immediately after receiving a message.consume, the credit for that destination - defaults to zero. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="destination" domain="destination" /> - <field name="mode" domain="octet"> - <doc> - One of: - - credit (0): choose credit based flow control - - window (1): choose window based flow control - </doc> - </field> - </method> - - <!-- - Method: message.flow - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="flow" index="130" label="control message flow"> - <doc> - This method controls the flow of message data to a given destination. It is used by the - recipient of messages to dynamically match the incoming rate of message flow to its - processing or forwarding capacity. Upon receipt of this method, the sender must add "value" - number of the specified unit to the available credit balance for the specified destination. - A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for - the given unit until the credit balance is zeroed with message.stop or message.flush. - </doc> - - <!-- throws no-such-destination --> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="destination" domain="destination"/> - <field name="unit" domain="octet"> - <doc> - Specifies the unit of credit balance. - - One of: - - message (0) - - byte (1) - </doc> - </field> - <field name="value" domain="long"> - <doc> - A value of (0xFFFFFFFF) indicates an infinite amount of credit. - </doc> - </field> - </method> - - <!-- - Method: message.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="flush" index="140"> - <doc> - Forces the sender to exhaust his credit supply. The sender's credit will always be zero when - this method completes. The message does not complete until all the message transfers occur. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="destination" domain="destination" /> - </method> - - <!-- - Method: message.stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="stop" index="150"> - <doc> - On receipt of this method, a producer of messages MUST set his credit to zero for the given - destination. This obeys the generic semantics of command completion, i.e. when confirmation - is issued credit MUST be zero and no further messages will be sent until such a time as - further credit is received. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="destination" domain="destination" /> - </method> - - <!-- - Method: message.empty - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="empty" index="200" label="empty queue"> - <doc> - Signals that a queue does not contain any messages; usually sent in response to the get - method. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - </method> - - <!-- - Method: message.offset - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="offset" index="210" label="return an offset"> - <doc> - Returns the data offset into a reference body; usually sent in response to resume method. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="value" domain="offset" label="offset into a reference body"> - <doc> - Offset in bytes into message body data. - </doc> - </field> - </method> - - </class> - - <!-- == Class: binding ======================================================================= --> - - <class name="binding" index="130" - label="provides the ability to query bindings"> - <doc> - This is a utility class for querying and exchange about its bindings to queues. - </doc> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MAY" /> - - <!-- - Method: binding.query - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="query" synchronous="1" index="10" - label="request information about bindings to an exchange"> - <doc> - This method is used to request information on the bindings to a particular exchange. - </doc> - - <chassis name="server" implement="MUST" /> - - <field name="ticket" domain="access-ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - exchange's access realm. - </doc> - </rule> - </field> - - <field name="exchange" domain="shortstr" label="the exchange name"> - <doc> - The name of the exchange for which binding information is being requested. If not - specified explicitly the default exchange is implied. - </doc> - </field> - - <field name="queue" domain="shortstr" label="a queue name"> - <doc> - If populated then determine whether the given queue is bound to the exchange. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="a routing-key"> - <doc> - If populated defines the routing key of the binding of interest, if not populated the - request will ignore the routing key on bindings when searching for a match. - </doc> - </field> - - <field name="arguments" domain="table" label="a set of binding arguments"> - <doc> - If populated defines the arguments of the binding of interest if not populated the request - will ignore the arguments on bindings when searching for a match - </doc> - </field> - - <result> - <struct size="long" type="11"> - <doc> - This method is used in response to a query and conveys information on the bindings to a - particular exchange. - </doc> - - <field name="exchange-not-found" domain="bit" label="indicate an unknown exchange"> - <doc> - If set, the exchange for which information was requested is not known. - </doc> - </field> - - <field name="queue-not-found" domain="bit" label="indicate an unknown queue"> - <doc> - If set, the queue specified is not known. - </doc> - </field> - - <field name="queue-not-matched" domain="bit" label="indicate no matching queue"> - <doc> - A bit which if set indicates that no binding was found from the specified exchange to the - specified queue. - </doc> - </field> - - <field name="key-not-matched" domain="bit" label="indicate no matching routing key"> - <doc> - A bit which if set indicates that no binding was found from the specified exchange with - the specified routing key. - </doc> - </field> - - <field name="args-not-matched" domain="bit" label="indicate no matching args"> - <doc> - A bit which if set indicates that no binding was found from the specified exchange with - the specified arguments. - </doc> - </field> - </struct> - </result> - </method> - - </class> - - <!-- == Class: execution ===================================================================== --> - - <class name="execution" index="140"> - <doc> - This class allows for efficiently communicating information about completion of processing. - </doc> - - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - - <!-- - Method: execution.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="flush" index="10" label="request an execution.complete return method"> - <doc> - Requests notification of all currently complete commands. The server should issue an - execution.complete at the earliest possible opportunity. - </doc> - - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - </method> - - <!-- - Method: execution.complete - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="complete" index="20"> - <doc> - Signals completion of all commands such that command-id <= cumulative-execution-mark, or - command-id is in the set defined by ranged-execution-set. This can be sent spontaneously, - in response to a execution.flush, or as requested by use of the sync bit. - - <!-- TODO: See chapter (TBD here) for how command ids are computed. --> - </doc> - - <rule name="unique-encoding"> - <doc> - In order to ensure a canonical wire representation, the value cumulative-execution-mark + - 1 must not be covered by the ranged-execution-set. - </doc> - </rule> - - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - - <field name="cumulative-execution-mark" domain="rfc1982-long" - label="Low-water mark for command ids"> - <doc> - The low-water mark for executed command-ids. All ids below this mark have been executed; - above this mark, there are gaps containing unexecuted command ids (i.e. discontinuous). By - definition, the first id above this mark (if it exists) is an unexecuted command-id. - </doc> - </field> - - <field name="ranged-execution-set" domain="rfc1982-long-set" - label="Set of discontinuous command ids above cumulative-execution-mark"> - <doc> - This set contains a sequence of discontinuous executed command-ids above the low-water - mark (i.e. above the first gap of unexecuted command ids). - </doc> - </field> - </method> - - <!-- - Method: execution.noop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="noop" index="30" label="a command that does nothing"> - <doc> - This command may be used when it is desirable to send a command that has no effect. This - situation can occur after issuing a number of commands with sync=False. If, after issuing - the commands, a peer wishes to receive confirmation of completion, the peer can do so by - sending an execution.noop command with sync=True. - </doc> - - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - </method> - - <!-- - Method: execution.result - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="result" index="40" label="carries execution results"> - <doc> - This method carries data resulting from the execution of a command. - </doc> - - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - - <field name="command-id" domain="command-id"/> - <field name="data" domain="long-struct"/> - </method> - - <!-- - Method: execution.sync - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name="sync" index="50" label="request notification of completion for issued commands"> - <doc> - Requests notification (via execution.complete) when all commands issued prior to the sync - control are complete. If the recipient of this control has already notified the - sender that said commands are complete, it may safely ignore the control. - </doc> - - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - </method> - - </class> - -</amqp> diff --git a/qpid/specs/amqp.0-10-qpid-errata.stripped.xml b/qpid/specs/amqp.0-10-qpid-errata.stripped.xml new file mode 100644 index 0000000000..83ddf709e9 --- /dev/null +++ b/qpid/specs/amqp.0-10-qpid-errata.stripped.xml @@ -0,0 +1,1203 @@ +<?xml version="1.0"?> + +<!-- +(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. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="0" xmlns="http://www.amqp.org/schema/amqp.xsd" port="5672" minor="10"> + <type name="bin8" code="0x00" fixed-width="1"/> + <type name="int8" code="0x01" fixed-width="1"/> + <type name="uint8" code="0x02" fixed-width="1"/> + <type name="char" code="0x04" fixed-width="1"/> + <type name="boolean" code="0x08" fixed-width="1"/> + <type name="bin16" code="0x10" fixed-width="2"/> + <type name="int16" code="0x11" fixed-width="2"/> + <type name="uint16" code="0x12" fixed-width="2"/> + <type name="bin32" code="0x20" fixed-width="4"/> + <type name="int32" code="0x21" fixed-width="4"/> + <type name="uint32" code="0x22" fixed-width="4"/> + <type name="float" code="0x23" fixed-width="4"/> + <type name="char-utf32" code="0x27" fixed-width="4"/> + <type name="sequence-no" fixed-width="4"/> + <type name="bin64" code="0x30" fixed-width="8"/> + <type name="int64" code="0x31" fixed-width="8"/> + <type name="uint64" code="0x32" fixed-width="8"/> + <type name="double" code="0x33" fixed-width="8"/> + <type name="datetime" code="0x38" fixed-width="8"/> + <type name="bin128" code="0x40" fixed-width="16"/> + <type name="uuid" code="0x48" fixed-width="16"/> + <type name="bin256" code="0x50" fixed-width="32"/> + <type name="bin512" code="0x60" fixed-width="64"/> + <type name="bin1024" code="0x70" fixed-width="128"/> + <type name="vbin8" code="0x80" variable-width="1"/> + <type name="str8-latin" code="0x84" variable-width="1"/> + <type name="str8" code="0x85" variable-width="1"/> + <type name="str8-utf16" code="0x86" variable-width="1"/> + <type name="vbin16" code="0x90" variable-width="2"/> + <type name="str16-latin" code="0x94" variable-width="2"/> + <type name="str16" code="0x95" variable-width="2"/> + <type name="str16-utf16" code="0x96" variable-width="2"/> + <type name="byte-ranges" variable-width="2"/> + <type name="sequence-set" variable-width="2"/> + <type name="vbin32" code="0xa0" variable-width="4"/> + <type name="map" code="0xa8" variable-width="4"/> + <type name="list" code="0xa9" variable-width="4"/> + <type name="array" code="0xaa" variable-width="4"/> + <type name="struct32" code="0xab" variable-width="4"/> + <type name="bin40" code="0xc0" fixed-width="5"/> + <type name="dec32" code="0xc8" fixed-width="5"/> + <type name="bin72" code="0xd0" fixed-width="9"/> + <type name="dec64" code="0xd8" fixed-width="9"/> + <type name="void" code="0xf0" fixed-width="0"/> + <type name="bit" code="0xf1" fixed-width="0"/> + <constant name="MIN-MAX-FRAME-SIZE" value="4096"/> + <domain name="segment-type" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + <choice name="header" value="2"/> + <choice name="body" value="3"/> + </enum> + </domain> + <domain name="track" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + </enum> + </domain> + <domain name="str16-array" type="array"/> + <class name="connection" code="0x1"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="close-code" type="uint16"> + <enum> + <choice name="normal" value="200"/> + <choice name="connection-forced" value="320"/> + <choice name="invalid-path" value="402"/> + <choice name="framing-error" value="501"/> + </enum> + </domain> + <domain name="amqp-host-url" type="str16"/> + <domain name="amqp-host-array" type="array"/> + <control name="start" code="0x1"> + <rule name="protocol-name"/> + <rule name="client-support"/> + <implement role="client" handle="MUST"/> + <response name="start-ok"/> + <field name="server-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanisms" type="str16-array" required="true"/> + <field name="locales" type="str16-array" required="true"> + <rule name="required-support"/> + </field> + </control> + <control name="start-ok" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="client-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanism" type="str8" required="true"> + <rule name="security"/> + <rule name="validity"/> + </field> + <field name="response" type="vbin32" required="true"/> + <field name="locale" type="str8" required="true"/> + </control> + <control name="secure" code="0x3"> + <implement role="client" handle="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="vbin32" required="true"/> + </control> + <control name="secure-ok" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="response" type="vbin32" required="true"/> + </control> + <control name="tune" code="0x5"> + <implement role="client" handle="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" type="uint16"/> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + </field> + <field name="heartbeat-min" type="uint16"/> + <field name="heartbeat-max" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="tune-ok" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="channel-max" type="uint16" required="true"> + <rule name="upper-limit"/> + <rule name="available-channels"/> + </field> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + <rule name="upper-limit"/> + <rule name="max-frame-size"/> + </field> + <field name="heartbeat" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="open" code="0x7"> + <implement role="server" handle="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" type="str8" required="true"> + <rule name="separation"/> + <rule name="security"/> + </field> + <field name="capabilities" type="str16-array"/> + <field name="insist" type="bit"> + <rule name="behavior"/> + </field> + </control> + <control name="open-ok" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="redirect" code="0x9"> + <rule name="usage"/> + <implement role="client" handle="MUST"/> + <field name="host" type="amqp-host-url" required="true"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="heartbeat" code="0xa"> + <implement role="client" handle="MAY"/> + <implement role="server" handle="MAY"/> + </control> + <control name="close" code="0xb"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <response name="close-ok"/> + <field name="reply-code" type="close-code" required="true"/> + <field name="reply-text" type="str8"/> + </control> + <control name="close-ok" code="0xc"> + <rule name="reporting"/> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + </control> + </class> + <class name="session" code="0x2"> + <rule name="attachment"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <role name="sender" implement="MUST"/> + <role name="receiver" implement="MUST"/> + <domain name="name" type="vbin16"/> + <domain name="detach-code" type="uint8"> + <enum> + <choice name="normal" value="0"/> + <choice name="session-busy" value="1"/> + <choice name="transport-busy" value="2"/> + <choice name="not-attached" value="3"/> + <choice name="unknown-ids" value="4"/> + </enum> + </domain> + <domain name="commands" type="sequence-set"/> + <struct name="header" size="1" pack="1"> + <field name="sync" type="bit"/> + </struct> + <struct name="command-fragment" size="0" pack="0"> + <field name="command-id" type="sequence-no" required="true"/> + <field name="byte-ranges" type="byte-ranges" required="true"/> + </struct> + <domain name="command-fragments" type="array"/> + <control name="attach" code="0x1"> + <rule name="one-transport-per-session"/> + <rule name="one-session-per-transport"/> + <rule name="idempotence"/> + <rule name="scoping"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <response name="attached"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + <field name="force" type="bit"/> + </control> + <control name="attached" code="0x2"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detach" code="0x3"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detached" code="0x4"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + <field name="code" type="detach-code" required="true"/> + </control> + <control name="request-timeout" code="0x5"> + <rule name="maximum-granted-timeout"/> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <response name="timeout"/> + <field name="timeout" type="uint32"/> + </control> + <control name="timeout" code="0x6"> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <field name="timeout" type="uint32"/> + </control> + <control name="command-point" code="0x7"> + <rule name="newly-attached-transports"/> + <rule name="zero-offset"/> + <rule name="nonzero-offset"/> + <implement role="receiver" handle="MUST"/> + <field name="command-id" type="sequence-no" required="true"/> + <field name="command-offset" type="uint64" required="true"/> + </control> + <control name="expected" code="0x8"> + <rule name="include-next-command"/> + <rule name="commands-empty-means-new-session"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands" required="true"/> + <field name="fragments" type="command-fragments"/> + </control> + <control name="confirmed" code="0x9"> + <rule name="durability"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="exclude-known-complete"/> + </field> + <field name="fragments" type="command-fragments"/> + </control> + <control name="completed" code="0xa"> + <rule name="known-completed-reply"/> + <rule name="delayed-reply"/> + <rule name="merged-reply"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="completed-implies-confirmed"/> + <rule name="exclude-known-complete"/> + </field> + <field name="timely-reply" type="bit"/> + </control> + <control name="known-completed" code="0xb"> + <rule name="stateless"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="known-completed-implies-known-confirmed"/> + </field> + </control> + <control name="flush" code="0xc"> + <implement role="receiver" handle="MUST"/> + <field name="expected" type="bit"/> + <field name="confirmed" type="bit"/> + <field name="completed" type="bit"/> + </control> + <control name="gap" code="0xd"> + <rule name="gap-confirmation-and-completion"/> + <rule name="aborted-commands"/> + <rule name="completed-or-confirmed-commands"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"/> + </control> + </class> + <class name="execution" code="0x3"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="error-code" type="uint16"> + <enum> + <choice name="unauthorized-access" value="403"/> + <choice name="not-found" value="404"/> + <choice name="resource-locked" value="405"/> + <choice name="precondition-failed" value="406"/> + <choice name="resource-deleted" value="408"/> + <choice name="illegal-state" value="409"/> + <choice name="command-invalid" value="503"/> + <choice name="resource-limit-exceeded" value="506"/> + <choice name="not-allowed" value="530"/> + <choice name="illegal-argument" value="531"/> + <choice name="not-implemented" value="540"/> + <choice name="internal-error" value="541"/> + <choice name="invalid-argument" value="542"/> + </enum> + </domain> + <command name="sync" code="0x1"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + </command> + <command name="result" code="0x2"> + <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> + <command name="exception" code="0x3"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <field name="error-code" type="error-code" required="true"/> + <field name="command-id" type="sequence-no"/> + <field name="class-code" type="uint8"/> + <field name="command-code" type="uint8"/> + <field name="field-index" type="uint8"/> + <field name="description" type="str16"/> + <field name="error-info" type="map"/> + </command> + </class> + <class name="message" code="0x4"> + <rule name="persistent-message"/> + <rule name="no-persistent-message-discard"/> + <rule name="throttling"/> + <rule name="non-persistent-message-overflow"/> + <rule name="non-persistent-message-discard"/> + <rule name="min-priority-levels"/> + <rule name="priority-level-implementation"/> + <rule name="priority-delivery"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="destination" type="str8"/> + <domain name="accept-mode" type="uint8"> + <enum> + <choice name="explicit" value="0"/> + <choice name="none" value="1"/> + </enum> + </domain> + <domain name="acquire-mode" type="uint8"> + <enum> + <choice name="pre-acquired" value="0"/> + <choice name="not-acquired" value="1"/> + </enum> + </domain> + <domain name="reject-code" type="uint16"> + <enum> + <choice name="unspecified" value="0"/> + <choice name="unroutable" value="1"/> + <choice name="immediate" value="2"/> + </enum> + </domain> + <domain name="resume-id" type="str16"/> + <domain name="delivery-mode" type="uint8"> + <enum> + <choice name="non-persistent" value="1"/> + <choice name="persistent" value="2"/> + </enum> + </domain> + <domain name="delivery-priority" type="uint8"> + <enum> + <choice name="lowest" value="0"/> + <choice name="lower" value="1"/> + <choice name="low" value="2"/> + <choice name="below-average" value="3"/> + <choice name="medium" value="4"/> + <choice name="above-average" value="5"/> + <choice name="high" value="6"/> + <choice name="higher" value="7"/> + <choice name="very-high" value="8"/> + <choice name="highest" value="9"/> + </enum> + </domain> + <struct name="delivery-properties" code="0x1" size="4" pack="2"> + <field name="discard-unroutable" type="bit"/> + <field name="immediate" type="bit"/> + <field name="redelivered" type="bit"> + <rule name="implementation"/> + <rule name="hinting"/> + </field> + <field name="priority" type="delivery-priority" required="true"/> + <field name="delivery-mode" type="delivery-mode" required="true"/> + <field name="ttl" type="uint64"> + <rule name="ttl-decrement"/> + </field> + <field name="timestamp" type="datetime"/> + <field name="expiration" type="datetime"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + </struct> + <struct name="fragment-properties" code="0x2" size="4" pack="2"> + <field name="first" type="bit" default="1"/> + <field name="last" type="bit" default="1"/> + <field name="fragment-size" type="uint64"/> + </struct> + <struct name="reply-to" size="2" pack="2"> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + </struct> + <struct name="message-properties" code="0x3" size="4" pack="2"> + <field name="content-length" type="uint64"/> + <field name="message-id" type="uuid"> + <rule name="unique"/> + <rule name="immutable"/> + </field> + <field name="correlation-id" type="vbin16"/> + <field name="reply-to" type="reply-to"/> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="user-id" type="vbin16"> + <rule name="authentication"/> + </field> + <field name="app-id" type="vbin16"/> + <field name="application-headers" type="map"/> + </struct> + <domain name="flow-mode" type="uint8"> + <enum> + <choice name="credit" value="0"/> + <choice name="window" value="1"/> + </enum> + </domain> + <domain name="credit-unit" type="uint8"> + <enum> + <choice name="message" value="0"/> + <choice name="byte" value="1"/> + </enum> + </domain> + <command name="transfer" code="0x1"> + <rule name="transactional-publish"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <rule name="blank-destination"/> + <exception name="nonexistent-exchange" error-code="not-found"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <segments> + <header> + <entry type="delivery-properties"/> + <entry type="fragment-properties"/> + <entry type="message-properties"/> + </header> + <body/> + </segments> + </command> + <command name="accept" code="0x2"> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + </command> + <command name="reject" code="0x3"> + <rule name="alternate-exchange"/> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="code" type="reject-code" required="true"/> + <field name="text" type="str8"/> + </command> + <command name="release" code="0x4"> + <rule name="ordering"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="set-redelivered" type="bit"/> + </command> + <command name="acquire" code="0x5"> + <rule name="one-to-one"/> + <implement role="server" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <result> + <struct name="acquired" code="0x4" size="4" pack="2"> + <field name="transfers" type="session.commands" required="true"/> + </struct> + </result> + </command> + <command name="resume" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <exception name="destination-not-found" error-code="not-found"/> + </field> + <field name="resume-id" type="resume-id" required="true"> + <rule name="unknown-resume-id"/> + </field> + <result> + <struct name="message-resume-result" code="0x5" size="4" pack="2"> + <field name="offset" type="uint64"/> + </struct> + </result> + </command> + <command name="subscribe" code="0x7"> + <rule name="simultaneous-subscriptions"/> + <rule name="default-flow-mode"/> + <exception name="queue-deletion" error-code="resource-deleted"/> + <exception name="queue-not-found" error-code="not-found"/> + <rule name="initial-credit"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"/> + <field name="destination" type="destination"> + <exception name="unique-subscriber-destination" error-code="not-allowed"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + <field name="arguments" type="map"/> + </command> + <command name="cancel" code="0x8"> + <rule name="post-cancel-transfer-resolution"/> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination" required="true"> + <exception name="subscription-not-found" error-code="not-found"/> + </field> + </command> + <command name="set-flow-mode" code="0x9"> + <rule name="byte-accounting"/> + <rule name="mode-switching"/> + <rule name="default-flow-mode"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="flow-mode" type="flow-mode" required="true"/> + </command> + <command name="flow" code="0xa"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="unit" type="credit-unit" required="true"/> + <field name="value" type="uint32"/> + </command> + <command name="flush" code="0xb"> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + <command name="stop" code="0xc"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + </class> + <class name="tx" code="0x5"> + <rule name="duplicate-tracking"/> + <role name="server" implement="SHOULD"/> + <command name="select" code="0x1"> + <exception name="exactly-once" error-code="illegal-state"/> + <exception name="no-dtx" error-code="illegal-state"/> + <exception name="explicit-accepts" error-code="not-allowed"/> + <implement role="server" handle="MUST"/> + </command> + <command name="commit" code="0x2"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + <command name="rollback" code="0x3"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + </class> + <class name="dtx" code="0x6"> + <rule name="transactionality"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <domain name="xa-status" type="uint16"> + <enum> + <choice name="xa-ok" value="0"/> + <choice name="xa-rbrollback" value="1"/> + <choice name="xa-rbtimeout" value="2"/> + <choice name="xa-heurhaz" value="3"/> + <choice name="xa-heurcom" value="4"/> + <choice name="xa-heurrb" value="5"/> + <choice name="xa-heurmix" value="6"/> + <choice name="xa-rdonly" value="7"/> + </enum> + </domain> + <struct name="xa-result" code="0x1" size="4" pack="2"> + <field name="status" type="xa-status" required="true"/> + </struct> + <struct name="xid" code="0x4" size="4" pack="2"> + <field name="format" type="uint32" required="true"/> + <field name="global-id" type="vbin8" required="true"/> + <field name="branch-id" type="vbin8" required="true"/> + </struct> + <command name="select" code="0x1"> + <implement role="server" handle="MAY"/> + </command> + <command name="start" code="0x2"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="already-known" error-code="not-allowed"/> + <exception name="join-and-resume" error-code="not-allowed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-allowed"/> + </field> + <field name="join" type="bit"> + <exception name="unsupported" error-code="not-implemented"/> + </field> + <field name="resume" type="bit"/> + <result type="xa-result"/> + </command> + <command name="end" code="0x3"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="suspend-and-fail" error-code="not-allowed"/> + <rule name="success"/> + <rule name="session-closed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="not-associated" error-code="illegal-state"/> + </field> + <field name="fail" type="bit"> + <rule name="failure"/> + </field> + <field name="suspend" type="bit"> + <rule name="resume"/> + </field> + <result type="xa-result"/> + </command> + <command name="commit" code="0x4"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <field name="one-phase" type="bit"> + <exception name="one-phase" error-code="illegal-state"/> + <exception name="two-phase" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="forget" code="0x5"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + </command> + <command name="get-timeout" code="0x6"> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <result> + <struct name="get-timeout-result" code="0x2" size="4" pack="2"> + <field name="timeout" type="uint32" required="true"/> + </struct> + </result> + </command> + <command name="prepare" code="0x7"> + <exception name="illegal-state" error-code="illegal-state"/> + <rule name="obligation-1"/> + <rule name="obligation-2"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="recover" code="0x8"> + <implement role="server" handle="MAY"/> + <result> + <struct name="recover-result" code="0x3" size="4" pack="2"> + <field name="in-doubt" type="array" required="true"/> + </struct> + </result> + </command> + <command name="rollback" code="0x9"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="set-timeout" code="0xa"> + <rule name="effective"/> + <rule name="reset"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <field name="timeout" type="uint32" required="true"/> + </command> + </class> + <class name="exchange" code="0x7"> + <rule name="required-types"/> + <rule name="recommended-types"/> + <rule name="required-instances"/> + <rule name="default-exchange"/> + <rule name="default-access"/> + <rule name="extensions"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="minimum"/> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="reserved-names" error-code="not-allowed"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="type" type="str8" required="true"> + <exception name="typed" error-code="not-allowed"/> + <exception name="exchange-type-not-found" error-code="not-found"/> + </field> + <field name="alternate-exchange" type="name"> + <rule name="empty-name"/> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <rule name="double-failure"/> + </field> + <field name="passive" type="bit"> + <exception name="not-found" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="support"/> + <rule name="sticky"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="sticky"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="exists" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + <exception name="used-as-alternate" error-code="not-allowed"/> + </field> + <field name="if-unused" type="bit"> + <exception name="exchange-in-use" error-code="precondition-failed"/> + </field> + </command> + <command name="query" code="0x3"> + <implement role="server" handle="MUST"/> + <field name="name" type="str8"/> + <result> + <struct name="exchange-query-result" code="0x1" size="4" pack="2"> + <field name="type" type="str8"/> + <field name="durable" type="bit"/> + <field name="not-found" type="bit"/> + <field name="arguments" type="map"/> + </struct> + </result> + </command> + <command name="bind" code="0x4"> + <rule name="duplicates"/> + <rule name="durable-exchange"/> + <rule name="binding-count"/> + <rule name="multiple-bindings"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="empty-queue" error-code="invalid-argument"/> + <exception name="queue-existence" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="exchange-existence" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"/> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="unbind" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="non-existent-queue" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="non-existent-exchange" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"> + <exception name="non-existent-binding-key" error-code="not-found"/> + </field> + </command> + <command name="bound" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="str8"/> + <field name="queue" type="str8" required="true"/> + <field name="binding-key" type="str8"/> + <field name="arguments" type="map"/> + <result> + <struct name="exchange-bound-result" code="0x2" size="4" pack="2"> + <field name="exchange-not-found" type="bit"/> + <field name="queue-not-found" type="bit"/> + <field name="queue-not-matched" type="bit"/> + <field name="key-not-matched" type="bit"/> + <field name="args-not-matched" type="bit"/> + </struct> + </result> + </command> + </class> + <class name="queue" code="0x8"> + <rule name="any-content"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="default-binding"/> + <rule name="minimum-queues"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="reserved-prefix" error-code="not-allowed"/> + </field> + <field name="alternate-exchange" type="exchange.name"> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <exception name="unknown-exchange" error-code="not-found"/> + </field> + <field name="passive" type="bit"> + <exception name="passive" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="persistence"/> + <rule name="types"/> + <rule name="pre-existence"/> + </field> + <field name="exclusive" type="bit"> + <rule name="types"/> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="pre-existence"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + <field name="if-unused" type="bit"> + <exception name="if-unused-flag" error-code="precondition-failed"/> + </field> + <field name="if-empty" type="bit"> + <exception name="not-empty" error-code="precondition-failed"/> + </field> + </command> + <command name="purge" code="0x3"> + <rule name="empty"/> + <rule name="pending-messages"/> + <rule name="purge-recovery"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + </command> + <command name="query" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"/> + <result> + <struct name="queue-query-result" code="0x1" size="4" pack="2"> + <field name="queue" type="name" required="true"/> + <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" required="true"/> + <field name="subscriber-count" type="uint32" required="true"/> + </struct> + </result> + </command> + </class> + <class name="file" code="0x9"> + <rule name="reliable-storage"/> + <rule name="no-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="file-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="reply-to" type="str8"/> + <field name="message-id" type="str8"/> + <field name="filename" type="str8"/> + <field name="timestamp" type="datetime"/> + <field name="cluster-id" type="str8"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"> + <rule name="prefetch-discretion"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="no-ack" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="open" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="open-ok"/> + <field name="identifier" type="str8"/> + <field name="content-size" type="uint64"> + <rule name="content-size"/> + </field> + </command> + <command name="open-ok" code="0x7"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="stage"/> + <field name="staged-size" type="uint64"> + <rule name="behavior"/> + <rule name="staging"/> + </field> + </command> + <command name="stage" code="0x8"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="publish" code="0x9"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <field name="identifier" type="str8"/> + </command> + <command name="return" code="0xa"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0xb"> + <rule name="redelivery-tracking"/> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="non-zero"/> + </field> + <field name="redelivered" type="bit"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="identifier" type="str8"/> + </command> + <command name="ack" code="0xc"> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="multiple" type="bit"> + <rule name="validation"/> + </field> + </command> + <command name="reject" code="0xd"> + <rule name="server-interpretation"/> + <rule name="not-selection"/> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="requeue" type="bit"> + <rule name="requeue-strategy"/> + </field> + </command> + </class> + <class name="stream" code="0xa"> + <rule name="overflow-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="stream-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="timestamp" type="datetime"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"/> + <field name="consume-rate" type="uint32"> + <rule name="ignore-prefetch"/> + <rule name="drop-by-priority"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <rule name="priority-based-delivery"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="publish" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="return" code="0x7"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="exchange" type="exchange.name"/> + <field name="queue" type="queue.name" required="true"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + </class> +</amqp> diff --git a/qpid/specs/amqp.0-10-qpid-errata.xml b/qpid/specs/amqp.0-10-qpid-errata.xml deleted file mode 100644 index f0fd17a59b..0000000000 --- a/qpid/specs/amqp.0-10-qpid-errata.xml +++ /dev/null @@ -1,6654 +0,0 @@ -<?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.0-10.dtd"> - -<amqp xmlns="http://www.amqp.org/schema/amqp.xsd" - major="0" minor="10" port="5672"> - - <!-- - ====================== == 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> - - <!-- - 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 | - +---------+------------------------+ - uint8 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="byte-ranges" variable-width="2" label="byte ranges within a 64-bit payload"> - <doc> - The byte-ranges type encodes up to 65535 octets worth of non-overlapping, non-touching, - ascending byte ranges within a 64-bit sequence of bytes. Each range is represented as an - inclusive lower and upper bound that identifies all the byte offsets included within a given - range. - </doc> - - <doc> - The number of octets of data is first encoded as a 16-bit unsigned integral value in network - byte order. This is then followed by the encoded representation of the ranges included in the - set. These MUST be encoded in ascending order, and any two ranges included in a given set MUST - NOT include overlapping or touching byte offsets. - </doc> - - <doc> - Each range is encoded as a pair of 64-bit unsigned integral values in network byte order - respectively representing the lower and upper bounds for that range. Note that because each - range is exactly 16 octets, the size in octets of the encoded ranges will always be 16 times - the number of ranges in the set. - </doc> - - <doc type="picture" title="Wire Format"> - +----= size OCTETs =----+ - | | - 2 OCTETs | 16 OCTETs | - +----------+-----+-----------+-----+ - | size | .../| range |\... | - +----------+---/ +-----------+ \---+ - uint16 / / \ \ - / / \ \ - / 8 OCTETs 8 OCTETs \ - +-----------+-----------+ - | lower | upper | - +-----------+-----------+ - uint64 uint64 - </doc> - - <doc type="bnf"> - byte-ranges = size *range - size = uint16 - range = lower upper - lower = uint64 - upper = uint64 - </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> - - <!-- Tracks --> - - <domain name="track" type="uint8" label="Valid values for transport level tracks"> - <doc> Tracks are defined in <xref ref="specification.transport.channels_and_tracks"/>. The - track domain defines the valid values that may used for the track indicator within the frame - header</doc> - <enum> - <choice name="control" value="0"> - <doc> - The track used for all controls. All controls defined in this specification MUST be sent - on track 0. - </doc> - </choice> - <choice name="command" value="1"> - <doc> - The track used for all commands. All commands defined in this specification MUST be sent - on track 1. - </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 a client to establish a network connection to a - server, and for both peers to operate the connection thereafter. - </doc> - - <doc type="grammar"> - connection = open-connection - *use-connection - close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <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="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> - - <!-- - Control: connection.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="start" code="0x1" label="start connection negotiation"> - <doc> - This control starts the connection negotiation process by telling the client the supported - security mechanisms and locales from which the client can choose. - </doc> - - <rule name="protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, it MUST close - the socket connection without sending any response 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> - - <implement role="client" handle="MUST" /> - - <response name="start-ok" /> - - <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> - - <field name="mechanisms" type="str16-array" label="available security mechanisms" - required="true"> - <doc> - A list of the security mechanisms that the server supports. - </doc> - </field> - - <field name="locales" type="str16-array" label="available message locales" required="true"> - <doc> - A list of the message locales that the server supports. The locale defines the language in - which the server will send reply texts. - </doc> - - <rule name="required-support"> - <doc> - The server MUST support at least the en_US locale. - </doc> - <doc type="scenario"> - Client connects to server and inspects the locales field. It checks for the presence of - the required locale(s). - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="start-ok" code="0x2" label="select security mechanism and locale"> - <doc> - This control selects a SASL security mechanism. - </doc> - - <implement role="server" handle="MUST" /> - - <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="mechanism" type="str8" label="selected security mechanism" required="true"> - <doc> - A single security mechanisms selected by the client, which must be one of those specified - by the server. - </doc> - - <rule name="security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it can handle - from the list provided by the server. - </doc> - </rule> - - <rule name="validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms proposed by the - server in the Start control, the server MUST close the connection without sending any - further data. - </doc> - <doc type="scenario"> - Client connects to server and sends an invalid security mechanism. The server must - respond by closing the connection (a socket close, with no connection close - negotiation). - </doc> - </rule> - </field> - - <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> - - <field name="locale" type="str8" label="selected message locale" required="true"> - <doc> - A single message locale selected by the client, which must be one of those specified by - the server. - </doc> - </field> - </control> - - <!-- - Control: connection.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="secure" code="0x3" label="security mechanism challenge"> - <doc> - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This control challenges the - client to provide more information. - </doc> - - <implement role="client" handle="MUST" /> - - <response name="secure-ok" /> - - <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.secure-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="secure-ok" 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.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="tune" code="0x5" label="propose connection tuning parameters"> - <doc> - This control proposes a set of connection configuration values to the client. The client can - accept and/or adjust these. - </doc> - - <implement role="client" handle="MUST" /> - - <response name="tune-ok" /> - - <field name="channel-max" type="uint16" label="proposed maximum channels"> - <doc> - The maximum total number of channels that the server allows per connection. If this is not - set it means that the server does not impose a fixed limit, but the number of allowed - channels may be limited by available server resources. - </doc> - </field> - - <field name="max-frame-size" type="uint16" label="proposed maximum frame size"> - <doc> - The largest frame size that the server proposes for the connection. The client can - negotiate a lower value. If this is not set means that the server does not impose any - specific limit but may reject very large frames if it cannot allocate resources for them. - </doc> - - <rule name="minimum"> - <doc> - Until the max-frame-size has been negotiated, both peers MUST accept frames of up to - MIN-MAX-FRAME-SIZE octets large, and the minimum negotiated value for max-frame-size is - also MIN-MAX-FRAME-SIZE. - </doc> - <doc type="scenario"> - Client connects to server and sends a large properties field, creating a frame of - MIN-MAX-FRAME-SIZE octets. The server must accept this frame. - </doc> - </rule> - </field> - - <field name="heartbeat-min" type="uint16" label="the minimum supported heartbeat delay"> - <doc> - The minimum delay, in seconds, of the connection heartbeat supported by the server. If - this is not set it means the server does not support sending heartbeats. - </doc> - </field> - - <field name="heartbeat-max" type="uint16" label="the maximum supported heartbeat delay"> - <doc> - The maximum delay, in seconds, of the connection heartbeat supported by the server. If - this is not set it means the server has no maximum. - </doc> - - <rule name="permitted-range"> - <doc> - The heartbeat-max value must be greater than or equal to the value supplied in the - heartbeat-min field. - </doc> - </rule> - - <rule name="no-heartbeat-min"> - <doc> - If no heartbeat-min is supplied, then the heartbeat-max field MUST remain empty. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.tune-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="tune-ok" code="0x6" label="negotiate connection tuning parameters"> - <doc> - This control sends the client's connection tuning parameters to the server. Certain fields - are negotiated, others provide capability information. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="channel-max" type="uint16" label="negotiated maximum channels" required="true"> - <doc> - The maximum total number of channels that the client will use per connection. - </doc> - - <rule name="upper-limit"> - <doc> - If the client specifies a channel max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementers. - </doc> - - </rule> - - <rule name="available-channels"> - <doc> - If the client agrees to a channel-max of N channels, then the channels available for - communication between client and server are precisely the channels numbered 0 to (N-1). - </doc> - </rule> - </field> - - <field name="max-frame-size" type="uint16" label="negotiated maximum frame size"> - <doc> - The largest frame size that the client and server will use for the connection. If it is - not set means that the client does not impose any specific limit but may reject very large - frames if it cannot allocate resources for them. Note that the max-frame-size limit - applies principally to content frames, where large contents can be broken into frames of - arbitrary size. - </doc> - - <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, and the minimum negotiated value for max-frame-size is - also MIN-MAX-FRAME-SIZE. - </doc> - </rule> - - <rule name="upper-limit"> - <doc> - If the client specifies a max-frame-size that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementers. - </doc> - </rule> - - <rule name="max-frame-size"> - <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="heartbeat" type="uint16" label="negotiated heartbeat delay"> - <doc> - The delay, in seconds, of the connection heartbeat chosen by the client. If it is not set - it means the client does not want a heartbeat. - </doc> - - <rule name="permitted-range"> - <doc> - The chosen heartbeat MUST be in the range supplied by the heartbeat-min and - heartbeat-max fields of connection.tune. - </doc> - </rule> - - <rule name="no-heartbeat-min"> - <doc> - The heartbeat field MUST NOT be set if the heartbeat-min field of connection.tune was - not set by the server. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open" code="0x7" label="open connection to 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" /> - - <response name="open-ok" /> - <response name="redirect" /> - - <field name="virtual-host" type="str8" label="virtual host name" required="true"> - <doc> - The name of the virtual host to work with. - </doc> - - <rule name="separation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full separation of - exchanges, queues, and all associated entities per virtual host. An application, - connected to a specific virtual host, MUST NOT be able to access resources of another - virtual host. - </doc> - </rule> - - <rule name="security"> - <doc> - The server SHOULD verify that the client has permission to access the specified virtual - host. - </doc> - </rule> - </field> - - <field name="capabilities" type="str16-array" label="required capabilities"> - <doc> - The client can specify zero or more capability names. The server can use this to determine - how to process the client's connection request. - </doc> - </field> - - <field name="insist" type="bit" label="insist on connecting to server"> - <doc> - In a configuration with multiple collaborating servers, the server may respond to a - connection.open control with a Connection.Redirect. The insist option tells the server - that the client is insisting on a connection to the specified server. - </doc> - <rule name="behavior"> - <doc> - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect control. If it cannot accept the client's connection request it - should respond by closing the connection with a suitable reply code. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open-ok" code="0x8" label="signal that connection is ready"> - <doc> - This control signals to the client that the connection is ready for use. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="known-hosts" type="amqp-host-array" label="alternate hosts which may be used in - the case of failure"> - <doc> - Specifies an array of equivalent or alternative hosts that the server knows about, which - will normally include the current server itself. Each entry in the array will be in the - form of an IP address or DNS name, optionally followed by a colon and a port number. - Clients can cache this information and use it when reconnecting to a server after a - failure. This field may be empty. - </doc> - </field> - </control> - - <!-- - Control: connection.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="redirect" code="0x9" label="redirects client to other server"> - <doc> - This control redirects the client to another server, based on the requested virtual host - and/or capabilities. - </doc> - - <rule name="usage"> - <doc> - When getting the connection.redirect control, the client SHOULD reconnect to the host - specified, and if that host is not present, to any of the hosts specified in the - known-hosts list. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - - <field name="host" type="amqp-host-url" label="server to connect to" required="true"> - <doc> - Specifies the server to connect to. - </doc> - </field> - - <field name="known-hosts" type="amqp-host-array" label="alternate hosts to try in case of - failure"> - <doc> - An array of equivalent or alternative hosts that the server knows about. - </doc> - </field> - </control> - - <!-- - Control: connection.heartbeat - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="heartbeat" code="0xa" 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> - <implement role="client" handle="MAY" /> - <implement role="server" handle="MAY" /> - </control> - - <!-- - Control: connection.close - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="close" code="0xb" 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" /> - - <response name="close-ok" /> - - <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> - - <!-- - Control: connection.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="close-ok" code="0xc" label="confirm a connection close"> - <doc> - This control confirms a connection.close control and tells the recipient that it is safe to - release resources for the connection and close the socket. - </doc> - - <rule name="reporting"> - <doc> - A peer that detects a socket closure without having received a Close-Ok handshake control - SHOULD log the error. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - <implement role="server" handle="MUST" /> - </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> - 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="header" size="1" pack="1"> - <doc> - The session header appears on commands after the class and command id, but prior to command - arguments. - </doc> - - <field name="sync" type="bit" label="request notification of completion"> - <doc> - Request notification of completion for this command. - </doc> - </field> - </struct> - - <struct name="command-fragment" size="0" pack="0" label="byte-ranges within a set of commands"> - - <field name="command-id" type="sequence-no" required="true"> - - </field> - <field name="byte-ranges" type="byte-ranges" required="true"> - - </field> - </struct> - - <domain name="command-fragments" type="array" label="an array of values of type - command-fragment"/> - - <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="MAY" /> - - <response name="attached"/> - <response name="detached"/> - - <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> - </control> - - <control name="attached" code="0x2" label="confirm attachment to the named session"> - <doc> - Confirms successful attachment of the transport to the named session. - </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 session now attached to the current transport. - </doc> - </field> - </control> - - <control name="detach" code="0x3" label="detach from the named session"> - <doc> - Detaches the current transport from the named session. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="detached"/> - - <field name="name" type="name" label="the session name" required="true"> - <doc> - Identifies the session to detach. - </doc> - </field> - </control> - - <control name="detached" code="0x4" label="confirm detachment from the named session"> - <doc> - Confirms detachment of the current transport from the named session. - </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> - </control> - - <!-- - Execution state is the set of confirmed, and completed incoming commands, as well as the set - of outgoing in-doubt commands held for replay. - --> - - <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> - - <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"/> - <field name="command-offset" type="uint64" label="the byte offset within the command" - required="true"/> - </control> - - <control name="expected" code="0x8" label="informs the peer of expected commands"> - <doc> - This control is sent by the receiver of commands and handled by the sender of commands. It - informs the sender of what commands and command fragments are expected at the receiver. - This control is only sent in response to a flush control with the expected flag set. The - expected control is never sent spontaneously. - </doc> - - <rule name="include-next-command"> - <doc> - The set of expected commands MUST include the next command after the highest seen command. - </doc> - </rule> - - <rule name="commands-empty-means-new-session"> - <doc> - The set of expected commands MUST have zero elements if and only if the sender holds no - execution state for the session (i.e. it is a new session). - </doc> - </rule> - - <rule name="no-overlaps"> - <doc> - If a command-id appears in the commands field, it MUST NOT appear in the fragments field. - </doc> - </rule> - - <rule name="minimal-fragments"> - <doc> - When choice is permitted, a command MUST appear in the commands field rather than the - fragments field. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="expected commands" required="true"/> - <field name="fragments" type="command-fragments" label="expected fragments" /> - </control> - - <control name="confirmed" code="0x9" label="notifies of confirmed commands"> - <doc> - This control is sent by the receiver of commands and handled by the sender of commands. This - sends the set of commands that will definitely be completed by this peer to the sender. This - excludes commands known by the receiver to be considered confirmed or complete at the - sender. - </doc> - <doc> - This control must be sent if the partner requests the set of confirmed commands using the - session.flush control with the confirmed flag set. - </doc> - <doc> - This control may be sent spontaneously. One reason for separating confirmation from - completion is for large persistent messages, where the receipt (and storage to a durable - store) of part of the message will result in less data needing to be replayed in the case of - transport failure during transmission. - </doc> - <doc> - A simple implementation of an AMQP client or server may be implemented to take no action on - receipt of session.confirmed controls, and take action only when receiving - session.completed controls. - </doc> - <doc> - A simple implementation of an AMQP client or server may be implemented such that it never - spontaneously sends session.confirmed and that when requested for the set of confirmed - commands (via the session.flush control) it responds with the same set of commands as it - would to when the set of completed commands was requested (trivially all completed commands - are confirmed). - </doc> - - <rule name="durability"> - <doc> - If a command has durable implications, it MUST NOT be confirmed until the fact of the - command has been recorded on durable media. - </doc> - </rule> - - <rule name="no-overlaps"> - <doc> - If a command-id appears in the commands field, it MUST NOT appear in the fragments field. - </doc> - </rule> - - <rule name="minimal-fragments"> - <doc> - When choice is permitted, a command MUST appear in the commands field rather than the - fragments field. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="entirely confirmed commands"> - <rule name="exclude-known-complete"> - <doc> - Command-ids included in prior known-complete replies MUST be excluded from the set of - all confirmed commands. - </doc> - </rule> - </field> - <field name="fragments" type="command-fragments" label="partially confirmed commands"/> - </control> - - <control name="completed" code="0xa" label="notifies of command completion"> - <doc> - This control is sent by the receiver of commands, and handled by the sender of commands. It - informs the sender of all commands completed by the receiver. This excludes commands known - by the receiver to be considered complete at the sender. - </doc> - - <rule name="known-completed-reply"> - <doc> - The sender MUST eventually reply with a known-completed set that covers the completed ids. - </doc> - </rule> - - <rule name="delayed-reply"> - <doc> - The known-complete reply MAY be delayed at the senders discretion if the timely-reply - field is not set. - </doc> - </rule> - - <rule name="merged-reply"> - <doc> - Multiple replies may be merged by sending a single known-completed that includes the union - of the merged command-id sets. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="completed commands"> - <doc> - The ids of all completed commands. This excludes commands known by the receiver to be - considered complete at the sender. - </doc> - - <rule name="completed-implies-confirmed"> - <doc> - The sender MUST consider any completed commands to also be confirmed. - </doc> - </rule> - - <rule name="exclude-known-complete"> - <doc> - Command-ids included in prior known-complete replies MUST be excluded from the set of - all completed commands. - </doc> - </rule> - </field> - <field name="timely-reply" type="bit"> - <doc> - If set, the sender is no longer free to delay the known-completed reply. - </doc> - </field> - </control> - - <control name="known-completed" code="0xb" label="Inform peer of which commands are known to be - completed"> - <doc> - This control is sent by the sender of commands, and handled by the receiver of commands. It - is sent in reply to one or more completed controls from the receiver. It informs the - receiver that commands are known to be completed by the sender. - </doc> - - <rule name="stateless"> - <doc> - The sender need not keep state to generate this reply. It is sufficient to reply to any - completed control with an exact echo of the completed ids. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="commands" type="commands" label="commands known to be complete"> - <doc> - The set of completed commands for one or more session.completed controls. - </doc> - - <rule name="known-completed-implies-known-confirmed"> - <doc> - The receiver MUST treat any of the specified commands to be considered by the sender as - confirmed as well as completed. - </doc> - </rule> - </field> - </control> - - <control name="flush" code="0xc" label="requests a session.completed"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. It - requests that the receiver produce the indicated command sets. The receiver should issue the - indicated sets at the earliest possible opportunity. - </doc> - - <implement role="receiver" handle="MUST" /> - - <field name="expected" type="bit" label="request notification of expected commands"/> - <field name="confirmed" type="bit" label="request notification of confirmed commands"/> - <field name="completed" type="bit" label="request notification of completed commands"/> - </control> - - <control name="gap" code="0xd" label="indicates missing segments in the stream"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. It - sends command ranges for which there will be no further data forthcoming. The receiver - should proceed with the next available commands that arrive after the gap. - </doc> - - <rule name="gap-confirmation-and-completion"> - <doc> - The command-ids covered by a session.gap MUST be added to the completed and confirmed sets - by the receiver. - </doc> - </rule> - - <rule name="aborted-commands"> - <doc> - If a session.gap covers a partially received command, the receiving peer MUST treat the - command as aborted. - </doc> - </rule> - - <rule name="completed-or-confirmed-commands"> - <doc> - If a session.gap covers a completed or confirmed command, the receiving peer MUST continue - to treat the command as completed or confirmed. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="commands" type="commands"> - <doc> - The set of command-ids that are contained in this gap. - </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="0x1" 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="0x2" 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> - - <!-- - Command: execution.exception - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="exception" code="0x3" 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> - - <implement role="client" handle="MUST"/> - <implement role="server" handle="MUST"/> - - <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"/> - - </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="destination" type="str8" label="destination for a message"> - <doc> - Specifies the destination to which the message is to be transferred. - </doc> - </domain> - - <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> - <choice name="immediate" value="2"> - <doc> - The rejected message had the immediate flag set to true, but at the time of the transfer - at least one of the queues to which it was to be routed did not have any subscriber able - to take the message. - </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="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="immediate" type="bit" label="Consider message unroutable if it cannot be - processed immediately"> - <doc> - If the immediate flag is set to true on a message transferred to a Server, then the - message should be considered unroutable (and not delivered to any queues) if, for any - queue that it is to be routed to according to the standard routing behavior, there is not - a subscription on that queue able to receive the message. The treatment of unroutable - messages is dependent on the value of the discard-unroutable flag. - </doc> - <doc> - The immediate flag is ignored on transferred to a Client. - </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 when a resume-id is specified. If no resume-id is - specified then this value should be ignored. - </doc> - </field> - </struct> - - <struct name="fragment-properties" size="4" code="0x2" pack="2"> - <doc> - These properties permit the transfer of message fragments. These may be used in conjunction - with byte level flow control to limit the rate at which large messages are received. Only - the first fragment carries the delivery-properties and message-properties. - - Syntactically each fragment appears as a complete message to the lower layers of the - protocol, however the model layer is required to treat all the fragments as a single - message. For example all fragments must be delivered to the same client. In pre-acquired - mode, no message fragments can be delivered by the broker until the entire message has been - received. - </doc> - - <field name="first" type="bit" default="1"> - <doc>True if this fragment contains the start of the message, false otherwise.</doc> - </field> - - <field name="last" type="bit" default="1"> - <doc>True if this fragment contains the end of the message, false otherwise.</doc> - </field> - - <field name="fragment-size" type="uint64"> - <doc>This field may optionally contain the size of the fragment.</doc> - </field> - </struct> - - <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="uuid" 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="reply-to" label="destination to reply to"> - <doc> - The destination of any message that is sent in reply to this message. - </doc> - </field> - - <field name="content-type" 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> - - <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> - - <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> - - <domain name="credit-unit" type="uint8" label="specifies the unit of credit balance"> - <enum> - <choice name="message" value="0"> - <doc>Indicates a value specified in messages.</doc> - </choice> - <choice name="byte" value="1"> - <doc>Indicates a value specified in bytes.</doc> - </choice> - </enum> - </domain> - - <!-- - 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="destination" type="destination" label="message destination"> - <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="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> - - <segments> - <header> - <entry type="delivery-properties"/> - <entry type="fragment-properties"/> - <entry type="message-properties"/> - </header> - <body/> - </segments> - </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> - - <!-- - Command: message.resume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="resume" code="0x6" label="resume an interrupted message transfer"> - <doc> - This command resumes an interrupted transfer. The recipient should return the amount of - partially transferred data associated with the given resume-id, or zero if there is no data - at all. If a non-zero result is returned, the recipient should expect to receive message - fragment(s) containing the remainder of the interrupted message. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"> - <doc> - The destination to which the remaining message fragments are transferred. - </doc> - - <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="resume-id" type="resume-id" required="true"> - <doc> - The name of the transfer being resumed. - </doc> - - <rule name="unknown-resume-id"> - <doc>If the resume-id is not known, the recipient MUST return an offset of zero.</doc> - </rule> - </field> - - <result> - <struct name="message-resume-result" size="4" code="0x5" pack="2"> - <field name="offset" type="uint64"> - <doc> - Indicates the amount of data already transferred. - </doc> - </field> - </struct> - </result> - </command> - - <!-- - Command: message.subscribe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="subscribe" 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"/> - - <field name="queue" type="queue.name" required="true"> - <doc> Specifies the name of the subscribed queue. </doc> - </field> - - <field name="destination" type="destination" label="incoming message destination"> - <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="accept-mode" type="accept-mode" required="true"> - <doc> The accept-mode to use for messages transferred from this subscription. </doc> - </field> - - <field name="acquire-mode" type="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="resume-id"> - <doc> Requests that the broker use the supplied resume-id when transferring messages for - this subscription. </doc> - </field> - - <field name="resume-ttl" type="uint64"> - <doc> Requested duration in milliseconds for the broker use as resume-ttl when transferring - messages for this subscription. </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: message.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x8" label="end a queue subscription"> - <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> - - <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="destination" type="destination" 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: message.set-flow-mode - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="set-flow-mode" code="0x9" label="set the flow control mode"> - <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 assemblies. This means that if there is not enough byte - credit available to send a complete message, the sender must either wait or use message - fragmentation (see the fragment-properties header struct) to send the first part of the - message data in a complete assembly. - - 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.flush - 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> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - <field name="flow-mode" type="flow-mode" required="true"> - <doc> - The new flow control mode. - </doc> - </field> - </command> - - <!-- - Command: message.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 unit to the available credit balance for the specified destination. - A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for - the given unit until the credit balance is zeroed with message.stop or message.flush. - </doc> - - <!-- throws no-such-destination --> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - <field name="unit" type="credit-unit" required="true"> - <doc> - The unit of value. - </doc> - </field> - <field name="value" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - </command> - - <!-- - Command: message.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="flush" 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="destination"/> - </command> - - <!-- - Command: message.stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stop" code="0xc" 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> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - </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="4" code="0x4" 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> - - <!-- == Class: file ========================================================================== --> - - <class name="file" code="0x9" label="work with file content"> - <doc> - The file class provides commands that support reliable file transfer. File messages have a - specific set of properties that are required for interoperability with file transfer - applications. File messages and acknowledgements are subject to session transactions. Note - that the file class does not provide message browsing commands; these are not compatible with - the staging model. Applications that need browsable file transfer should use Message content - and the Message class. - </doc> - - <doc type="grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - </doc> - - <rule name="reliable-storage"> - <doc> - The server MUST make a best-effort to hold file messages on a reliable storage mechanism. - </doc> - </rule> - - <rule name="no-discard"> - <doc> - The server MUST NOT discard a file message in case of a queue overflow. The server MUST use - the Session.Flow command to slow or stop a file message publisher when necessary. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for file messages, where priorities 0-4 - and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST support both automatic and explicit acknowledgements on file content. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- These are the properties for a File content --> - <struct name="file-properties" size="4" code="0x1" pack="2"> - <field name="content-type" type="str8" label="MIME content type" /> - <field name="content-encoding" type="str8" label="MIME content encoding" /> - <field name="headers" type="map" label="message header field table" /> - <field name="priority" type="uint8" label="message priority, 0 to 9" /> - <field name="reply-to" type="str8" label="destination to reply to" /> - <field name="message-id" type="str8" label="application message identifier" /> - <field name="filename" type="str8" label="message filename" /> - <field name="timestamp" type="datetime" label="message timestamp" /> - <!-- This field is deprecated pending review --> - <field name="cluster-id" type="str8" label="intra-cluster routing identifier" /> - </struct> - - <domain name="return-code" type="uint16" label="return code from server"> - <doc> - The return code. The AMQP return codes are defined by this enum. - </doc> - <enum> - <choice name="content-too-large" value="311"> - <doc> - The client attempted to transfer content larger than the server could accept. - </doc> - </choice> - - <choice name="no-route" value="312"> - <doc> - The exchange cannot route a message, most likely due to an invalid routing key. Only - when the mandatory flag is set. - </doc> - </choice> - - <choice name="no-consumers" value="313"> - <doc> - The exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: file.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos" code="0x1" label="specify quality of service"> - <doc> - This command requests a specific quality of service. The QoS can be specified for the - current session or for all sessions on the connection. The particular properties and - semantics of a qos command always depend on the content class semantics. Though the qos - command could in principle apply to both peers, it is currently meaningful only for the - server. - </doc> - - <implement role="server" handle="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" type="uint32" label="pre-fetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Pre-fetching gives a performance improvement. This field - specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other pre-fetch limits may still apply. The prefetch-size is ignored if - the no-ack option is set. - </doc> - </field> - - <field name="prefetch-count" type="uint16" label="pre-fetch window in messages"> - <doc> - Specifies a pre-fetch window in terms of whole messages. This is compatible with some file - API implementations. This field may be used in combination with the prefetch-size field; a - message will only be sent in advance if both pre-fetch windows (and those at the session - and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name="prefetch-discretion"> - <doc> - The server MAY send less data in advance than allowed by the client's specified - pre-fetch windows but it MUST NOT send more. - </doc> - </rule> - </field> - - <field name="global" type="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </command> - - <!-- - Command: file.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos-ok" code="0x2" label="confirm the requested qos"> - <doc> - This command tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <implement role="client" handle="MUST" /> - </command> - - <!-- - Command: file.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume" code="0x3" label="start a queue consumer"> - <doc> - This command asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the session they were created on, - or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <response name="consume-ok" /> - - <field name="queue" type="queue.name"> - <doc> - Specifies the name of the queue to consume from. - </doc> - - <exception name="queue-exists-if-empty" error-code="not-allowed"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="consumer-tag" type="str8"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. - </doc> - - <exception name="not-existing-consumer" error-code="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-empty-consumer-tag" error-code="not-allowed"> - <doc> - The client MUST NOT specify a tag that is empty or blank. - </doc> - <doc type="scenario"> - Attempt to create a consumers with an empty tag. - </doc> - </exception> - </field> - - <field name="no-local" type="bit"> - <doc>If the no-local field is set the server will not send messages to the connection that - published them.</doc> - </field> - - <field name="no-ack" type="bit" label="no acknowledgement needed"> - <doc> - If this field is set the server does not expect acknowledgements for messages. That is, - when a message is delivered to the client the server automatically and silently - acknowledges it on behalf of the client. This functionality increases performance but at - the cost of reliability. Messages can get lost if a client dies before it can deliver them - to the application. - </doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise an exception. - </doc> - </exception> - </field> - - <field name="nowait" type="bit" label="do not send a reply command"> - <doc> - If set, the server will not respond to the command. The client should not wait for a reply - command. If the server could not complete the command it will raise an exception. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </command> - - <command name="consume-ok" code="0x4" label="confirm a new consumer"> - <doc> - This command provides the client with a consumer tag which it MUST use in commands that work - with the consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </command> - - <!-- - Command: file.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x5" label="end a queue consumer"> - <doc> - This command cancels a consumer. This does not affect already delivered messages, but it - does mean the server will not send any more messages for that consumer. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - the identifier of the consumer to be cancelled. - </doc> - </field> - </command> - - <!-- - Command: file.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="open" code="0x6" label="request to start staging"> - <doc> - This command requests permission to start staging a message. Staging means sending the - message into a temporary area at the recipient end and then delivering the message by - referring to this temporary area. Staging is how the protocol handles partial file transfers - - if a message is partially staged and the connection breaks, the next time the sender - starts to stage it, it can restart from where it left off. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="open-ok" /> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier. This is an arbitrary string chosen by the sender. For - staging to work correctly the sender must use the same staging identifier when staging the - same message a second time after recovery from a failure. A good choice for the staging - identifier would be the SHA1 hash of the message properties data (including the original - filename, revised time, etc.). - </doc> - </field> - - <field name="content-size" type="uint64" label="message content size"> - <doc> - The size of the content in octets. The recipient may use this information to allocate or - check available space in advance, to avoid "disk full" errors during staging of very large - messages. - </doc> - - <rule name="content-size"> - <doc> - The sender MUST accurately fill the content-size field. Zero-length content is - permitted. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="open-ok" code="0x7" label="confirm staging ready"> - <doc> - This command confirms that the recipient is ready to accept staged data. If the message was - already partially-staged at a previous time the recipient will report the number of octets - already staged. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="stage" /> - - <field name="staged-size" type="uint64" label="already staged amount"> - <doc> - The amount of previously-staged content in octets. For a new message this will be zero. - </doc> - - <rule name="behavior"> - <doc> - The sender MUST start sending data from this octet offset in the message, counting from - zero. - </doc> - </rule> - - <rule name="staging"> - <doc> - The recipient MAY decide how long to hold partially-staged content and MAY implement - staging by always discarding partially-staged content. However if it uses the file - content type it MUST support the staging commands. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.stage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stage" code="0x8" label="stage message content"> - <doc> - This command stages the message, sending the message content to the recipient from the octet - offset specified in the Open-Ok command. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <segments> - <header required="true"> - <entry type="file-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: file.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="publish" code="0x9" label="publish a message"> - <doc> - This command publishes a staged file message to a specific exchange. The file message will - be routed to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise an exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <exception name="refusal" error-code="not-implemented"> - <doc> - The exchange MAY refuse file content in which case it MUST send an exception. - </doc> - </exception> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" type="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return command. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" type="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return command. If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier of the message to publish. The message must have been - staged. Note that a client can send the Publish command asynchronously without waiting for - staging to finish. - </doc> - </field> - </command> - - <!-- - Command: file.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="return" code="0xa" label="return a failed message"> - <doc> - This command returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="reply-code" type="return-code" /> - - <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> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="file-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: file.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="deliver" code="0xb" label="notify the client of a consumer message"> - <doc> - This command delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the consume command, - then the server responds with Deliver commands as and when messages arrive for that - consumer. - </doc> - - <rule name="redelivery-tracking"> - <doc> - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be non-processable (possibly - causing client applications to abort), and move the message to a dead letter queue. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - - <field name="delivery-tag" type="uint64" > - <doc> - The server-assigned and session-specific delivery tag - </doc> - - <rule name="non-zero"> - <doc> - The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, - meaning "all messages so far received". - </doc> - </rule> - </field> - - <field name="redelivered" type="bit" label="Indicate possible duplicate delivery"> - <doc> - This boolean flag indicates that the message may have been previously delivered to this - or another client. - </doc> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier of the message to deliver. The message must have been - staged. Note that a server can send the Deliver command asynchronously without waiting for - staging to finish. - </doc> - </field> - </command> - - <!-- - Command: file.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="ack" code="0xc" label="acknowledge one or more messages"> - <doc> - This command acknowledges one or more messages delivered via the Deliver command. The client - can ask to confirm a single message or a set of messages up to and including a specific - message. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="delivery-tag" type="uint64" > - <doc> - The identifier of the message being acknowledged - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then acknowledge it on - another. - </doc> - </rule> - </field> - - <field name="multiple" type="bit" label="acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages with a single command. If set to zero, the delivery tag - refers to a single message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding messages. - </doc> - - <rule name="validation"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered message, - and raise an exception if this is not the case. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="reject" code="0xd" label="reject an incoming message"> - <doc> - This command allows a client to reject a message. It can be used to return untreatable - messages to their original queue. Note that file content is staged before delivery, so the - client will not use this command to interrupt delivery of a large message. - </doc> - - <rule name="server-interpretation"> - <doc> - The server SHOULD interpret this command as meaning that the client is unable to process - the message at this time. - </doc> - </rule> - - <rule name="not-selection"> - <doc> - A client MUST NOT use this command as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="delivery-tag" type="uint64"> - <doc> - the identifier of the message to be rejected - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then reject it on another. - </doc> - </rule> - </field> - - <field name="requeue" type="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - </doc> - - <rule name="requeue-strategy"> - <doc> - The server MUST NOT deliver the message to the same client within the context of the - current session. The recommended strategy is to attempt to deliver the message to an - alternative consumer, and if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold the message on the queue - and redeliver it to the same client at a later stage. - </doc> - </rule> - </field> - </command> - - </class> - - <!-- == Class: stream ======================================================================== --> - - <class name="stream" code="0xa" label="work with streaming content"> - <doc> - The stream class provides commands that support multimedia streaming. The stream class uses - the following semantics: one message is one packet of data; delivery is unacknowledged and - unreliable; the consumer can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favor of high priority messages. - </doc> - - <doc type="grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - </doc> - - <rule name="overflow-discard"> - <doc> - The server SHOULD discard stream messages on a priority basis if the queue size exceeds some - configured limit. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for stream messages, where priorities - 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST implement automatic acknowledgements on stream content. That is, as soon as - a message is delivered to a client via a Deliver command, the server must remove it from the - queue. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- These are the properties for a Stream content --> - <struct name="stream-properties" size="4" code="0x1" pack="2"> - <field name="content-type" type="str8" label="MIME content type" /> - <field name="content-encoding" type="str8" label="MIME content encoding" /> - <field name="headers" type="map" label="message header field table" /> - <field name="priority" type="uint8" label="message priority, 0 to 9" /> - <field name="timestamp" type="datetime" label="message timestamp" /> - </struct> - - <domain name="return-code" type="uint16" label="return code from server"> - <doc> - The return code. The AMQP return codes are defined by this enum. - </doc> - <enum> - <choice name="content-too-large" value="311"> - <doc> - The client attempted to transfer content larger than the server could accept. - </doc> - </choice> - - <choice name="no-route" value="312"> - <doc> - The exchange cannot route a message, most likely due to an invalid routing key. Only - when the mandatory flag is set. - </doc> - </choice> - - <choice name="no-consumers" value="313"> - <doc> - The exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: stream.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos" code="0x1" label="specify quality of service"> - <doc> - This command requests a specific quality of service. The QoS can be specified for the - current session or for all sessions on the connection. The particular properties and - semantics of a qos command always depend on the content class semantics. Though the qos - command could in principle apply to both peers, it is currently meaningful only for the - server. - </doc> - - <implement role="server" handle="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" type="uint32" label="pre-fetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Pre-fetching gives a performance improvement. This field - specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other pre-fetch limits may still apply. - </doc> - </field> - - <field name="prefetch-count" type="uint16" label="pre-fetch window in messages"> - <doc> - Specifies a pre-fetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - pre-fetch windows (and those at the session and connection level) allow it. - </doc> - </field> - - <field name="consume-rate" type="uint32" label="transfer rate in octets/second"> - <doc> - Specifies a desired transfer rate in octets per second. This is usually determined by the - application that uses the streaming data. A value of zero means "no limit", i.e. as - rapidly as possible. - </doc> - - <rule name="ignore-prefetch"> - <doc> - The server MAY ignore the pre-fetch values and consume rates, depending on the type of - stream and the ability of the server to queue and/or reply it. - </doc> - </rule> - - <rule name="drop-by-priority"> - <doc> - The server MAY drop low-priority messages in favor of high-priority messages. - </doc> - </rule> - </field> - - <field name="global" type="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </command> - - <!-- - Command: stream.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos-ok" code="0x2" label="confirm the requested qos"> - <doc> - This command tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <implement role="client" handle="MUST" /> - </command> - - <!-- - Command: stream.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume" code="0x3" label="start a queue consumer"> - <doc> - This command asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the session they were created on, - or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <rule name="priority-based-delivery"> - <doc> - Streaming applications SHOULD use different sessions to select different streaming - resolutions. AMQP makes no provision for filtering and/or transforming streams except on - the basis of priority-based selective delivery of individual messages. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <response name="consume-ok" /> - - <field name="queue" type="queue.name"> - <doc> - Specifies the name of the queue to consume from. - </doc> - - <exception name="queue-exists-if-empty" error-code="not-allowed"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="consumer-tag" type="str8"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. - </doc> - - <exception name="not-existing-consumer" error-code="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-empty-consumer-tag" error-code="not-allowed"> - <doc> - The client MUST NOT specify a tag that is empty or blank. - </doc> - <doc type="scenario"> - Attempt to create a consumers with an empty tag. - </doc> - </exception> - </field> - - <field name="no-local" type="bit"> - <doc>If the no-local field is set the server will not send messages to the connection that - published them.</doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise an exception with return code 405 - (resource locked). - </doc> - </exception> - </field> - - <field name="nowait" type="bit" label="do not send a reply command"> - <doc> - If set, the server will not respond to the command. The client should not wait for a reply - command. If the server could not complete the command it will raise an exception. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </command> - - <!-- - Command: stream.consume-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume-ok" code="0x4" label="confirm a new consumer"> - <doc> - This command provides the client with a consumer tag which it may use in commands that work - with the consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </command> - - <!-- - Command: stream.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x5" label="end a queue consumer"> - <doc> - This command cancels a consumer. Since message delivery is asynchronous the client may - continue to receive messages for a short while after cancelling a consumer. It may process - or discard these as appropriate. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - </command> - - <!-- - Command: stream.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="publish" code="0x6" label="publish a message"> - <doc> - This command publishes a message to a specific exchange. The message will be routed to - queues as defined by the exchange configuration and distributed to any active consumers as - appropriate. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise an exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <exception name="refusal" error-code="not-implemented"> - <doc> - The exchange MAY refuse stream content in which case it MUST respond with an exception. - </doc> - </exception> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" type="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return command. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" type="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return command. If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: stream.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="return" code="0x7" label="return a failed message"> - <doc> - This command returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="reply-code" type="return-code" /> - - <field name="reply-text" type="str8" label="The localized reply text."> - <doc> - The localized reply text. This text can be logged as an aid to resolving issues. - </doc> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: stream.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="deliver" code="0x8" label="notify the client of a consumer message"> - <doc> - This command delivers a message to the client, via a consumer. In the asynchronous message - delivery model, the client starts a consumer using the Consume command, then the server - responds with Deliver commands as and when messages arrive for that consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - - <field name="delivery-tag" type="uint64"> - <doc> - The server-assigned and session-specific delivery tag - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then acknowledge it on - another. - </doc> - </rule> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="queue" type="queue.name" required="true"> - <doc> - Specifies the name of the queue that the message came from. Note that a single session can - start many consumers on different queues. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - </class> - -</amqp> diff --git a/qpid/specs/amqp.0-10.stripped.xml b/qpid/specs/amqp.0-10.stripped.xml new file mode 100644 index 0000000000..1c53608138 --- /dev/null +++ b/qpid/specs/amqp.0-10.stripped.xml @@ -0,0 +1,1200 @@ +<?xml version="1.0"?> + +<!-- +(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. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="0" xmlns="http://www.amqp.org/schema/amqp.xsd" port="5672" minor="10"> + <type name="bin8" code="0x00" fixed-width="1"/> + <type name="int8" code="0x01" fixed-width="1"/> + <type name="uint8" code="0x02" fixed-width="1"/> + <type name="char" code="0x04" fixed-width="1"/> + <type name="boolean" code="0x08" fixed-width="1"/> + <type name="bin16" code="0x10" fixed-width="2"/> + <type name="int16" code="0x11" fixed-width="2"/> + <type name="uint16" code="0x12" fixed-width="2"/> + <type name="bin32" code="0x20" fixed-width="4"/> + <type name="int32" code="0x21" fixed-width="4"/> + <type name="uint32" code="0x22" fixed-width="4"/> + <type name="float" code="0x23" fixed-width="4"/> + <type name="char-utf32" code="0x27" fixed-width="4"/> + <type name="sequence-no" fixed-width="4"/> + <type name="bin64" code="0x30" fixed-width="8"/> + <type name="int64" code="0x31" fixed-width="8"/> + <type name="uint64" code="0x32" fixed-width="8"/> + <type name="double" code="0x33" fixed-width="8"/> + <type name="datetime" code="0x38" fixed-width="8"/> + <type name="bin128" code="0x40" fixed-width="16"/> + <type name="uuid" code="0x48" fixed-width="16"/> + <type name="bin256" code="0x50" fixed-width="32"/> + <type name="bin512" code="0x60" fixed-width="64"/> + <type name="bin1024" code="0x70" fixed-width="128"/> + <type name="vbin8" code="0x80" variable-width="1"/> + <type name="str8-latin" code="0x84" variable-width="1"/> + <type name="str8" code="0x85" variable-width="1"/> + <type name="str8-utf16" code="0x86" variable-width="1"/> + <type name="vbin16" code="0x90" variable-width="2"/> + <type name="str16-latin" code="0x94" variable-width="2"/> + <type name="str16" code="0x95" variable-width="2"/> + <type name="str16-utf16" code="0x96" variable-width="2"/> + <type name="byte-ranges" variable-width="2"/> + <type name="sequence-set" variable-width="2"/> + <type name="vbin32" code="0xa0" variable-width="4"/> + <type name="map" code="0xa8" variable-width="4"/> + <type name="list" code="0xa9" variable-width="4"/> + <type name="array" code="0xaa" variable-width="4"/> + <type name="struct32" code="0xab" variable-width="4"/> + <type name="bin40" code="0xc0" fixed-width="5"/> + <type name="dec32" code="0xc8" fixed-width="5"/> + <type name="bin72" code="0xd0" fixed-width="9"/> + <type name="dec64" code="0xd8" fixed-width="9"/> + <type name="void" code="0xf0" fixed-width="0"/> + <type name="bit" code="0xf1" fixed-width="0"/> + <constant name="MIN-MAX-FRAME-SIZE" value="4096"/> + <domain name="segment-type" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + <choice name="header" value="2"/> + <choice name="body" value="3"/> + </enum> + </domain> + <domain name="track" type="uint8"> + <enum> + <choice name="control" value="0"/> + <choice name="command" value="1"/> + </enum> + </domain> + <domain name="str16-array" type="array"/> + <class name="connection" code="0x1"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="close-code" type="uint16"> + <enum> + <choice name="normal" value="200"/> + <choice name="connection-forced" value="320"/> + <choice name="invalid-path" value="402"/> + <choice name="framing-error" value="501"/> + </enum> + </domain> + <domain name="amqp-host-url" type="str16"/> + <domain name="amqp-host-array" type="array"/> + <control name="start" code="0x1"> + <rule name="protocol-name"/> + <rule name="client-support"/> + <implement role="client" handle="MUST"/> + <response name="start-ok"/> + <field name="server-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanisms" type="str16-array" required="true"/> + <field name="locales" type="str16-array" required="true"> + <rule name="required-support"/> + </field> + </control> + <control name="start-ok" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="client-properties" type="map"> + <rule name="required-fields"/> + </field> + <field name="mechanism" type="str8" required="true"> + <rule name="security"/> + <rule name="validity"/> + </field> + <field name="response" type="vbin32" required="true"/> + <field name="locale" type="str8" required="true"/> + </control> + <control name="secure" code="0x3"> + <implement role="client" handle="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="vbin32" required="true"/> + </control> + <control name="secure-ok" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="response" type="vbin32" required="true"/> + </control> + <control name="tune" code="0x5"> + <implement role="client" handle="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" type="uint16"/> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + </field> + <field name="heartbeat-min" type="uint16"/> + <field name="heartbeat-max" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="tune-ok" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="channel-max" type="uint16" required="true"> + <rule name="upper-limit"/> + <rule name="available-channels"/> + </field> + <field name="max-frame-size" type="uint16"> + <rule name="minimum"/> + <rule name="upper-limit"/> + <rule name="max-frame-size"/> + </field> + <field name="heartbeat" type="uint16"> + <rule name="permitted-range"/> + <rule name="no-heartbeat-min"/> + </field> + </control> + <control name="open" code="0x7"> + <implement role="server" handle="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" type="str8" required="true"> + <rule name="separation"/> + <rule name="security"/> + </field> + <field name="capabilities" type="str16-array"/> + <field name="insist" type="bit"> + <rule name="behavior"/> + </field> + </control> + <control name="open-ok" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="redirect" code="0x9"> + <rule name="usage"/> + <implement role="client" handle="MUST"/> + <field name="host" type="amqp-host-url" required="true"/> + <field name="known-hosts" type="amqp-host-array"/> + </control> + <control name="heartbeat" code="0xa"/> + <control name="close" code="0xb"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <response name="close-ok"/> + <field name="reply-code" type="close-code" required="true"/> + <field name="reply-text" type="str8"/> + </control> + <control name="close-ok" code="0xc"> + <rule name="reporting"/> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + </control> + </class> + <class name="session" code="0x2"> + <rule name="attachment"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <role name="sender" implement="MUST"/> + <role name="receiver" implement="MUST"/> + <domain name="name" type="vbin16"/> + <domain name="detach-code" type="uint8"> + <enum> + <choice name="normal" value="0"/> + <choice name="session-busy" value="1"/> + <choice name="transport-busy" value="2"/> + <choice name="not-attached" value="3"/> + <choice name="unknown-ids" value="4"/> + </enum> + </domain> + <domain name="commands" type="sequence-set"/> + <struct name="header" size="1" pack="1"> + <field name="sync" type="bit"/> + </struct> + <struct name="command-fragment" size="0" pack="0"> + <field name="command-id" type="sequence-no" required="true"/> + <field name="byte-ranges" type="byte-ranges" required="true"/> + </struct> + <domain name="command-fragments" type="array"/> + <control name="attach" code="0x1"> + <rule name="one-transport-per-session"/> + <rule name="one-session-per-transport"/> + <rule name="idempotence"/> + <rule name="scoping"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <response name="attached"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + <field name="force" type="bit"/> + </control> + <control name="attached" code="0x2"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detach" code="0x3"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="detached"/> + <field name="name" type="name" required="true"/> + </control> + <control name="detached" code="0x4"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="name" type="name" required="true"/> + <field name="code" type="detach-code" required="true"/> + </control> + <control name="request-timeout" code="0x5"> + <rule name="maximum-granted-timeout"/> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <response name="timeout"/> + <field name="timeout" type="uint32"/> + </control> + <control name="timeout" code="0x6"> + <implement role="sender" handle="MUST"/> + <implement role="receiver" handle="MUST"/> + <field name="timeout" type="uint32"/> + </control> + <control name="command-point" code="0x7"> + <rule name="newly-attached-transports"/> + <rule name="zero-offset"/> + <rule name="nonzero-offset"/> + <implement role="receiver" handle="MUST"/> + <field name="command-id" type="sequence-no" required="true"/> + <field name="command-offset" type="uint64" required="true"/> + </control> + <control name="expected" code="0x8"> + <rule name="include-next-command"/> + <rule name="commands-empty-means-new-session"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands" required="true"/> + <field name="fragments" type="command-fragments"/> + </control> + <control name="confirmed" code="0x9"> + <rule name="durability"/> + <rule name="no-overlaps"/> + <rule name="minimal-fragments"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="exclude-known-complete"/> + </field> + <field name="fragments" type="command-fragments"/> + </control> + <control name="completed" code="0xa"> + <rule name="known-completed-reply"/> + <rule name="delayed-reply"/> + <rule name="merged-reply"/> + <implement role="sender" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="completed-implies-confirmed"/> + <rule name="exclude-known-complete"/> + </field> + <field name="timely-reply" type="bit"/> + </control> + <control name="known-completed" code="0xb"> + <rule name="stateless"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"> + <rule name="known-completed-implies-known-confirmed"/> + </field> + </control> + <control name="flush" code="0xc"> + <implement role="receiver" handle="MUST"/> + <field name="expected" type="bit"/> + <field name="confirmed" type="bit"/> + <field name="completed" type="bit"/> + </control> + <control name="gap" code="0xd"> + <rule name="gap-confirmation-and-completion"/> + <rule name="aborted-commands"/> + <rule name="completed-or-confirmed-commands"/> + <implement role="receiver" handle="MUST"/> + <field name="commands" type="commands"/> + </control> + </class> + <class name="execution" code="0x3"> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="error-code" type="uint16"> + <enum> + <choice name="unauthorized-access" value="403"/> + <choice name="not-found" value="404"/> + <choice name="resource-locked" value="405"/> + <choice name="precondition-failed" value="406"/> + <choice name="resource-deleted" value="408"/> + <choice name="illegal-state" value="409"/> + <choice name="command-invalid" value="503"/> + <choice name="resource-limit-exceeded" value="506"/> + <choice name="not-allowed" value="530"/> + <choice name="illegal-argument" value="531"/> + <choice name="not-implemented" value="540"/> + <choice name="internal-error" value="541"/> + <choice name="invalid-argument" value="542"/> + </enum> + </domain> + <command name="sync" code="0x1"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + </command> + <command name="result" code="0x2"> + <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> + <command name="exception" code="0x3"> + <implement role="client" handle="MUST"/> + <implement role="server" handle="MUST"/> + <field name="error-code" type="error-code" required="true"/> + <field name="command-id" type="sequence-no"/> + <field name="class-code" type="uint8"/> + <field name="command-code" type="uint8"/> + <field name="field-index" type="uint8"/> + <field name="description" type="str16"/> + <field name="error-info" type="map"/> + </command> + </class> + <class name="message" code="0x4"> + <rule name="persistent-message"/> + <rule name="no-persistent-message-discard"/> + <rule name="throttling"/> + <rule name="non-persistent-message-overflow"/> + <rule name="non-persistent-message-discard"/> + <rule name="min-priority-levels"/> + <rule name="priority-level-implementation"/> + <rule name="priority-delivery"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="destination" type="str8"/> + <domain name="accept-mode" type="uint8"> + <enum> + <choice name="explicit" value="0"/> + <choice name="none" value="1"/> + </enum> + </domain> + <domain name="acquire-mode" type="uint8"> + <enum> + <choice name="pre-acquired" value="0"/> + <choice name="not-acquired" value="1"/> + </enum> + </domain> + <domain name="reject-code" type="uint16"> + <enum> + <choice name="unspecified" value="0"/> + <choice name="unroutable" value="1"/> + <choice name="immediate" value="2"/> + </enum> + </domain> + <domain name="resume-id" type="str16"/> + <domain name="delivery-mode" type="uint8"> + <enum> + <choice name="non-persistent" value="1"/> + <choice name="persistent" value="2"/> + </enum> + </domain> + <domain name="delivery-priority" type="uint8"> + <enum> + <choice name="lowest" value="0"/> + <choice name="lower" value="1"/> + <choice name="low" value="2"/> + <choice name="below-average" value="3"/> + <choice name="medium" value="4"/> + <choice name="above-average" value="5"/> + <choice name="high" value="6"/> + <choice name="higher" value="7"/> + <choice name="very-high" value="8"/> + <choice name="highest" value="9"/> + </enum> + </domain> + <struct name="delivery-properties" code="0x1" size="4" pack="2"> + <field name="discard-unroutable" type="bit"/> + <field name="immediate" type="bit"/> + <field name="redelivered" type="bit"> + <rule name="implementation"/> + <rule name="hinting"/> + </field> + <field name="priority" type="delivery-priority" required="true"/> + <field name="delivery-mode" type="delivery-mode" required="true"/> + <field name="ttl" type="uint64"> + <rule name="ttl-decrement"/> + </field> + <field name="timestamp" type="datetime"/> + <field name="expiration" type="datetime"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + </struct> + <struct name="fragment-properties" code="0x2" size="4" pack="2"> + <field name="first" type="bit" default="1"/> + <field name="last" type="bit" default="1"/> + <field name="fragment-size" type="uint64"/> + </struct> + <struct name="reply-to" size="2" pack="2"> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + </struct> + <struct name="message-properties" code="0x3" size="4" pack="2"> + <field name="content-length" type="uint64"/> + <field name="message-id" type="uuid"> + <rule name="unique"/> + <rule name="immutable"/> + </field> + <field name="correlation-id" type="vbin16"/> + <field name="reply-to" type="reply-to"/> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="user-id" type="vbin16"> + <rule name="authentication"/> + </field> + <field name="app-id" type="vbin16"/> + <field name="application-headers" type="map"/> + </struct> + <domain name="flow-mode" type="uint8"> + <enum> + <choice name="credit" value="0"/> + <choice name="window" value="1"/> + </enum> + </domain> + <domain name="credit-unit" type="uint8"> + <enum> + <choice name="message" value="0"/> + <choice name="byte" value="1"/> + </enum> + </domain> + <command name="transfer" code="0x1"> + <rule name="transactional-publish"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <rule name="blank-destination"/> + <exception name="nonexistent-exchange" error-code="not-found"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <segments> + <header> + <entry type="delivery-properties"/> + <entry type="fragment-properties"/> + <entry type="message-properties"/> + </header> + <body/> + </segments> + </command> + <command name="accept" code="0x2"> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + </command> + <command name="reject" code="0x3"> + <rule name="alternate-exchange"/> + <rule name="acquisition"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="code" type="reject-code" required="true"/> + <field name="text" type="str8"/> + </command> + <command name="release" code="0x4"> + <rule name="ordering"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MAY"/> + <field name="transfers" type="session.commands" required="true"/> + <field name="set-redelivered" type="bit"/> + </command> + <command name="acquire" code="0x5"> + <rule name="one-to-one"/> + <implement role="server" handle="MUST"/> + <field name="transfers" type="session.commands" required="true"/> + <result> + <struct name="acquired" code="0x4" size="4" pack="2"> + <field name="transfers" type="session.commands" required="true"/> + </struct> + </result> + </command> + <command name="resume" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"> + <exception name="destination-not-found" error-code="not-found"/> + </field> + <field name="resume-id" type="resume-id" required="true"> + <rule name="unknown-resume-id"/> + </field> + <result> + <struct name="message-resume-result" code="0x5" size="4" pack="2"> + <field name="offset" type="uint64"/> + </struct> + </result> + </command> + <command name="subscribe" code="0x7"> + <rule name="simultaneous-subscriptions"/> + <rule name="default-flow-mode"/> + <exception name="queue-deletion" error-code="resource-deleted"/> + <exception name="queue-not-found" error-code="not-found"/> + <rule name="initial-credit"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"/> + <field name="destination" type="destination"> + <exception name="unique-subscriber-destination" error-code="not-allowed"/> + </field> + <field name="accept-mode" type="accept-mode" required="true"/> + <field name="acquire-mode" type="acquire-mode" required="true"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="resume-id" type="resume-id"/> + <field name="resume-ttl" type="uint64"/> + <field name="arguments" type="map"/> + </command> + <command name="cancel" code="0x8"> + <rule name="post-cancel-transfer-resolution"/> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination" required="true"> + <exception name="subscription-not-found" error-code="not-found"/> + </field> + </command> + <command name="set-flow-mode" code="0x9"> + <rule name="byte-accounting"/> + <rule name="mode-switching"/> + <rule name="default-flow-mode"/> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="flow-mode" type="flow-mode" required="true"/> + </command> + <command name="flow" code="0xa"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + <field name="unit" type="credit-unit" required="true"/> + <field name="value" type="uint32"/> + </command> + <command name="flush" code="0xb"> + <implement role="server" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + <command name="stop" code="0xc"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <field name="destination" type="destination"/> + </command> + </class> + <class name="tx" code="0x5"> + <rule name="duplicate-tracking"/> + <role name="server" implement="SHOULD"/> + <command name="select" code="0x1"> + <exception name="exactly-once" error-code="illegal-state"/> + <exception name="no-dtx" error-code="illegal-state"/> + <exception name="explicit-accepts" error-code="not-allowed"/> + <implement role="server" handle="MUST"/> + </command> + <command name="commit" code="0x2"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + <command name="rollback" code="0x3"> + <exception name="select-required" error-code="illegal-state"/> + <implement role="server" handle="MUST"/> + </command> + </class> + <class name="dtx" code="0x6"> + <rule name="transactionality"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <domain name="xa-status" type="uint16"> + <enum> + <choice name="xa-ok" value="0"/> + <choice name="xa-rbrollback" value="1"/> + <choice name="xa-rbtimeout" value="2"/> + <choice name="xa-heurhaz" value="3"/> + <choice name="xa-heurcom" value="4"/> + <choice name="xa-heurrb" value="5"/> + <choice name="xa-heurmix" value="6"/> + <choice name="xa-rdonly" value="7"/> + </enum> + </domain> + <struct name="xa-result" code="0x1" size="4" pack="2"> + <field name="status" type="xa-status" required="true"/> + </struct> + <struct name="xid" size="2" pack="2"> + <field name="format" type="uint32" required="true"/> + <field name="global-id" type="vbin8" required="true"/> + <field name="branch-id" type="vbin8" required="true"/> + </struct> + <command name="select" code="0x1"> + <implement role="server" handle="MAY"/> + </command> + <command name="start" code="0x2"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="already-known" error-code="not-allowed"/> + <exception name="join-and-resume" error-code="not-allowed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-allowed"/> + </field> + <field name="join" type="bit"> + <exception name="unsupported" error-code="not-implemented"/> + </field> + <field name="resume" type="bit"/> + <result type="xa-result"/> + </command> + <command name="end" code="0x3"> + <exception name="illegal-state" error-code="illegal-state"/> + <exception name="suspend-and-fail" error-code="not-allowed"/> + <rule name="success"/> + <rule name="session-closed"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="not-associated" error-code="illegal-state"/> + </field> + <field name="fail" type="bit"> + <rule name="failure"/> + </field> + <field name="suspend" type="bit"> + <rule name="resume"/> + </field> + <result type="xa-result"/> + </command> + <command name="commit" code="0x4"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <field name="one-phase" type="bit"> + <exception name="one-phase" error-code="illegal-state"/> + <exception name="two-phase" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="forget" code="0x5"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + </command> + <command name="get-timeout" code="0x6"> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <result> + <struct name="get-timeout-result" code="0x2" size="4" pack="2"> + <field name="timeout" type="uint32" required="true"/> + </struct> + </result> + </command> + <command name="prepare" code="0x7"> + <exception name="illegal-state" error-code="illegal-state"/> + <rule name="obligation-1"/> + <rule name="obligation-2"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="recover" code="0x8"> + <implement role="server" handle="MAY"/> + <result> + <struct name="recover-result" code="0x3" size="4" pack="2"> + <field name="in-doubt" type="array" required="true"/> + </struct> + </result> + </command> + <command name="rollback" code="0x9"> + <exception name="illegal-state" error-code="illegal-state"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + <exception name="not-disassociated" error-code="illegal-state"/> + </field> + <result type="xa-result"/> + </command> + <command name="set-timeout" code="0xa"> + <rule name="effective"/> + <rule name="reset"/> + <implement role="server" handle="MAY"/> + <field name="xid" type="xid" required="true"> + <exception name="unknown-xid" error-code="not-found"/> + </field> + <field name="timeout" type="uint32" required="true"/> + </command> + </class> + <class name="exchange" code="0x7"> + <rule name="required-types"/> + <rule name="recommended-types"/> + <rule name="required-instances"/> + <rule name="default-exchange"/> + <rule name="default-access"/> + <rule name="extensions"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="minimum"/> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="reserved-names" error-code="not-allowed"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="type" type="str8" required="true"> + <exception name="typed" error-code="not-allowed"/> + <exception name="exchange-type-not-found" error-code="not-found"/> + </field> + <field name="alternate-exchange" type="name"> + <rule name="empty-name"/> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <rule name="double-failure"/> + </field> + <field name="passive" type="bit"> + <exception name="not-found" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="support"/> + <rule name="sticky"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="sticky"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="name" required="true"> + <exception name="exists" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + <exception name="used-as-alternate" error-code="not-allowed"/> + </field> + <field name="if-unused" type="bit"> + <exception name="exchange-in-use" error-code="precondition-failed"/> + </field> + </command> + <command name="query" code="0x3"> + <implement role="server" handle="MUST"/> + <field name="name" type="str8"/> + <result> + <struct name="exchange-query-result" code="0x1" size="4" pack="2"> + <field name="type" type="str8"/> + <field name="durable" type="bit"/> + <field name="not-found" type="bit"/> + <field name="arguments" type="map"/> + </struct> + </result> + </command> + <command name="bind" code="0x4"> + <rule name="duplicates"/> + <rule name="durable-exchange"/> + <rule name="binding-count"/> + <rule name="multiple-bindings"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="empty-queue" error-code="invalid-argument"/> + <exception name="queue-existence" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="exchange-existence" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"/> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="unbind" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="queue" type="queue.name" required="true"> + <exception name="non-existent-queue" error-code="not-found"/> + </field> + <field name="exchange" type="name" required="true"> + <exception name="non-existent-exchange" error-code="not-found"/> + <exception name="exchange-name-required" error-code="invalid-argument"/> + </field> + <field name="binding-key" type="str8" required="true"> + <exception name="non-existent-binding-key" error-code="not-found"/> + </field> + </command> + <command name="bound" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="str8"/> + <field name="queue" type="str8" required="true"/> + <field name="binding-key" type="str8"/> + <field name="arguments" type="map"/> + <result> + <struct name="exchange-bound-result" code="0x2" size="4" pack="2"> + <field name="exchange-not-found" type="bit"/> + <field name="queue-not-found" type="bit"/> + <field name="queue-not-matched" type="bit"/> + <field name="key-not-matched" type="bit"/> + <field name="args-not-matched" type="bit"/> + </struct> + </result> + </command> + </class> + <class name="queue" code="0x8"> + <rule name="any-content"/> + <role name="server" implement="MUST"/> + <role name="client" implement="MUST"/> + <domain name="name" type="str8"/> + <command name="declare" code="0x1"> + <rule name="default-binding"/> + <rule name="minimum-queues"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="reserved-prefix" error-code="not-allowed"/> + </field> + <field name="alternate-exchange" type="exchange.name"> + <exception name="pre-existing-exchange" error-code="not-allowed"/> + <exception name="unknown-exchange" error-code="not-found"/> + </field> + <field name="passive" type="bit"> + <exception name="passive" error-code="not-found"/> + </field> + <field name="durable" type="bit"> + <rule name="persistence"/> + <rule name="types"/> + <rule name="pre-existence"/> + </field> + <field name="exclusive" type="bit"> + <rule name="types"/> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="auto-delete" type="bit"> + <rule name="pre-existence"/> + </field> + <field name="arguments" type="map"> + <exception name="unknown-argument" error-code="not-implemented"/> + </field> + </command> + <command name="delete" code="0x2"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + <field name="if-unused" type="bit"> + <exception name="if-unused-flag" error-code="precondition-failed"/> + </field> + <field name="if-empty" type="bit"> + <exception name="not-empty" error-code="precondition-failed"/> + </field> + </command> + <command name="purge" code="0x3"> + <rule name="empty"/> + <rule name="pending-messages"/> + <rule name="purge-recovery"/> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"> + <exception name="empty-name" error-code="invalid-argument"/> + <exception name="queue-exists" error-code="not-found"/> + </field> + </command> + <command name="query" code="0x4"> + <implement role="server" handle="MUST"/> + <field name="queue" type="name" required="true"/> + <result> + <struct name="queue-query-result" code="0x1" size="4" pack="2"> + <field name="queue" type="name" required="true"/> + <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" required="true"/> + <field name="subscriber-count" type="uint32" required="true"/> + </struct> + </result> + </command> + </class> + <class name="file" code="0x9"> + <rule name="reliable-storage"/> + <rule name="no-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="file-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="reply-to" type="str8"/> + <field name="message-id" type="str8"/> + <field name="filename" type="str8"/> + <field name="timestamp" type="datetime"/> + <field name="cluster-id" type="str8"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"> + <rule name="prefetch-discretion"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="no-ack" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="open" code="0x6"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="open-ok"/> + <field name="identifier" type="str8"/> + <field name="content-size" type="uint64"> + <rule name="content-size"/> + </field> + </command> + <command name="open-ok" code="0x7"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <response name="stage"/> + <field name="staged-size" type="uint64"> + <rule name="behavior"/> + <rule name="staging"/> + </field> + </command> + <command name="stage" code="0x8"> + <implement role="server" handle="MUST"/> + <implement role="client" handle="MUST"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="publish" code="0x9"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <field name="identifier" type="str8"/> + </command> + <command name="return" code="0xa"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="file-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0xb"> + <rule name="redelivery-tracking"/> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="non-zero"/> + </field> + <field name="redelivered" type="bit"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <field name="identifier" type="str8"/> + </command> + <command name="ack" code="0xc"> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="multiple" type="bit"> + <rule name="validation"/> + </field> + </command> + <command name="reject" code="0xd"> + <rule name="server-interpretation"/> + <rule name="not-selection"/> + <implement role="server" handle="MUST"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="requeue" type="bit"> + <rule name="requeue-strategy"/> + </field> + </command> + </class> + <class name="stream" code="0xa"> + <rule name="overflow-discard"/> + <rule name="priority-levels"/> + <rule name="acknowledgement-support"/> + <role name="server" implement="MAY"/> + <role name="client" implement="MAY"/> + <struct name="stream-properties" code="0x1" size="4" pack="2"> + <field name="content-type" type="str8"/> + <field name="content-encoding" type="str8"/> + <field name="headers" type="map"/> + <field name="priority" type="uint8"/> + <field name="timestamp" type="datetime"/> + </struct> + <domain name="return-code" type="uint16"> + <enum> + <choice name="content-too-large" value="311"/> + <choice name="no-route" value="312"/> + <choice name="no-consumers" value="313"/> + </enum> + </domain> + <command name="qos" code="0x1"> + <implement role="server" handle="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" type="uint32"/> + <field name="prefetch-count" type="uint16"/> + <field name="consume-rate" type="uint32"> + <rule name="ignore-prefetch"/> + <rule name="drop-by-priority"/> + </field> + <field name="global" type="bit"/> + </command> + <command name="qos-ok" code="0x2"> + <implement role="client" handle="MUST"/> + </command> + <command name="consume" code="0x3"> + <rule name="min-consumers"/> + <rule name="priority-based-delivery"/> + <implement role="server" handle="MUST"/> + <response name="consume-ok"/> + <field name="queue" type="queue.name"> + <exception name="queue-exists-if-empty" error-code="not-allowed"/> + </field> + <field name="consumer-tag" type="str8"> + <exception name="not-existing-consumer" error-code="not-allowed"/> + <exception name="not-empty-consumer-tag" error-code="not-allowed"/> + </field> + <field name="no-local" type="bit"/> + <field name="exclusive" type="bit"> + <exception name="in-use" error-code="resource-locked"/> + </field> + <field name="nowait" type="bit"/> + <field name="arguments" type="map"/> + </command> + <command name="consume-ok" code="0x4"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="cancel" code="0x5"> + <implement role="server" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + </command> + <command name="publish" code="0x6"> + <implement role="server" handle="MUST"/> + <field name="exchange" type="exchange.name"> + <rule name="default"/> + <exception name="refusal" error-code="not-implemented"/> + </field> + <field name="routing-key" type="str8"/> + <field name="mandatory" type="bit"> + <rule name="implementation"/> + </field> + <field name="immediate" type="bit"> + <rule name="implementation"/> + </field> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="return" code="0x7"> + <implement role="client" handle="MUST"/> + <field name="reply-code" type="return-code"/> + <field name="reply-text" type="str8"/> + <field name="exchange" type="exchange.name"/> + <field name="routing-key" type="str8"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + <command name="deliver" code="0x8"> + <implement role="client" handle="MUST"/> + <field name="consumer-tag" type="str8"/> + <field name="delivery-tag" type="uint64"> + <rule name="session-local"/> + </field> + <field name="exchange" type="exchange.name"/> + <field name="queue" type="queue.name" required="true"/> + <segments> + <header required="true"> + <entry type="stream-properties"/> + </header> + <body/> + </segments> + </command> + </class> +</amqp> diff --git a/qpid/specs/amqp.0-10.xml b/qpid/specs/amqp.0-10.xml deleted file mode 100644 index 454114c17a..0000000000 --- a/qpid/specs/amqp.0-10.xml +++ /dev/null @@ -1,6652 +0,0 @@ -<?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.0-10.dtd"> - -<amqp xmlns="http://www.amqp.org/schema/amqp.xsd" - major="0" minor="10" port="5672"> - - <!-- - ====================== == 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> - - <!-- - 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="byte-ranges" variable-width="2" label="byte ranges within a 64-bit payload"> - <doc> - The byte-ranges type encodes up to 65535 octets worth of non-overlapping, non-touching, - ascending byte ranges within a 64-bit sequence of bytes. Each range is represented as an - inclusive lower and upper bound that identifies all the byte offsets included within a given - range. - </doc> - - <doc> - The number of octets of data is first encoded as a 16-bit unsigned integral value in network - byte order. This is then followed by the encoded representation of the ranges included in the - set. These MUST be encoded in ascending order, and any two ranges included in a given set MUST - NOT include overlapping or touching byte offsets. - </doc> - - <doc> - Each range is encoded as a pair of 64-bit unsigned integral values in network byte order - respectively representing the lower and upper bounds for that range. Note that because each - range is exactly 16 octets, the size in octets of the encoded ranges will always be 16 times - the number of ranges in the set. - </doc> - - <doc type="picture" title="Wire Format"> - +----= size OCTETs =----+ - | | - 2 OCTETs | 16 OCTETs | - +----------+-----+-----------+-----+ - | size | .../| range |\... | - +----------+---/ +-----------+ \---+ - uint16 / / \ \ - / / \ \ - / 8 OCTETs 8 OCTETs \ - +-----------+-----------+ - | lower | upper | - +-----------+-----------+ - uint64 uint64 - </doc> - - <doc type="bnf"> - byte-ranges = size *range - size = uint16 - range = lower upper - lower = uint64 - upper = uint64 - </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> - - <!-- Tracks --> - - <domain name="track" type="uint8" label="Valid values for transport level tracks"> - <doc> Tracks are defined in <xref ref="specification.transport.channels_and_tracks"/>. The - track domain defines the valid values that may used for the track indicator within the frame - header</doc> - <enum> - <choice name="control" value="0"> - <doc> - The track used for all controls. All controls defined in this specification MUST be sent - on track 0. - </doc> - </choice> - <choice name="command" value="1"> - <doc> - The track used for all commands. All commands defined in this specification MUST be sent - on track 1. - </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 a client to establish a network connection to a - server, and for both peers to operate the connection thereafter. - </doc> - - <doc type="grammar"> - connection = open-connection - *use-connection - close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <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="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> - - <!-- - Control: connection.start - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="start" code="0x1" label="start connection negotiation"> - <doc> - This control starts the connection negotiation process by telling the client the supported - security mechanisms and locales from which the client can choose. - </doc> - - <rule name="protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, it MUST close - the socket connection without sending any response 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> - - <implement role="client" handle="MUST" /> - - <response name="start-ok" /> - - <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> - - <field name="mechanisms" type="str16-array" label="available security mechanisms" - required="true"> - <doc> - A list of the security mechanisms that the server supports. - </doc> - </field> - - <field name="locales" type="str16-array" label="available message locales" required="true"> - <doc> - A list of the message locales that the server supports. The locale defines the language in - which the server will send reply texts. - </doc> - - <rule name="required-support"> - <doc> - The server MUST support at least the en_US locale. - </doc> - <doc type="scenario"> - Client connects to server and inspects the locales field. It checks for the presence of - the required locale(s). - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.start-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="start-ok" code="0x2" label="select security mechanism and locale"> - <doc> - This control selects a SASL security mechanism. - </doc> - - <implement role="server" handle="MUST" /> - - <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="mechanism" type="str8" label="selected security mechanism" required="true"> - <doc> - A single security mechanisms selected by the client, which must be one of those specified - by the server. - </doc> - - <rule name="security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it can handle - from the list provided by the server. - </doc> - </rule> - - <rule name="validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms proposed by the - server in the Start control, the server MUST close the connection without sending any - further data. - </doc> - <doc type="scenario"> - Client connects to server and sends an invalid security mechanism. The server must - respond by closing the connection (a socket close, with no connection close - negotiation). - </doc> - </rule> - </field> - - <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> - - <field name="locale" type="str8" label="selected message locale" required="true"> - <doc> - A single message locale selected by the client, which must be one of those specified by - the server. - </doc> - </field> - </control> - - <!-- - Control: connection.secure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="secure" code="0x3" label="security mechanism challenge"> - <doc> - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This control challenges the - client to provide more information. - </doc> - - <implement role="client" handle="MUST" /> - - <response name="secure-ok" /> - - <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.secure-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="secure-ok" 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.tune - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="tune" code="0x5" label="propose connection tuning parameters"> - <doc> - This control proposes a set of connection configuration values to the client. The client can - accept and/or adjust these. - </doc> - - <implement role="client" handle="MUST" /> - - <response name="tune-ok" /> - - <field name="channel-max" type="uint16" label="proposed maximum channels"> - <doc> - The maximum total number of channels that the server allows per connection. If this is not - set it means that the server does not impose a fixed limit, but the number of allowed - channels may be limited by available server resources. - </doc> - </field> - - <field name="max-frame-size" type="uint16" label="proposed maximum frame size"> - <doc> - The largest frame size that the server proposes for the connection. The client can - negotiate a lower value. If this is not set means that the server does not impose any - specific limit but may reject very large frames if it cannot allocate resources for them. - </doc> - - <rule name="minimum"> - <doc> - Until the max-frame-size has been negotiated, both peers MUST accept frames of up to - MIN-MAX-FRAME-SIZE octets large, and the minimum negotiated value for max-frame-size is - also MIN-MAX-FRAME-SIZE. - </doc> - <doc type="scenario"> - Client connects to server and sends a large properties field, creating a frame of - MIN-MAX-FRAME-SIZE octets. The server must accept this frame. - </doc> - </rule> - </field> - - <field name="heartbeat-min" type="uint16" label="the minimum supported heartbeat delay"> - <doc> - The minimum delay, in seconds, of the connection heartbeat supported by the server. If - this is not set it means the server does not support sending heartbeats. - </doc> - </field> - - <field name="heartbeat-max" type="uint16" label="the maximum supported heartbeat delay"> - <doc> - The maximum delay, in seconds, of the connection heartbeat supported by the server. If - this is not set it means the server has no maximum. - </doc> - - <rule name="permitted-range"> - <doc> - The heartbeat-max value must be greater than or equal to the value supplied in the - heartbeat-min field. - </doc> - </rule> - - <rule name="no-heartbeat-min"> - <doc> - If no heartbeat-min is supplied, then the heartbeat-max field MUST remain empty. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.tune-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="tune-ok" code="0x6" label="negotiate connection tuning parameters"> - <doc> - This control sends the client's connection tuning parameters to the server. Certain fields - are negotiated, others provide capability information. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="channel-max" type="uint16" label="negotiated maximum channels" required="true"> - <doc> - The maximum total number of channels that the client will use per connection. - </doc> - - <rule name="upper-limit"> - <doc> - If the client specifies a channel max that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementers. - </doc> - - </rule> - - <rule name="available-channels"> - <doc> - If the client agrees to a channel-max of N channels, then the channels available for - communication between client and server are precisely the channels numbered 0 to (N-1). - </doc> - </rule> - </field> - - <field name="max-frame-size" type="uint16" label="negotiated maximum frame size"> - <doc> - The largest frame size that the client and server will use for the connection. If it is - not set means that the client does not impose any specific limit but may reject very large - frames if it cannot allocate resources for them. Note that the max-frame-size limit - applies principally to content frames, where large contents can be broken into frames of - arbitrary size. - </doc> - - <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, and the minimum negotiated value for max-frame-size is - also MIN-MAX-FRAME-SIZE. - </doc> - </rule> - - <rule name="upper-limit"> - <doc> - If the client specifies a max-frame-size that is higher than the value provided by the - server, the server MUST close the connection without attempting a negotiated close. The - server may report the error in some fashion to assist implementers. - </doc> - </rule> - - <rule name="max-frame-size"> - <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="heartbeat" type="uint16" label="negotiated heartbeat delay"> - <doc> - The delay, in seconds, of the connection heartbeat chosen by the client. If it is not set - it means the client does not want a heartbeat. - </doc> - - <rule name="permitted-range"> - <doc> - The chosen heartbeat MUST be in the range supplied by the heartbeat-min and - heartbeat-max fields of connection.tune. - </doc> - </rule> - - <rule name="no-heartbeat-min"> - <doc> - The heartbeat field MUST NOT be set if the heartbeat-min field of connection.tune was - not set by the server. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open" code="0x7" label="open connection to 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" /> - - <response name="open-ok" /> - <response name="redirect" /> - - <field name="virtual-host" type="str8" label="virtual host name" required="true"> - <doc> - The name of the virtual host to work with. - </doc> - - <rule name="separation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full separation of - exchanges, queues, and all associated entities per virtual host. An application, - connected to a specific virtual host, MUST NOT be able to access resources of another - virtual host. - </doc> - </rule> - - <rule name="security"> - <doc> - The server SHOULD verify that the client has permission to access the specified virtual - host. - </doc> - </rule> - </field> - - <field name="capabilities" type="str16-array" label="required capabilities"> - <doc> - The client can specify zero or more capability names. The server can use this to determine - how to process the client's connection request. - </doc> - </field> - - <field name="insist" type="bit" label="insist on connecting to server"> - <doc> - In a configuration with multiple collaborating servers, the server may respond to a - connection.open control with a Connection.Redirect. The insist option tells the server - that the client is insisting on a connection to the specified server. - </doc> - <rule name="behavior"> - <doc> - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect control. If it cannot accept the client's connection request it - should respond by closing the connection with a suitable reply code. - </doc> - </rule> - </field> - </control> - - <!-- - Control: connection.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="open-ok" code="0x8" label="signal that connection is ready"> - <doc> - This control signals to the client that the connection is ready for use. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="known-hosts" type="amqp-host-array" label="alternate hosts which may be used in - the case of failure"> - <doc> - Specifies an array of equivalent or alternative hosts that the server knows about, which - will normally include the current server itself. Each entry in the array will be in the - form of an IP address or DNS name, optionally followed by a colon and a port number. - Clients can cache this information and use it when reconnecting to a server after a - failure. This field may be empty. - </doc> - </field> - </control> - - <!-- - Control: connection.redirect - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="redirect" code="0x9" label="redirects client to other server"> - <doc> - This control redirects the client to another server, based on the requested virtual host - and/or capabilities. - </doc> - - <rule name="usage"> - <doc> - When getting the connection.redirect control, the client SHOULD reconnect to the host - specified, and if that host is not present, to any of the hosts specified in the - known-hosts list. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - - <field name="host" type="amqp-host-url" label="server to connect to" required="true"> - <doc> - Specifies the server to connect to. - </doc> - </field> - - <field name="known-hosts" type="amqp-host-array" label="alternate hosts to try in case of - failure"> - <doc> - An array of equivalent or alternative hosts that the server knows about. - </doc> - </field> - </control> - - <!-- - Control: connection.heartbeat - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="heartbeat" code="0xa" 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="0xb" 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" /> - - <response name="close-ok" /> - - <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> - - <!-- - Control: connection.close-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <control name="close-ok" code="0xc" label="confirm a connection close"> - <doc> - This control confirms a connection.close control and tells the recipient that it is safe to - release resources for the connection and close the socket. - </doc> - - <rule name="reporting"> - <doc> - A peer that detects a socket closure without having received a Close-Ok handshake control - SHOULD log the error. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - <implement role="server" handle="MUST" /> - </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> - 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="header" size="1" pack="1"> - <doc> - The session header appears on commands after the class and command id, but prior to command - arguments. - </doc> - - <field name="sync" type="bit" label="request notification of completion"> - <doc> - Request notification of completion for this command. - </doc> - </field> - </struct> - - <struct name="command-fragment" size="0" pack="0" label="byte-ranges within a set of commands"> - - <field name="command-id" type="sequence-no" required="true"> - - </field> - <field name="byte-ranges" type="byte-ranges" required="true"> - - </field> - </struct> - - <domain name="command-fragments" type="array" label="an array of values of type - command-fragment"/> - - <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="MAY" /> - - <response name="attached"/> - <response name="detached"/> - - <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> - </control> - - <control name="attached" code="0x2" label="confirm attachment to the named session"> - <doc> - Confirms successful attachment of the transport to the named session. - </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 session now attached to the current transport. - </doc> - </field> - </control> - - <control name="detach" code="0x3" label="detach from the named session"> - <doc> - Detaches the current transport from the named session. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="detached"/> - - <field name="name" type="name" label="the session name" required="true"> - <doc> - Identifies the session to detach. - </doc> - </field> - </control> - - <control name="detached" code="0x4" label="confirm detachment from the named session"> - <doc> - Confirms detachment of the current transport from the named session. - </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> - </control> - - <!-- - Execution state is the set of confirmed, and completed incoming commands, as well as the set - of outgoing in-doubt commands held for replay. - --> - - <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> - - <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"/> - <field name="command-offset" type="uint64" label="the byte offset within the command" - required="true"/> - </control> - - <control name="expected" code="0x8" label="informs the peer of expected commands"> - <doc> - This control is sent by the receiver of commands and handled by the sender of commands. It - informs the sender of what commands and command fragments are expected at the receiver. - This control is only sent in response to a flush control with the expected flag set. The - expected control is never sent spontaneously. - </doc> - - <rule name="include-next-command"> - <doc> - The set of expected commands MUST include the next command after the highest seen command. - </doc> - </rule> - - <rule name="commands-empty-means-new-session"> - <doc> - The set of expected commands MUST have zero elements if and only if the sender holds no - execution state for the session (i.e. it is a new session). - </doc> - </rule> - - <rule name="no-overlaps"> - <doc> - If a command-id appears in the commands field, it MUST NOT appear in the fragments field. - </doc> - </rule> - - <rule name="minimal-fragments"> - <doc> - When choice is permitted, a command MUST appear in the commands field rather than the - fragments field. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="expected commands" required="true"/> - <field name="fragments" type="command-fragments" label="expected fragments" /> - </control> - - <control name="confirmed" code="0x9" label="notifies of confirmed commands"> - <doc> - This control is sent by the receiver of commands and handled by the sender of commands. This - sends the set of commands that will definitely be completed by this peer to the sender. This - excludes commands known by the receiver to be considered confirmed or complete at the - sender. - </doc> - <doc> - This control must be sent if the partner requests the set of confirmed commands using the - session.flush control with the confirmed flag set. - </doc> - <doc> - This control may be sent spontaneously. One reason for separating confirmation from - completion is for large persistent messages, where the receipt (and storage to a durable - store) of part of the message will result in less data needing to be replayed in the case of - transport failure during transmission. - </doc> - <doc> - A simple implementation of an AMQP client or server may be implemented to take no action on - receipt of session.confirmed controls, and take action only when receiving - session.completed controls. - </doc> - <doc> - A simple implementation of an AMQP client or server may be implemented such that it never - spontaneously sends session.confirmed and that when requested for the set of confirmed - commands (via the session.flush control) it responds with the same set of commands as it - would to when the set of completed commands was requested (trivially all completed commands - are confirmed). - </doc> - - <rule name="durability"> - <doc> - If a command has durable implications, it MUST NOT be confirmed until the fact of the - command has been recorded on durable media. - </doc> - </rule> - - <rule name="no-overlaps"> - <doc> - If a command-id appears in the commands field, it MUST NOT appear in the fragments field. - </doc> - </rule> - - <rule name="minimal-fragments"> - <doc> - When choice is permitted, a command MUST appear in the commands field rather than the - fragments field. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="entirely confirmed commands"> - <rule name="exclude-known-complete"> - <doc> - Command-ids included in prior known-complete replies MUST be excluded from the set of - all confirmed commands. - </doc> - </rule> - </field> - <field name="fragments" type="command-fragments" label="partially confirmed commands"/> - </control> - - <control name="completed" code="0xa" label="notifies of command completion"> - <doc> - This control is sent by the receiver of commands, and handled by the sender of commands. It - informs the sender of all commands completed by the receiver. This excludes commands known - by the receiver to be considered complete at the sender. - </doc> - - <rule name="known-completed-reply"> - <doc> - The sender MUST eventually reply with a known-completed set that covers the completed ids. - </doc> - </rule> - - <rule name="delayed-reply"> - <doc> - The known-complete reply MAY be delayed at the senders discretion if the timely-reply - field is not set. - </doc> - </rule> - - <rule name="merged-reply"> - <doc> - Multiple replies may be merged by sending a single known-completed that includes the union - of the merged command-id sets. - </doc> - </rule> - - <implement role="sender" handle="MUST" /> - - <field name="commands" type="commands" label="completed commands"> - <doc> - The ids of all completed commands. This excludes commands known by the receiver to be - considered complete at the sender. - </doc> - - <rule name="completed-implies-confirmed"> - <doc> - The sender MUST consider any completed commands to also be confirmed. - </doc> - </rule> - - <rule name="exclude-known-complete"> - <doc> - Command-ids included in prior known-complete replies MUST be excluded from the set of - all completed commands. - </doc> - </rule> - </field> - <field name="timely-reply" type="bit"> - <doc> - If set, the sender is no longer free to delay the known-completed reply. - </doc> - </field> - </control> - - <control name="known-completed" code="0xb" label="Inform peer of which commands are known to be - completed"> - <doc> - This control is sent by the sender of commands, and handled by the receiver of commands. It - is sent in reply to one or more completed controls from the receiver. It informs the - receiver that commands are known to be completed by the sender. - </doc> - - <rule name="stateless"> - <doc> - The sender need not keep state to generate this reply. It is sufficient to reply to any - completed control with an exact echo of the completed ids. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="commands" type="commands" label="commands known to be complete"> - <doc> - The set of completed commands for one or more session.completed controls. - </doc> - - <rule name="known-completed-implies-known-confirmed"> - <doc> - The receiver MUST treat any of the specified commands to be considered by the sender as - confirmed as well as completed. - </doc> - </rule> - </field> - </control> - - <control name="flush" code="0xc" label="requests a session.completed"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. It - requests that the receiver produce the indicated command sets. The receiver should issue the - indicated sets at the earliest possible opportunity. - </doc> - - <implement role="receiver" handle="MUST" /> - - <field name="expected" type="bit" label="request notification of expected commands"/> - <field name="confirmed" type="bit" label="request notification of confirmed commands"/> - <field name="completed" type="bit" label="request notification of completed commands"/> - </control> - - <control name="gap" code="0xd" label="indicates missing segments in the stream"> - <doc> - This control is sent by the sender of commands and handled by the receiver of commands. It - sends command ranges for which there will be no further data forthcoming. The receiver - should proceed with the next available commands that arrive after the gap. - </doc> - - <rule name="gap-confirmation-and-completion"> - <doc> - The command-ids covered by a session.gap MUST be added to the completed and confirmed sets - by the receiver. - </doc> - </rule> - - <rule name="aborted-commands"> - <doc> - If a session.gap covers a partially received command, the receiving peer MUST treat the - command as aborted. - </doc> - </rule> - - <rule name="completed-or-confirmed-commands"> - <doc> - If a session.gap covers a completed or confirmed command, the receiving peer MUST continue - to treat the command as completed or confirmed. - </doc> - </rule> - - <implement role="receiver" handle="MUST" /> - - <field name="commands" type="commands"> - <doc> - The set of command-ids that are contained in this gap. - </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="0x1" 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="0x2" 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> - - <!-- - Command: execution.exception - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="exception" code="0x3" 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> - - <implement role="client" handle="MUST"/> - <implement role="server" handle="MUST"/> - - <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"/> - - </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="destination" type="str8" label="destination for a message"> - <doc> - Specifies the destination to which the message is to be transferred. - </doc> - </domain> - - <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> - <choice name="immediate" value="2"> - <doc> - The rejected message had the immediate flag set to true, but at the time of the transfer - at least one of the queues to which it was to be routed did not have any subscriber able - to take the message. - </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="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="immediate" type="bit" label="Consider message unroutable if it cannot be - processed immediately"> - <doc> - If the immediate flag is set to true on a message transferred to a Server, then the - message should be considered unroutable (and not delivered to any queues) if, for any - queue that it is to be routed to according to the standard routing behavior, there is not - a subscription on that queue able to receive the message. The treatment of unroutable - messages is dependent on the value of the discard-unroutable flag. - </doc> - <doc> - The immediate flag is ignored on transferred to a Client. - </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 when a resume-id is specified. If no resume-id is - specified then this value should be ignored. - </doc> - </field> - </struct> - - <struct name="fragment-properties" size="4" code="0x2" pack="2"> - <doc> - These properties permit the transfer of message fragments. These may be used in conjunction - with byte level flow control to limit the rate at which large messages are received. Only - the first fragment carries the delivery-properties and message-properties. - - Syntactically each fragment appears as a complete message to the lower layers of the - protocol, however the model layer is required to treat all the fragments as a single - message. For example all fragments must be delivered to the same client. In pre-acquired - mode, no message fragments can be delivered by the broker until the entire message has been - received. - </doc> - - <field name="first" type="bit" default="1"> - <doc>True if this fragment contains the start of the message, false otherwise.</doc> - </field> - - <field name="last" type="bit" default="1"> - <doc>True if this fragment contains the end of the message, false otherwise.</doc> - </field> - - <field name="fragment-size" type="uint64"> - <doc>This field may optionally contain the size of the fragment.</doc> - </field> - </struct> - - <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="uuid" 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="reply-to" label="destination to reply to"> - <doc> - The destination of any message that is sent in reply to this message. - </doc> - </field> - - <field name="content-type" 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> - - <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> - - <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> - - <domain name="credit-unit" type="uint8" label="specifies the unit of credit balance"> - <enum> - <choice name="message" value="0"> - <doc>Indicates a value specified in messages.</doc> - </choice> - <choice name="byte" value="1"> - <doc>Indicates a value specified in bytes.</doc> - </choice> - </enum> - </domain> - - <!-- - 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="destination" type="destination" label="message destination"> - <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="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> - - <segments> - <header> - <entry type="delivery-properties"/> - <entry type="fragment-properties"/> - <entry type="message-properties"/> - </header> - <body/> - </segments> - </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> - - <!-- - Command: message.resume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="resume" code="0x6" label="resume an interrupted message transfer"> - <doc> - This command resumes an interrupted transfer. The recipient should return the amount of - partially transferred data associated with the given resume-id, or zero if there is no data - at all. If a non-zero result is returned, the recipient should expect to receive message - fragment(s) containing the remainder of the interrupted message. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"> - <doc> - The destination to which the remaining message fragments are transferred. - </doc> - - <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="resume-id" type="resume-id" required="true"> - <doc> - The name of the transfer being resumed. - </doc> - - <rule name="unknown-resume-id"> - <doc>If the resume-id is not known, the recipient MUST return an offset of zero.</doc> - </rule> - </field> - - <result> - <struct name="message-resume-result" size="4" code="0x5" pack="2"> - <field name="offset" type="uint64"> - <doc> - Indicates the amount of data already transferred. - </doc> - </field> - </struct> - </result> - </command> - - <!-- - Command: message.subscribe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="subscribe" 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"/> - - <field name="queue" type="queue.name" required="true"> - <doc> Specifies the name of the subscribed queue. </doc> - </field> - - <field name="destination" type="destination" label="incoming message destination"> - <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="accept-mode" type="accept-mode" required="true"> - <doc> The accept-mode to use for messages transferred from this subscription. </doc> - </field> - - <field name="acquire-mode" type="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="resume-id"> - <doc> Requests that the broker use the supplied resume-id when transferring messages for - this subscription. </doc> - </field> - - <field name="resume-ttl" type="uint64"> - <doc> Requested duration in milliseconds for the broker use as resume-ttl when transferring - messages for this subscription. </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: message.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x8" label="end a queue subscription"> - <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> - - <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="destination" type="destination" 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: message.set-flow-mode - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="set-flow-mode" code="0x9" label="set the flow control mode"> - <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 assemblies. This means that if there is not enough byte - credit available to send a complete message, the sender must either wait or use message - fragmentation (see the fragment-properties header struct) to send the first part of the - message data in a complete assembly. - - 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.flush - 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> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - <field name="flow-mode" type="flow-mode" required="true"> - <doc> - The new flow control mode. - </doc> - </field> - </command> - - <!-- - Command: message.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 unit to the available credit balance for the specified destination. - A value of (0xFFFFFFFF) indicates an infinite amount of credit. This disables any limit for - the given unit until the credit balance is zeroed with message.stop or message.flush. - </doc> - - <!-- throws no-such-destination --> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - <field name="unit" type="credit-unit" required="true"> - <doc> - The unit of value. - </doc> - </field> - <field name="value" type="uint32"> - <doc> - If the value is not set then this indicates an infinite amount of credit. - </doc> - </field> - </command> - - <!-- - Command: message.flush - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="flush" 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="destination"/> - </command> - - <!-- - Command: message.stop - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stop" code="0xc" 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> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <field name="destination" type="destination"/> - </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> - - <!-- == Class: file ========================================================================== --> - - <class name="file" code="0x9" label="work with file content"> - <doc> - The file class provides commands that support reliable file transfer. File messages have a - specific set of properties that are required for interoperability with file transfer - applications. File messages and acknowledgements are subject to session transactions. Note - that the file class does not provide message browsing commands; these are not compatible with - the staging model. Applications that need browsable file transfer should use Message content - and the Message class. - </doc> - - <doc type="grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - </doc> - - <rule name="reliable-storage"> - <doc> - The server MUST make a best-effort to hold file messages on a reliable storage mechanism. - </doc> - </rule> - - <rule name="no-discard"> - <doc> - The server MUST NOT discard a file message in case of a queue overflow. The server MUST use - the Session.Flow command to slow or stop a file message publisher when necessary. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for file messages, where priorities 0-4 - and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST support both automatic and explicit acknowledgements on file content. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- These are the properties for a File content --> - <struct name="file-properties" size="4" code="0x1" pack="2"> - <field name="content-type" type="str8" label="MIME content type" /> - <field name="content-encoding" type="str8" label="MIME content encoding" /> - <field name="headers" type="map" label="message header field table" /> - <field name="priority" type="uint8" label="message priority, 0 to 9" /> - <field name="reply-to" type="str8" label="destination to reply to" /> - <field name="message-id" type="str8" label="application message identifier" /> - <field name="filename" type="str8" label="message filename" /> - <field name="timestamp" type="datetime" label="message timestamp" /> - <!-- This field is deprecated pending review --> - <field name="cluster-id" type="str8" label="intra-cluster routing identifier" /> - </struct> - - <domain name="return-code" type="uint16" label="return code from server"> - <doc> - The return code. The AMQP return codes are defined by this enum. - </doc> - <enum> - <choice name="content-too-large" value="311"> - <doc> - The client attempted to transfer content larger than the server could accept. - </doc> - </choice> - - <choice name="no-route" value="312"> - <doc> - The exchange cannot route a message, most likely due to an invalid routing key. Only - when the mandatory flag is set. - </doc> - </choice> - - <choice name="no-consumers" value="313"> - <doc> - The exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: file.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos" code="0x1" label="specify quality of service"> - <doc> - This command requests a specific quality of service. The QoS can be specified for the - current session or for all sessions on the connection. The particular properties and - semantics of a qos command always depend on the content class semantics. Though the qos - command could in principle apply to both peers, it is currently meaningful only for the - server. - </doc> - - <implement role="server" handle="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" type="uint32" label="pre-fetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Pre-fetching gives a performance improvement. This field - specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other pre-fetch limits may still apply. The prefetch-size is ignored if - the no-ack option is set. - </doc> - </field> - - <field name="prefetch-count" type="uint16" label="pre-fetch window in messages"> - <doc> - Specifies a pre-fetch window in terms of whole messages. This is compatible with some file - API implementations. This field may be used in combination with the prefetch-size field; a - message will only be sent in advance if both pre-fetch windows (and those at the session - and connection level) allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name="prefetch-discretion"> - <doc> - The server MAY send less data in advance than allowed by the client's specified - pre-fetch windows but it MUST NOT send more. - </doc> - </rule> - </field> - - <field name="global" type="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </command> - - <!-- - Command: file.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos-ok" code="0x2" label="confirm the requested qos"> - <doc> - This command tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <implement role="client" handle="MUST" /> - </command> - - <!-- - Command: file.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume" code="0x3" label="start a queue consumer"> - <doc> - This command asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the session they were created on, - or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <response name="consume-ok" /> - - <field name="queue" type="queue.name"> - <doc> - Specifies the name of the queue to consume from. - </doc> - - <exception name="queue-exists-if-empty" error-code="not-allowed"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="consumer-tag" type="str8"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. - </doc> - - <exception name="not-existing-consumer" error-code="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-empty-consumer-tag" error-code="not-allowed"> - <doc> - The client MUST NOT specify a tag that is empty or blank. - </doc> - <doc type="scenario"> - Attempt to create a consumers with an empty tag. - </doc> - </exception> - </field> - - <field name="no-local" type="bit"> - <doc>If the no-local field is set the server will not send messages to the connection that - published them.</doc> - </field> - - <field name="no-ack" type="bit" label="no acknowledgement needed"> - <doc> - If this field is set the server does not expect acknowledgements for messages. That is, - when a message is delivered to the client the server automatically and silently - acknowledges it on behalf of the client. This functionality increases performance but at - the cost of reliability. Messages can get lost if a client dies before it can deliver them - to the application. - </doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise an exception. - </doc> - </exception> - </field> - - <field name="nowait" type="bit" label="do not send a reply command"> - <doc> - If set, the server will not respond to the command. The client should not wait for a reply - command. If the server could not complete the command it will raise an exception. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </command> - - <command name="consume-ok" code="0x4" label="confirm a new consumer"> - <doc> - This command provides the client with a consumer tag which it MUST use in commands that work - with the consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </command> - - <!-- - Command: file.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x5" label="end a queue consumer"> - <doc> - This command cancels a consumer. This does not affect already delivered messages, but it - does mean the server will not send any more messages for that consumer. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - the identifier of the consumer to be cancelled. - </doc> - </field> - </command> - - <!-- - Command: file.open - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="open" code="0x6" label="request to start staging"> - <doc> - This command requests permission to start staging a message. Staging means sending the - message into a temporary area at the recipient end and then delivering the message by - referring to this temporary area. Staging is how the protocol handles partial file transfers - - if a message is partially staged and the connection breaks, the next time the sender - starts to stage it, it can restart from where it left off. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="open-ok" /> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier. This is an arbitrary string chosen by the sender. For - staging to work correctly the sender must use the same staging identifier when staging the - same message a second time after recovery from a failure. A good choice for the staging - identifier would be the SHA1 hash of the message properties data (including the original - filename, revised time, etc.). - </doc> - </field> - - <field name="content-size" type="uint64" label="message content size"> - <doc> - The size of the content in octets. The recipient may use this information to allocate or - check available space in advance, to avoid "disk full" errors during staging of very large - messages. - </doc> - - <rule name="content-size"> - <doc> - The sender MUST accurately fill the content-size field. Zero-length content is - permitted. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.open-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="open-ok" code="0x7" label="confirm staging ready"> - <doc> - This command confirms that the recipient is ready to accept staged data. If the message was - already partially-staged at a previous time the recipient will report the number of octets - already staged. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <response name="stage" /> - - <field name="staged-size" type="uint64" label="already staged amount"> - <doc> - The amount of previously-staged content in octets. For a new message this will be zero. - </doc> - - <rule name="behavior"> - <doc> - The sender MUST start sending data from this octet offset in the message, counting from - zero. - </doc> - </rule> - - <rule name="staging"> - <doc> - The recipient MAY decide how long to hold partially-staged content and MAY implement - staging by always discarding partially-staged content. However if it uses the file - content type it MUST support the staging commands. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.stage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="stage" code="0x8" label="stage message content"> - <doc> - This command stages the message, sending the message content to the recipient from the octet - offset specified in the Open-Ok command. - </doc> - - <implement role="server" handle="MUST" /> - <implement role="client" handle="MUST" /> - - <segments> - <header required="true"> - <entry type="file-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: file.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="publish" code="0x9" label="publish a message"> - <doc> - This command publishes a staged file message to a specific exchange. The file message will - be routed to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise an exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <exception name="refusal" error-code="not-implemented"> - <doc> - The exchange MAY refuse file content in which case it MUST send an exception. - </doc> - </exception> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" type="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return command. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" type="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return command. If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier of the message to publish. The message must have been - staged. Note that a client can send the Publish command asynchronously without waiting for - staging to finish. - </doc> - </field> - </command> - - <!-- - Command: file.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="return" code="0xa" label="return a failed message"> - <doc> - This command returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="reply-code" type="return-code" /> - - <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> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="file-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: file.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="deliver" code="0xb" label="notify the client of a consumer message"> - <doc> - This command delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the consume command, - then the server responds with Deliver commands as and when messages arrive for that - consumer. - </doc> - - <rule name="redelivery-tracking"> - <doc> - The server SHOULD track the number of times a message has been delivered to clients and - when a message is redelivered a certain number of times - e.g. 5 times - without being - acknowledged, the server SHOULD consider the message to be non-processable (possibly - causing client applications to abort), and move the message to a dead letter queue. - </doc> - </rule> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - - <field name="delivery-tag" type="uint64" > - <doc> - The server-assigned and session-specific delivery tag - </doc> - - <rule name="non-zero"> - <doc> - The server MUST NOT use a zero value for delivery tags. Zero is reserved for client use, - meaning "all messages so far received". - </doc> - </rule> - </field> - - <field name="redelivered" type="bit" label="Indicate possible duplicate delivery"> - <doc> - This boolean flag indicates that the message may have been previously delivered to this - or another client. - </doc> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <field name="identifier" type="str8" label="staging identifier"> - <doc> - This is the staging identifier of the message to deliver. The message must have been - staged. Note that a server can send the Deliver command asynchronously without waiting for - staging to finish. - </doc> - </field> - </command> - - <!-- - Command: file.ack - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="ack" code="0xc" label="acknowledge one or more messages"> - <doc> - This command acknowledges one or more messages delivered via the Deliver command. The client - can ask to confirm a single message or a set of messages up to and including a specific - message. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="delivery-tag" type="uint64" > - <doc> - The identifier of the message being acknowledged - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then acknowledge it on - another. - </doc> - </rule> - </field> - - <field name="multiple" type="bit" label="acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the client can - acknowledge multiple messages with a single command. If set to zero, the delivery tag - refers to a single message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding messages. - </doc> - - <rule name="validation"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered message, - and raise an exception if this is not the case. - </doc> - </rule> - </field> - </command> - - <!-- - Command: file.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="reject" code="0xd" label="reject an incoming message"> - <doc> - This command allows a client to reject a message. It can be used to return untreatable - messages to their original queue. Note that file content is staged before delivery, so the - client will not use this command to interrupt delivery of a large message. - </doc> - - <rule name="server-interpretation"> - <doc> - The server SHOULD interpret this command as meaning that the client is unable to process - the message at this time. - </doc> - </rule> - - <rule name="not-selection"> - <doc> - A client MUST NOT use this command as a means of selecting messages to process. A rejected - message MAY be discarded or dead-lettered, not necessarily passed to another client. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <field name="delivery-tag" type="uint64"> - <doc> - the identifier of the message to be rejected - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then reject it on another. - </doc> - </rule> - </field> - - <field name="requeue" type="bit" label="requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the server will - attempt to requeue the message. - </doc> - - <rule name="requeue-strategy"> - <doc> - The server MUST NOT deliver the message to the same client within the context of the - current session. The recommended strategy is to attempt to deliver the message to an - alternative consumer, and if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold the message on the queue - and redeliver it to the same client at a later stage. - </doc> - </rule> - </field> - </command> - - </class> - - <!-- == Class: stream ======================================================================== --> - - <class name="stream" code="0xa" label="work with streaming content"> - <doc> - The stream class provides commands that support multimedia streaming. The stream class uses - the following semantics: one message is one packet of data; delivery is unacknowledged and - unreliable; the consumer can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favor of high priority messages. - </doc> - - <doc type="grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - </doc> - - <rule name="overflow-discard"> - <doc> - The server SHOULD discard stream messages on a priority basis if the queue size exceeds some - configured limit. - </doc> - </rule> - - <rule name="priority-levels"> - <doc> - The server MUST implement at least 2 priority levels for stream messages, where priorities - 0-4 and 5-9 are treated as two distinct levels. The server MAY implement up to 10 priority - levels. - </doc> - </rule> - - <rule name="acknowledgement-support"> - <doc> - The server MUST implement automatic acknowledgements on stream content. That is, as soon as - a message is delivered to a client via a Deliver command, the server must remove it from the - queue. - </doc> - </rule> - - <role name="server" implement="MAY" /> - <role name="client" implement="MAY" /> - - <!-- These are the properties for a Stream content --> - <struct name="stream-properties" size="4" code="0x1" pack="2"> - <field name="content-type" type="str8" label="MIME content type" /> - <field name="content-encoding" type="str8" label="MIME content encoding" /> - <field name="headers" type="map" label="message header field table" /> - <field name="priority" type="uint8" label="message priority, 0 to 9" /> - <field name="timestamp" type="datetime" label="message timestamp" /> - </struct> - - <domain name="return-code" type="uint16" label="return code from server"> - <doc> - The return code. The AMQP return codes are defined by this enum. - </doc> - <enum> - <choice name="content-too-large" value="311"> - <doc> - The client attempted to transfer content larger than the server could accept. - </doc> - </choice> - - <choice name="no-route" value="312"> - <doc> - The exchange cannot route a message, most likely due to an invalid routing key. Only - when the mandatory flag is set. - </doc> - </choice> - - <choice name="no-consumers" value="313"> - <doc> - The exchange cannot deliver to a consumer when the immediate flag is set. As a result of - pending data on the queue or the absence of any consumers of the queue. - </doc> - </choice> - </enum> - </domain> - - <!-- - Command: stream.qos - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos" code="0x1" label="specify quality of service"> - <doc> - This command requests a specific quality of service. The QoS can be specified for the - current session or for all sessions on the connection. The particular properties and - semantics of a qos command always depend on the content class semantics. Though the qos - command could in principle apply to both peers, it is currently meaningful only for the - server. - </doc> - - <implement role="server" handle="MUST" /> - - <response name="qos-ok" /> - - <field name="prefetch-size" type="uint32" label="pre-fetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client finishes - processing a message, the following message is already held locally, rather than needing - to be sent within the session. Pre-fetching gives a performance improvement. This field - specifies the pre-fetch window size in octets. May be set to zero, meaning "no specific - limit". Note that other pre-fetch limits may still apply. - </doc> - </field> - - <field name="prefetch-count" type="uint16" label="pre-fetch window in messages"> - <doc> - Specifies a pre-fetch window in terms of whole messages. This field may be used in - combination with the prefetch-size field; a message will only be sent in advance if both - pre-fetch windows (and those at the session and connection level) allow it. - </doc> - </field> - - <field name="consume-rate" type="uint32" label="transfer rate in octets/second"> - <doc> - Specifies a desired transfer rate in octets per second. This is usually determined by the - application that uses the streaming data. A value of zero means "no limit", i.e. as - rapidly as possible. - </doc> - - <rule name="ignore-prefetch"> - <doc> - The server MAY ignore the pre-fetch values and consume rates, depending on the type of - stream and the ability of the server to queue and/or reply it. - </doc> - </rule> - - <rule name="drop-by-priority"> - <doc> - The server MAY drop low-priority messages in favor of high-priority messages. - </doc> - </rule> - </field> - - <field name="global" type="bit" label="apply to entire connection"> - <doc> - By default the QoS settings apply to the current session only. If this field is set, they - are applied to the entire connection. - </doc> - </field> - </command> - - <!-- - Command: stream.qos-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="qos-ok" code="0x2" label="confirm the requested qos"> - <doc> - This command tells the client that the requested QoS levels could be handled by the server. - The requested QoS applies to all active consumers until a new QoS is defined. - </doc> - - <implement role="client" handle="MUST" /> - </command> - - <!-- - Command: stream.consume - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume" code="0x3" label="start a queue consumer"> - <doc> - This command asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the session they were created on, - or until the client cancels them. - </doc> - - <rule name="min-consumers"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was declared - as private, and ideally, impose no limit except as defined by available resources. - </doc> - </rule> - - <rule name="priority-based-delivery"> - <doc> - Streaming applications SHOULD use different sessions to select different streaming - resolutions. AMQP makes no provision for filtering and/or transforming streams except on - the basis of priority-based selective delivery of individual messages. - </doc> - </rule> - - <implement role="server" handle="MUST" /> - - <response name="consume-ok" /> - - <field name="queue" type="queue.name"> - <doc> - Specifies the name of the queue to consume from. - </doc> - - <exception name="queue-exists-if-empty" error-code="not-allowed"> - <doc> - If the queue name in this command is empty, the server MUST raise an exception. - </doc> - </exception> - </field> - - <field name="consumer-tag" type="str8"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a connection, so - two clients can use the same consumer tags. - </doc> - - <exception name="not-existing-consumer" error-code="not-allowed"> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to create two - consumers with the same non-empty tag the server MUST raise an exception. - </doc> - </exception> - - <exception name="not-empty-consumer-tag" error-code="not-allowed"> - <doc> - The client MUST NOT specify a tag that is empty or blank. - </doc> - <doc type="scenario"> - Attempt to create a consumers with an empty tag. - </doc> - </exception> - </field> - - <field name="no-local" type="bit"> - <doc>If the no-local field is set the server will not send messages to the connection that - published them.</doc> - </field> - - <field name="exclusive" type="bit" label="request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the queue. - </doc> - - <exception name="in-use" error-code="resource-locked"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - because there are - other consumers active - it MUST raise an exception with return code 405 - (resource locked). - </doc> - </exception> - </field> - - <field name="nowait" type="bit" label="do not send a reply command"> - <doc> - If set, the server will not respond to the command. The client should not wait for a reply - command. If the server could not complete the command it will raise an exception. - </doc> - </field> - - <field name="arguments" type="map" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics of these arguments depends on - the providers implementation. - </doc> - </field> - </command> - - <!-- - Command: stream.consume-ok - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="consume-ok" code="0x4" label="confirm a new consumer"> - <doc> - This command provides the client with a consumer tag which it may use in commands that work - with the consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </command> - - <!-- - Command: stream.cancel - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="cancel" code="0x5" label="end a queue consumer"> - <doc> - This command cancels a consumer. Since message delivery is asynchronous the client may - continue to receive messages for a short while after cancelling a consumer. It may process - or discard these as appropriate. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - </command> - - <!-- - Command: stream.publish - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="publish" code="0x6" label="publish a message"> - <doc> - This command publishes a message to a specific exchange. The message will be routed to - queues as defined by the exchange configuration and distributed to any active consumers as - appropriate. - </doc> - - <implement role="server" handle="MUST" /> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be empty, meaning - the default exchange. If the exchange name is specified, and that exchange does not exist, - the server will raise an exception. - </doc> - - <rule name="default"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <exception name="refusal" error-code="not-implemented"> - <doc> - The exchange MAY refuse stream content in which case it MUST respond with an exception. - </doc> - </exception> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing messages - depending on the exchange configuration. - </doc> - </field> - - <field name="mandatory" type="bit" label="indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue. If - this flag is set, the server will return an unroutable message with a Return command. If - this flag is zero, the server silently drops the message. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - </rule> - </field> - - <field name="immediate" type="bit" label="request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a queue - consumer immediately. If this flag is set, the server will return an undeliverable message - with a Return command. If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - - <rule name="implementation"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: stream.return - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="return" code="0x7" label="return a failed message"> - <doc> - This command returns an undeliverable message that was published with the "immediate" flag - set, or an unroutable message published with the "mandatory" flag set. The reply code and - text provide information about the reason that the message was undeliverable. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="reply-code" type="return-code" /> - - <field name="reply-text" type="str8" label="The localized reply text."> - <doc> - The localized reply text. This text can be logged as an aid to resolving issues. - </doc> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="routing-key" type="str8" label="Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - <!-- - Command: stream.deliver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <command name="deliver" code="0x8" label="notify the client of a consumer message"> - <doc> - This command delivers a message to the client, via a consumer. In the asynchronous message - delivery model, the client starts a consumer using the Consume command, then the server - responds with Deliver commands as and when messages arrive for that consumer. - </doc> - - <implement role="client" handle="MUST" /> - - <field name="consumer-tag" type="str8" /> - - <field name="delivery-tag" type="uint64"> - <doc> - The server-assigned and session-specific delivery tag - </doc> - <rule name="session-local"> - <doc> - The delivery tag is valid only within the session from which the message was received. - i.e. A client MUST NOT receive a message on one session and then acknowledge it on - another. - </doc> - </rule> - </field> - - <field name="exchange" type="exchange.name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name="queue" type="queue.name" required="true"> - <doc> - Specifies the name of the queue that the message came from. Note that a single session can - start many consumers on different queues. - </doc> - </field> - - <segments> - <header required="true"> - <entry type="stream-properties"/> - </header> - <body/> - </segments> - </command> - - </class> - -</amqp> diff --git a/qpid/specs/amqp.0-8.xml b/qpid/specs/amqp.0-8.xml deleted file mode 100644 index 0463f45fa9..0000000000 --- a/qpid/specs/amqp.0-8.xml +++ /dev/null @@ -1,3998 +0,0 @@ -<?xml version="1.0"?> - -<!-- - Copyright Notice - ================ - (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., - iMatix Corporation, IONA\ufffd Technologies, Red Hat, Inc., - TWIST Process Innovations, and 29West Inc. 2006. All rights reserved. - - License - ======= - JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix - Corporation, IONA Technologies, Red Hat, Inc., TWIST Process Innovations, and - 29West Inc. (collectively, the "Authors") each hereby grants to you a worldwide, - perpetual, royalty-free, nontransferable, nonexclusive license to - (i) copy, display, distribute and implement the Advanced Messaging Queue Protocol - ("AMQP") Specification and (ii) the Licensed Claims that are held by - the Authors, all for the purpose of implementing the Advanced Messaging - Queue Protocol Specification. Your license and any rights under this - Agreement will terminate immediately without notice from - any Author if you bring any claim, suit, demand, or action related to - the Advanced Messaging Queue Protocol Specification against any Author. - Upon termination, you shall destroy all copies of the Advanced Messaging - Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or - patent application, throughout the world, excluding design patents and - design registrations, owned or controlled, or that can be sublicensed - without fee and in compliance with the requirements of this - Agreement, by an Author or its affiliates now or at any - future time and which would necessarily be infringed by implementation - of the Advanced Messaging Queue Protocol Specification. A claim is - necessarily infringed hereunder only when it is not possible to avoid - infringing it because there is no plausible non-infringing alternative - for implementing the required portions of the Advanced Messaging Queue - Protocol Specification. Notwithstanding the foregoing, Licensed Claims - shall not include any claims other than as set forth above even if - contained in the same patent as Licensed Claims; or that read solely - on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging - Queue Protocol Specification, or that, if licensed, would require a - payment of royalties by the licensor to unaffiliated third parties. - Moreover, Licensed Claims shall not include (i) any enabling technologies - that may be necessary to make or use any Licensed Product but are not - themselves expressly set forth in the Advanced Messaging Queue Protocol - Specification (e.g., semiconductor manufacturing technology, compiler - technology, object oriented technology, networking technology, operating - system technology, and the like); or (ii) the implementation of other - published standards developed elsewhere and merely referred to in the - body of the Advanced Messaging Queue Protocol Specification, or - (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced - Messaging Queue Protocol Specification. For purposes of this definition, - the Advanced Messaging Queue Protocol Specification shall be deemed to - include both architectural and interconnection requirements essential - for interoperability and may also include supporting source code artifacts - where such architectural, interconnection requirements and source code - artifacts are expressly identified as being required or documentation to - achieve compliance with the Advanced Messaging Queue Protocol Specification. - - As used hereunder, "Licensed Products" means only those specific portions - of products (hardware, software or combinations thereof) that implement - and are compliant with all relevant portions of the Advanced Messaging - Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any - use you may make of the Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," - AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE - CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE - SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY - PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, - INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY - USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED MESSAGING QUEUE - PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, - including advertising or publicity pertaining to the Advanced Messaging - Queue Protocol Specification or its contents without specific, written - prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you - shall destroy all copies of the Advanced Messaging Queue Protocol - Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the - Octagon Symbol are trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA - Technologies PLC and/or its subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered - trademarks of Red Hat, Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of - Sun Microsystems, Inc. in the United States, other countries, or both. - - Other company, product, or service names may be trademarks or service - marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp - ---> - -<!-- -======================================================== -EDITORS: (PH) Pieter Hintjens <ph@imatix.com> - (KvdR) Kim van der Riet <kim.vdriet@redhat.com> - -NOTE: These editors have been assigned by the AMQP working group. Please do not -edit/commit this file without consulting with one of the above editors. -======================================================== - -Revision history: - 2006-06-07 (PH) - version number changed to 0.8 to conform to public - release documentation. - - 2006-05-15 (PH) - fixed comments on queue name in basic.get to clarify - use of current queue in this method. - - 2006-05-15 (PH) - fixed comments on routing key in queue.bind to clarify - how routing key is filled when empty (to allow asynch queue.declare). - - 2006-05-11 (PH) - reset version to 0.70 so that putatitive standards - group can release 2-3 major new versions before hitting 1.0 (again). - - 2006-05-11 (PH) - TODO in documentation: cycle field in frame header - has been removed. - - 2006-05-11 (PH) - added nowait option to exchange.declare, delete, - queue.declare, delete, bind, purge, basic.consume, cancel, - file.consume, cancel, stream.consume and cancel methods. - - 2006-05-11 (PH) - removed notnull rule and added explanations on queue - name in queue.bind, purge, delete, basic.consume, cancel, file.consume, - cancel, stream.consume and cancel methods. - - 2006-05-11 (PH) - added basic.qos, file.qos, and stream.qos methods that - regroup all prefetch options from the consume methods. Also removed the - prefetch option from channel.open. - - 2006-05-11 (PH) - renumbered method indexes to show request-response - nature of methods; requests are 10, 20, 30 while responses are 11, 21, - etc. - - 2006-05-11 (PH) - removed OpenAMQ extension methods from this definition - since these are maintained seperately. - - 2006-05-26 (RG) - added Basic.Recover method to allow replay of - unacknowledged messages on a channel. - - 2006-07-03 (PH) - cosmetic clean-up of Basic.Recover comments. ---> - -<amqp major="8" minor="0" port="5672" comment="AMQ protocol 0.80"> - AMQ Protocol 0.80 - -<!-- -====================================================== -== CONSTANTS -====================================================== ---> - <constant name="frame method" value="1"/> - <constant name="frame header" value="2"/> - <constant name="frame body" value="3"/> - <constant name="frame oob method" value="4"/> - <constant name="frame oob header" value="5"/> - <constant name="frame oob body" value="6"/> - <constant name="frame trace" value="7"/> - <constant name="frame heartbeat" value="8"/> - <constant name="frame min size" value="4096"/> - <constant name="frame end" value="206"/> - <constant name="reply success" value="200"> - Indicates that the method completed successfully. This reply code is - reserved for future use - the current protocol design does not use - positive confirmation and reply codes are sent only in case of an - error. -</constant> - <constant name="not delivered" value="310" class="soft error"> - The client asked for a specific message that is no longer available. - The message was delivered to another client, or was purged from the - queue for some other reason. -</constant> - <constant name="content too large" value="311" class="soft error"> - The client attempted to transfer content larger than the server - could accept at the present time. The client may retry at a later - time. -</constant> - <constant name="connection forced" value="320" class="hard error"> - An operator intervened to close the connection for some reason. - The client may retry at some later date. -</constant> - <constant name="invalid path" value="402" class="hard error"> - The client tried to work with an unknown virtual host or cluster. -</constant> - <constant name="access refused" value="403" class="soft error"> - The client attempted to work with a server entity to which it has - no due to security settings. -</constant> - <constant name="not found" value="404" class="soft error"> - The client attempted to work with a server entity that does not exist. -</constant> - <constant name="resource locked" value="405" class="soft error"> - The client attempted to work with a server entity to which it has - no access because another client is working with it. -</constant> - <constant name="frame error" value="501" class="hard error"> - The client sent a malformed frame that the server could not decode. - This strongly implies a programming error in the client. -</constant> - <constant name="syntax error" value="502" class="hard error"> - The client sent a frame that contained illegal values for one or more - fields. This strongly implies a programming error in the client. -</constant> - <constant name="command invalid" value="503" class="hard error"> - The client sent an invalid sequence of frames, attempting to perform - an operation that was considered invalid by the server. This usually - implies a programming error in the client. -</constant> - <constant name="channel error" value="504" class="hard error"> - The client attempted to work with a channel that had not been - correctly opened. This most likely indicates a fault in the client - layer. -</constant> - <constant name="resource error" value="506" class="hard error"> - The server could not complete the method because it lacked sufficient - resources. This may be due to the client creating too many of some - type of entity. -</constant> - <constant name="not allowed" value="530" class="hard error"> - The client tried to work with some entity in a manner that is - prohibited by the server, due to security settings or by some other - criteria. -</constant> - <constant name="not implemented" value="540" class="hard error"> - The client tried to use functionality that is not implemented in the - server. -</constant> - <constant name="internal error" value="541" class="hard error"> - The server could not complete the method because of an internal error. - The server may require intervention by an operator in order to resume - normal operations. -</constant> - <!-- -====================================================== -== DOMAIN TYPES -====================================================== ---> - <domain name="access ticket" type="short"> - access ticket granted by server - <doc> - An access ticket granted by the server for a certain set of access - rights within a specific realm. Access tickets are valid within the - channel where they were created, and expire when the channel closes. - </doc> - <assert check="ne" value="0"/> - </domain> - <domain name="class id" type="short"/> - <domain name="consumer tag" type="shortstr"> - consumer tag - <doc> - Identifier for the consumer, valid within the current connection. - </doc> - <rule implement="MUST"> - The consumer tag is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in - one channel and then use it in another. - </rule> - </domain> - <domain name="delivery tag" type="longlong"> - server-assigned delivery tag - <doc> - The server-assigned and channel-specific delivery tag - </doc> - <rule implement="MUST"> - The delivery tag is valid only within the channel from which the - message was received. I.e. a client MUST NOT receive a message on - one channel and then acknowledge it on another. - </rule> - <rule implement="MUST"> - The server MUST NOT use a zero value for delivery tags. Zero is - reserved for client use, meaning "all messages so far received". - </rule> - </domain> - <domain name="exchange name" type="shortstr"> - exchange name - <doc> - The exchange name is a client-selected string that identifies - the exchange for publish methods. Exchange names may consist - of any mixture of digits, letters, and underscores. Exchange - names are scoped by the virtual host. - </doc> - <assert check="length" value="127"/> - </domain> - <domain name="known hosts" type="shortstr"> -list of known hosts -<doc> -Specifies the list of equivalent or alternative hosts that the server -knows about, which will normally include the current server itself. -Clients can cache this information and use it when reconnecting to a -server after a failure. -</doc> - <rule implement="MAY"> -The server MAY leave this field empty if it knows of no other -hosts than itself. -</rule> - </domain> - <domain name="method id" type="short"/> - <domain name="no ack" type="bit"> - no acknowledgement needed - <doc> - If this field is set the server does not expect acknowledgments - for messages. That is, when a message is delivered to the client - the server automatically and silently acknowledges it on behalf - of the client. This functionality increases performance but at - the cost of reliability. Messages can get lost if a client dies - before it can deliver them to the application. - </doc> - </domain> - <domain name="no local" type="bit"> - do not deliver own messages - <doc> - If the no-local field is set the server will not send messages to - the client that published them. - </doc> - </domain> - <domain name="path" type="shortstr"> - <doc> - Must start with a slash "/" and continue with path names - separated by slashes. A path name consists of any combination - of at least one of [A-Za-z0-9] plus zero or more of [.-_+!=:]. -</doc> - <assert check="notnull"/> - <assert check="syntax" rule="path"/> - <assert check="length" value="127"/> - </domain> - <domain name="peer properties" type="table"> - <doc> -This string provides a set of peer properties, used for -identification, debugging, and general information. -</doc> - <rule implement="SHOULD"> -The properties SHOULD contain these fields: -"product", giving the name of the peer product, "version", giving -the name of the peer version, "platform", giving the name of the -operating system, "copyright", if appropriate, and "information", -giving other general information. -</rule> - </domain> - <domain name="queue name" type="shortstr"> - queue name - <doc> - The queue name identifies the queue within the vhost. Queue - names may consist of any mixture of digits, letters, and - underscores. - </doc> - <assert check="length" value="127"/> - </domain> - <domain name="redelivered" type="bit"> - message is being redelivered - <doc> - This indicates that the message has been previously delivered to - this or another client. - </doc> - <rule implement="SHOULD"> - The server SHOULD try to signal redelivered messages when it can. - When redelivering a message that was not successfully acknowledged, - the server SHOULD deliver it to the original client if possible. - </rule> - <rule implement="MUST"> - The client MUST NOT rely on the redelivered field but MUST take it - as a hint that the message may already have been processed. A - fully robust client must be able to track duplicate received messages - on non-transacted, and locally-transacted channels. - </rule> - </domain> - <domain name="reply code" type="short"> -reply code from server -<doc> - The reply code. The AMQ reply codes are defined in AMQ RFC 011. -</doc> - <assert check="notnull"/> - </domain> - <domain name="reply text" type="shortstr"> -localised reply text -<doc> - The localised reply text. This text can be logged as an aid to - resolving issues. -</doc> - <assert check="notnull"/> - </domain> - <class name="connection" handler="connection" index="10"> - <!-- -====================================================== -== CONNECTION -====================================================== ---> - work with socket connections -<doc> - The connection class provides methods for a client to establish a - network connection to a server, and for both peers to operate the - connection thereafter. -</doc> - <doc name="grammar"> - connection = open-connection *use-connection close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="start" synchronous="1" index="10"> - start connection negotiation - <doc> - This method starts the connection negotiation process by telling - the client the protocol version that the server proposes, along - with a list of security mechanisms which the client can use for - authentication. - </doc> - <rule implement="MUST"> - If the client cannot handle the protocol version suggested by the - server it MUST close the socket connection. - </rule> - <rule implement="MUST"> - The server MUST provide a protocol version that is lower than or - equal to that requested by the client in the protocol header. If - the server cannot support the specified protocol it MUST NOT send - this method, but MUST close the socket connection. - </rule> - <chassis name="client" implement="MUST"/> - <response name="start-ok"/> - <field name="version major" type="octet"> - protocol major version - <doc> - The protocol major version that the server agrees to use, which - cannot be higher than the client's major version. - </doc> - </field> - <field name="version minor" type="octet"> - protocol major version - <doc> - The protocol minor version that the server agrees to use, which - cannot be higher than the client's minor version. - </doc> - </field> - <field name="server properties" domain="peer properties"> - server properties - </field> - <field name="mechanisms" type="longstr"> - available security mechanisms - <doc> - A list of the security mechanisms that the server supports, delimited - by spaces. Currently ASL supports these mechanisms: PLAIN. - </doc> - <see name="security mechanisms"/> - <assert check="notnull"/> - </field> - <field name="locales" type="longstr"> - available message locales - <doc> - A list of the message locales that the server supports, delimited - by spaces. The locale defines the language in which the server - will send reply texts. - </doc> - <rule implement="MUST"> - All servers MUST support at least the en_US locale. - </rule> - <assert check="notnull"/> - </field> - </method> - <method name="start-ok" synchronous="1" index="11"> - select security mechanism and locale - <doc> - This method selects a SASL security mechanism. ASL uses SASL - (RFC2222) to negotiate authentication and encryption. - </doc> - <chassis name="server" implement="MUST"/> - <field name="client properties" domain="peer properties"> - client properties - </field> - <field name="mechanism" type="shortstr"> - selected security mechanism - <doc> - A single security mechanisms selected by the client, which must be - one of those specified by the server. - </doc> - <rule implement="SHOULD"> - The client SHOULD authenticate using the highest-level security - profile it can handle from the list provided by the server. - </rule> - <rule implement="MUST"> - The mechanism field MUST contain one of the security mechanisms - proposed by the server in the Start method. If it doesn't, the - server MUST close the socket. - </rule> - <assert check="notnull"/> - </field> - <field name="response" type="longstr"> - security response data - <doc> - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. For the - PLAIN security mechanism this is defined as a field table holding - two fields, LOGIN and PASSWORD. - </doc> - <assert check="notnull"/> - </field> - <field name="locale" type="shortstr"> - selected message locale - <doc> - A single message local selected by the client, which must be one - of those specified by the server. - </doc> - <assert check="notnull"/> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="secure" synchronous="1" index="20"> - security mechanism challenge - <doc> - The SASL protocol works by exchanging challenges and responses until - both peers have received sufficient information to authenticate each - other. This method challenges the client to provide more information. - </doc> - <chassis name="client" implement="MUST"/> - <response name="secure-ok"/> - <field name="challenge" type="longstr"> - security challenge data - <doc> - Challenge information, a block of opaque binary data passed to - the security mechanism. - </doc> - <see name="security mechanisms"/> - </field> - </method> - <method name="secure-ok" synchronous="1" index="21"> - security mechanism response - <doc> - This method attempts to authenticate, passing a block of SASL data - for the security mechanism at the server side. - </doc> - <chassis name="server" implement="MUST"/> - <field name="response" type="longstr"> - security response data - <doc> - A block of opaque data passed to the security mechanism. The contents - of this data are defined by the SASL security mechanism. - </doc> - <assert check="notnull"/> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="tune" synchronous="1" index="30"> - propose connection tuning parameters - <doc> - This method proposes a set of connection configuration values - to the client. The client can accept and/or adjust these. - </doc> - <chassis name="client" implement="MUST"/> - <response name="tune-ok"/> - <field name="channel max" type="short"> - proposed maximum channels - <doc> - The maximum total number of channels that the server allows - per connection. Zero means that the server does not impose a - fixed limit, but the number of allowed channels may be limited - by available server resources. - </doc> - </field> - <field name="frame max" type="long"> - proposed maximum frame size - <doc> - The largest frame size that the server proposes for the - connection. The client can negotiate a lower value. Zero means - that the server does not impose any specific limit but may reject - very large frames if it cannot allocate resources for them. - </doc> - <rule implement="MUST"> - Until the frame-max has been negotiated, both peers MUST accept - frames of up to 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - </rule> - </field> - <field name="heartbeat" type="short"> - desired heartbeat delay - <doc> - The delay, in seconds, of the connection heartbeat that the server - wants. Zero means the server does not want a heartbeat. - </doc> - </field> - </method> - <method name="tune-ok" synchronous="1" index="31"> - negotiate connection tuning parameters - <doc> - This method sends the client's connection tuning parameters to the - server. Certain fields are negotiated, others provide capability - information. - </doc> - <chassis name="server" implement="MUST"/> - <field name="channel max" type="short"> - negotiated maximum channels - <doc> - The maximum total number of channels that the client will use - per connection. May not be higher than the value specified by - the server. - </doc> - <rule implement="MAY"> - The server MAY ignore the channel-max value or MAY use it for - tuning its resource allocation. - </rule> - <assert check="notnull"/> - <assert check="le" method="tune" field="channel max"/> - </field> - <field name="frame max" type="long"> - negotiated maximum frame size - <doc> - The largest frame size that the client and server will use for - the connection. Zero means that the client does not impose any - specific limit but may reject very large frames if it cannot - allocate resources for them. Note that the frame-max limit - applies principally to content frames, where large contents - can be broken into frames of arbitrary size. - </doc> - <rule implement="MUST"> - Until the frame-max has been negotiated, both peers must accept - frames of up to 4096 octets large. The minimum non-zero value for - the frame-max field is 4096. - </rule> - </field> - <field name="heartbeat" type="short"> - desired heartbeat delay - <doc> - The delay, in seconds, of the connection heartbeat that the client - wants. Zero means the client does not want a heartbeat. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="open" synchronous="1" index="40"> - open connection to virtual host - <doc> - This method opens a connection to a virtual host, which is a - collection of resources, and acts to separate multiple application - domains within a server. - </doc> - <rule implement="MUST"> - The client MUST open the context before doing any work on the - connection. - </rule> - <chassis name="server" implement="MUST"/> - <response name="open-ok"/> - <response name="redirect"/> - <field name="virtual host" domain="path"> - virtual host name - <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> - <doc> - The name of the virtual host to work with. - </doc> - <rule implement="MUST"> - If the server supports multiple virtual hosts, it MUST enforce a - full separation of exchanges, queues, and all associated entities - per virtual host. An application, connected to a specific virtual - host, MUST NOT be able to access resources of another virtual host. - </rule> - <rule implement="SHOULD"> - The server SHOULD verify that the client has permission to access - the specified virtual host. - </rule> - <rule implement="MAY"> - The server MAY configure arbitrary limits per virtual host, such - as the number of each type of entity that may be used, per - connection and/or in total. - </rule> - </field> - <field name="capabilities" type="shortstr"> - required capabilities - <doc> - The client may specify a number of capability names, delimited by - spaces. The server can use this string to how to process the - client's connection request. - </doc> - </field> - <field name="insist" type="bit"> - insist on connecting to server - <doc> - In a configuration with multiple load-sharing servers, the server - may respond to a Connection.Open method with a Connection.Redirect. - The insist option tells the server that the client is insisting on - a connection to the specified server. - </doc> - <rule implement="SHOULD"> - When the client uses the insist option, the server SHOULD accept - the client connection unless it is technically unable to do so. - </rule> - </field> - </method> - <method name="open-ok" synchronous="1" index="41"> - signal that the connection is ready - <doc> - This method signals to the client that the connection is ready for - use. - </doc> - <chassis name="client" implement="MUST"/> - <field name="known hosts" domain="known hosts"/> - </method> - <method name="redirect" synchronous="1" index="50"> - asks the client to use a different server - <doc> - This method redirects the client to another server, based on the - requested virtual host and/or capabilities. - </doc> - <rule implement="SHOULD"> - When getting the Connection.Redirect method, the client SHOULD - reconnect to the host specified, and if that host is not present, - to any of the hosts specified in the known-hosts list. - </rule> - <chassis name="client" implement="MAY"/> - <field name="host" type="shortstr"> - server to connect to - <doc> - Specifies the server to connect to. This is an IP address or a - DNS name, optionally followed by a colon and a port number. If - no port number is specified, the client should use the default - port number for the protocol. - </doc> - <assert check="notnull"/> - </field> - <field name="known hosts" domain="known hosts"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="close" synchronous="1" index="60"> - request a connection close - <doc> - This method indicates that the sender wants to close the connection. - This may be due to internal conditions (e.g. a forced shut-down) or - due to an error handling a specific method, i.e. an exception. When - a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - </doc> - <rule implement="MUST"> - After sending this method any received method except the Close-OK - method MUST be discarded. - </rule> - <rule implement="MAY"> - The peer sending this method MAY use a counter or timeout to - detect failure of the other peer to respond correctly with - the Close-OK method. - </rule> - <rule implement="MUST"> - When a server receives the Close method from a client it MUST - delete all server-side resources associated with the client's - context. A client CANNOT reconnect to a context after sending - or receiving a Close method. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="close-ok"/> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <field name="class id" domain="class id"> - failing method class - <doc> - When the close is provoked by a method exception, this is the - class of the method. - </doc> - </field> - <field name="method id" domain="method id"> - failing method ID - <doc> - When the close is provoked by a method exception, this is the - ID of the method. - </doc> - </field> - </method> - <method name="close-ok" synchronous="1" index="61"> - confirm a connection close - <doc> - This method confirms a Connection.Close method and tells the - recipient that it is safe to release resources for the connection - and close the socket. - </doc> - <rule implement="SHOULD"> - A peer that detects a socket closure without having received a - Close-Ok handshake method SHOULD log the error. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - </method> - </class> - <class name="channel" handler="channel" index="20"> - <!-- -====================================================== -== CHANNEL -====================================================== ---> - work with channels -<doc> - The channel class provides methods for a client to establish a virtual - connection - a channel - to a server and for both peers to operate the - virtual connection thereafter. -</doc> - <doc name="grammar"> - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:ALERT - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="open" synchronous="1" index="10"> - open a channel for use - <doc> - This method opens a virtual connection (a channel). - </doc> - <rule implement="MUST"> - This method MUST NOT be called when the channel is already open. - </rule> - <chassis name="server" implement="MUST"/> - <response name="open-ok"/> - <field name="out of band" type="shortstr"> - out-of-band settings - <doc> - Configures out-of-band transfers on this channel. The syntax and - meaning of this field will be formally defined at a later date. - </doc> - <assert check="null"/> - </field> - </method> - <method name="open-ok" synchronous="1" index="11"> - signal that the channel is ready - <doc> - This method signals to the client that the channel is ready for use. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="flow" synchronous="1" index="20"> - enable/disable flow from peer - <doc> - This method asks the peer to pause or restart the flow of content - data. This is a simple flow-control mechanism that a peer can use - to avoid oveflowing its queues or otherwise finding itself receiving - more messages than it can process. Note that this method is not - intended for window control. The peer that receives a request to - stop sending content should finish sending the current content, if - any, and then wait until it receives a Flow restart method. - </doc> - <rule implement="MAY"> - When a new channel is opened, it is active. Some applications - assume that channels are inactive until started. To emulate this - behaviour a client MAY open the channel, then pause it. - </rule> - <rule implement="SHOULD"> - When sending content data in multiple frames, a peer SHOULD monitor - the channel for incoming methods and respond to a Channel.Flow as - rapidly as possible. - </rule> - <rule implement="MAY"> - A peer MAY use the Channel.Flow method to throttle incoming content - data for internal reasons, for example, when exchangeing data over a - slower connection. - </rule> - <rule implement="MAY"> - The peer that requests a Channel.Flow method MAY disconnect and/or - ban a peer that does not respect the request. - </rule> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <response name="flow-ok"/> - <field name="active" type="bit"> - start/stop content frames - <doc> - If 1, the peer starts sending content frames. If 0, the peer - stops sending content frames. - </doc> - </field> - </method> - <method name="flow-ok" index="21"> - confirm a flow method - <doc> - Confirms to the peer that a flow command was received and processed. - </doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <field name="active" type="bit"> - current flow setting - <doc> - Confirms the setting of the processed flow method: 1 means the - peer will start sending or continue to send content frames; 0 - means it will not. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="alert" index="30"> - send a non-fatal warning message - <doc> - This method allows the server to send a non-fatal warning to the - client. This is used for methods that are normally asynchronous - and thus do not have confirmations, and for which the server may - detect errors that need to be reported. Fatal errors are handled - as channel or connection exceptions; non-fatal errors are sent - through this method. - </doc> - <chassis name="client" implement="MUST"/> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <field name="details" type="table"> - detailed information for warning - <doc> - A set of fields that provide more information about the - problem. The meaning of these fields are defined on a - per-reply-code basis (TO BE DEFINED). - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="close" synchronous="1" index="40"> - request a channel close - <doc> - This method indicates that the sender wants to close the channel. - This may be due to internal conditions (e.g. a forced shut-down) or - due to an error handling a specific method, i.e. an exception. When - a close is due to an exception, the sender provides the class and - method id of the method which caused the exception. - </doc> - <rule implement="MUST"> - After sending this method any received method except - Channel.Close-OK MUST be discarded. - </rule> - <rule implement="MAY"> - The peer sending this method MAY use a counter or timeout to detect - failure of the other peer to respond correctly with Channel.Close-OK.. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="close-ok"/> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <field name="class id" domain="class id"> - failing method class - <doc> - When the close is provoked by a method exception, this is the - class of the method. - </doc> - </field> - <field name="method id" domain="method id"> - failing method ID - <doc> - When the close is provoked by a method exception, this is the - ID of the method. - </doc> - </field> - </method> - <method name="close-ok" synchronous="1" index="41"> - confirm a channel close - <doc> - This method confirms a Channel.Close method and tells the recipient - that it is safe to release resources for the channel and close the - socket. - </doc> - <rule implement="SHOULD"> - A peer that detects a socket closure without having received a - Channel.Close-Ok handshake method SHOULD log the error. - </rule> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - </method> - </class> - <class name="access" handler="connection" index="30"> - <!-- -====================================================== -== ACCESS CONTROL -====================================================== ---> - work with access tickets -<doc> - The protocol control access to server resources using access tickets. - A client must explicitly request access tickets before doing work. - An access ticket grants a client the right to use a specific set of - resources - called a "realm" - in specific ways. -</doc> - <doc name="grammar"> - access = C:REQUEST S:REQUEST-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="request" synchronous="1" index="10"> - request an access ticket - <doc> - This method requests an access ticket for an access realm. - The server responds by granting the access ticket. If the - client does not have access rights to the requested realm - this causes a connection exception. Access tickets are a - per-channel resource. - </doc> - <rule implement="MUST"> - The realm name MUST start with either "/data" (for application - resources) or "/admin" (for server administration resources). - If the realm starts with any other path, the server MUST raise - a connection exception with reply code 403 (access refused). - </rule> - <rule implement="MUST"> - The server MUST implement the /data realm and MAY implement the - /admin realm. The mapping of resources to realms is not - defined in the protocol - this is a server-side configuration - issue. - </rule> - <chassis name="server" implement="MUST"/> - <response name="request-ok"/> - <field name="realm" domain="path"> - name of requested realm - <rule implement="MUST"> - If the specified realm is not known to the server, the server - must raise a channel exception with reply code 402 (invalid - path). - </rule> - </field> - <field name="exclusive" type="bit"> - request exclusive access - <doc> - Request exclusive access to the realm. If the server cannot grant - this - because there are other active tickets for the realm - it - raises a channel exception. - </doc> - </field> - <field name="passive" type="bit"> - request passive access - <doc> - Request message passive access to the specified access realm. - Passive access lets a client get information about resources in - the realm but not to make any changes to them. - </doc> - </field> - <field name="active" type="bit"> - request active access - <doc> - Request message active access to the specified access realm. - Acvtive access lets a client get create and delete resources in - the realm. - </doc> - </field> - <field name="write" type="bit"> - request write access - <doc> - Request write access to the specified access realm. Write access - lets a client publish messages to all exchanges in the realm. - </doc> - </field> - <field name="read" type="bit"> - request read access - <doc> - Request read access to the specified access realm. Read access - lets a client consume messages from queues in the realm. - </doc> - </field> - </method> - <method name="request-ok" synchronous="1" index="11"> - grant access to server resources - <doc> - This method provides the client with an access ticket. The access - ticket is valid within the current channel and for the lifespan of - the channel. - </doc> - <rule implement="MUST"> - The client MUST NOT use access tickets except within the same - channel as originally granted. - </rule> - <rule implement="MUST"> - The server MUST isolate access tickets per channel and treat an - attempt by a client to mix these as a connection exception. - </rule> - <chassis name="client" implement="MUST"/> - <field name="ticket" domain="access ticket"/> - </method> - </class> - <class name="exchange" handler="channel" index="40"> - <!-- -====================================================== -== EXCHANGES (or "routers", if you prefer) -== (Or matchers, plugins, extensions, agents,... Routing is just one of -== the many fun things an exchange can do.) -====================================================== ---> - work with exchanges -<doc> - Exchanges match and distribute messages across queues. Exchanges can be - configured in the server or created at runtime. -</doc> - <doc name="grammar"> - exchange = C:DECLARE S:DECLARE-OK - / C:DELETE S:DELETE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <rule implement="MUST"> - <test>amq_exchange_19</test> - The server MUST implement the direct and fanout exchange types, and - predeclare the corresponding exchanges named amq.direct and amq.fanout - in each virtual host. The server MUST also predeclare a direct - exchange to act as the default exchange for content Publish methods - and for default queue bindings. -</rule> - <rule implement="SHOULD"> - <test>amq_exchange_20</test> - The server SHOULD implement the topic exchange type, and predeclare - the corresponding exchange named amq.topic in each virtual host. -</rule> - <rule implement="MAY"> - <test>amq_exchange_21</test> - The server MAY implement the system exchange type, and predeclare the - corresponding exchanges named amq.system in each virtual host. If the - client attempts to bind a queue to the system exchange, the server - MUST raise a connection exception with reply code 507 (not allowed). -</rule> - <rule implement="MUST"> - <test>amq_exchange_22</test> - The default exchange MUST be defined as internal, and be inaccessible - to the client except by specifying an empty exchange name in a content - Publish method. That is, the server MUST NOT let clients make explicit - bindings to this exchange. -</rule> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="declare" synchronous="1" index="10"> - declare exchange, create if needed - <doc> - This method creates an exchange if it does not already exist, and if the - exchange exists, verifies that it is of the correct and expected class. - </doc> - <rule implement="SHOULD"> - <test>amq_exchange_23</test> - The server SHOULD support a minimum of 16 exchanges per virtual host - and ideally, impose no limit except as defined by available resources. - </rule> - <chassis name="server" implement="MUST"/> - <response name="declare-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - When a client defines a new exchange, this belongs to the access realm - of the ticket used. All further work done with that exchange must be - done with an access ticket for the same realm. - </doc> - <rule implement="MUST"> - The client MUST provide a valid access ticket giving "active" access - to the realm in which the exchange exists or will be created, or - "passive" access if the if-exists flag is set. - </rule> - </field> - <field name="exchange" domain="exchange name"> - <rule implement="MUST"> - <test>amq_exchange_15</test> - Exchange names starting with "amq." are reserved for predeclared - and standardised exchanges. If the client attempts to create an - exchange starting with "amq.", the server MUST raise a channel - exception with reply code 403 (access refused). - </rule> - <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> - </field> - <field name="type" type="shortstr"> - exchange type - <doc> - Each exchange belongs to one of a set of exchange types implemented - by the server. The exchange types define the functionality of the - exchange - i.e. how messages are routed through it. It is not valid - or meaningful to attempt to change the type of an existing exchange. - </doc> - <rule implement="MUST"> - <test>amq_exchange_16</test> - If the exchange already exists with a different type, the server - MUST raise a connection exception with a reply code 507 (not allowed). - </rule> - <rule implement="MUST"> - <test>amq_exchange_18</test> - If the server does not support the requested exchange type it MUST - raise a connection exception with a reply code 503 (command invalid). - </rule> - <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> - </field> - <field name="passive" type="bit"> - do not create exchange - <doc> - If set, the server will not create the exchange. The client can use - this to check whether an exchange exists without modifying the server - state. - </doc> - <rule implement="MUST"> - <test>amq_exchange_05</test> - If set, and the exchange does not already exist, the server MUST - raise a channel exception with reply code 404 (not found). - </rule> - </field> - <field name="durable" type="bit"> - request a durable exchange - <doc> - If set when creating a new exchange, the exchange will be marked as - durable. Durable exchanges remain active when a server restarts. - Non-durable exchanges (transient exchanges) are purged if/when a - server restarts. - </doc> - <rule implement="MUST"> - <test>amq_exchange_24</test> - The server MUST support both durable and transient exchanges. - </rule> - <rule implement="MUST"> - The server MUST ignore the durable field if the exchange already - exists. - </rule> - </field> - <field name="auto delete" type="bit"> - auto-delete when unused - <doc> - If set, the exchange is deleted when all queues have finished - using it. - </doc> - <rule implement="SHOULD"> - <test>amq_exchange_02</test> - The server SHOULD allow for a reasonable delay between the point - when it determines that an exchange is not being used (or no longer - used), and the point when it deletes the exchange. At the least it - must allow a client to create an exchange and then bind a queue to - it, with a small but non-zero delay between these two actions. - </rule> - <rule implement="MUST"> - <test>amq_exchange_25</test> - The server MUST ignore the auto-delete field if the exchange already - exists. - </rule> - </field> - <field name="internal" type="bit"> - create internal exchange - <doc> - If set, the exchange may not be used directly by publishers, but - only when bound to other exchanges. Internal exchanges are used to - construct wiring that is not visible to applications. - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table"> - arguments for declaration - <doc> - A set of arguments for the declaration. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - </doc> - </field> - </method> - <method name="declare-ok" synchronous="1" index="11"> - confirms an exchange declaration - <doc> - This method confirms a Declare method and confirms the name of the - exchange, essential for automatically-named exchanges. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="delete" synchronous="1" index="20"> - delete an exchange - <doc> - This method deletes an exchange. When an exchange is deleted all queue - bindings on the exchange are cancelled. - </doc> - <chassis name="server" implement="MUST"/> - <response name="delete-ok"/> - <field name="ticket" domain="access ticket"> - <rule implement="MUST"> - The client MUST provide a valid access ticket giving "active" - access rights to the exchange's access realm. - </rule> - </field> - <field name="exchange" domain="exchange name"> - <rule implement="MUST"> - <test>amq_exchange_11</test> - The exchange MUST exist. Attempting to delete a non-existing exchange - causes a channel exception. - </rule> - <assert check="notnull"/> - </field> - <field name="if unused" type="bit"> - delete only if unused - <doc> - If set, the server will only delete the exchange if it has no queue - bindings. If the exchange has queue bindings the server does not - delete it but raises a channel exception instead. - </doc> - <rule implement="SHOULD"> - <test>amq_exchange_12</test> - If set, the server SHOULD delete the exchange but only if it has - no queue bindings. - </rule> - <rule implement="SHOULD"> - <test>amq_exchange_13</test> - If set, the server SHOULD raise a channel exception if the exchange is in - use. - </rule> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - </method> - <method name="delete-ok" synchronous="1" index="21"> - confirm deletion of an exchange - <doc> - This method confirms the deletion of an exchange. - </doc> - <chassis name="client" implement="MUST"/> - </method> - - <method name="bound" synchronous="1" index="22"> - <chassis name="server" implement="SHOULD"/> - <field name="exchange" domain="exchange name"/> - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - <field name = "queue" domain = "queue name"/> - </method> - - <method name="bound-ok" synchronous="1" index="23"> - <field name="reply code" domain="reply code"/> - <field name="reply text" domain="reply text"/> - <chassis name="client" implement="SHOULD"/> - </method> - - </class> - - - <class name="queue" handler="channel" index="50"> - <!-- -====================================================== -== QUEUES -====================================================== ---> - work with queues - -<doc> - Queues store and forward messages. Queues can be configured in the server - or created at runtime. Queues must be attached to at least one exchange - in order to receive messages from publishers. -</doc> - <doc name="grammar"> - queue = C:DECLARE S:DECLARE-OK - / C:BIND S:BIND-OK - / C:PURGE S:PURGE-OK - / C:DELETE S:DELETE-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="MUST"/> - <rule implement="MUST"> - <test>amq_queue_33</test> - A server MUST allow any content class to be sent to any queue, in any - mix, and queue and delivery these content classes independently. Note - that all methods that fetch content off queues are specific to a given - content class. -</rule> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="declare" synchronous="1" index="10"> - declare queue, create if needed - <doc> - This method creates or checks a queue. When creating a new queue - the client can specify various properties that control the durability - of the queue and its contents, and the level of sharing for the queue. - </doc> - <rule implement="MUST"> - <test>amq_queue_34</test> - The server MUST create a default binding for a newly-created queue - to the default exchange, which is an exchange of type 'direct'. - </rule> - <rule implement="SHOULD"> - <test>amq_queue_35</test> - The server SHOULD support a minimum of 256 queues per virtual host - and ideally, impose no limit except as defined by available resources. - </rule> - <chassis name="server" implement="MUST"/> - <response name="declare-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - When a client defines a new queue, this belongs to the access realm - of the ticket used. All further work done with that queue must be - done with an access ticket for the same realm. - </doc> - <doc> - The client provides a valid access ticket giving "active" access - to the realm in which the queue exists or will be created, or - "passive" access if the if-exists flag is set. - </doc> - </field> - <field name="queue" domain="queue name"> - <rule implement="MAY"> - <test>amq_queue_10</test> - The queue name MAY be empty, in which case the server MUST create - a new queue with a unique generated name and return this to the - client in the Declare-Ok method. - </rule> - <rule implement="MUST"> - <test>amq_queue_32</test> - Queue names starting with "amq." are reserved for predeclared and - standardised server queues. If the queue name starts with "amq." - and the passive option is zero, the server MUST raise a connection - exception with reply code 403 (access refused). - </rule> - <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> - </field> - <field name="passive" type="bit"> - do not create queue - <doc> - If set, the server will not create the queue. The client can use - this to check whether a queue exists without modifying the server - state. - </doc> - <rule implement="MUST"> - <test>amq_queue_05</test> - If set, and the queue does not already exist, the server MUST - respond with a reply code 404 (not found) and raise a channel - exception. - </rule> - </field> - <field name="durable" type="bit"> - request a durable queue - <doc> - If set when creating a new queue, the queue will be marked as - durable. Durable queues remain active when a server restarts. - Non-durable queues (transient queues) are purged if/when a - server restarts. Note that durable queues do not necessarily - hold persistent messages, although it does not make sense to - send persistent messages to a transient queue. - </doc> - <rule implement="MUST"> - <test>amq_queue_03</test> - The server MUST recreate the durable queue after a restart. - </rule> - <rule implement="MUST"> - <test>amq_queue_36</test> - The server MUST support both durable and transient queues. - </rule> - <rule implement="MUST"> - <test>amq_queue_37</test> - The server MUST ignore the durable field if the queue already - exists. - </rule> - </field> - <field name="exclusive" type="bit"> - request an exclusive queue - <doc> - Exclusive queues may only be consumed from by the current connection. - Setting the 'exclusive' flag always implies 'auto-delete'. - </doc> - <rule implement="MUST"> - <test>amq_queue_38</test> - The server MUST support both exclusive (private) and non-exclusive - (shared) queues. - </rule> - <rule implement="MUST"> - <test>amq_queue_04</test> - The server MUST raise a channel exception if 'exclusive' is specified - and the queue already exists and is owned by a different connection. - </rule> - </field> - <field name="auto delete" type="bit"> - auto-delete queue when unused - <doc> - If set, the queue is deleted when all consumers have finished - using it. Last consumer can be cancelled either explicitly or because - its channel is closed. If there was no consumer ever on the queue, it - won't be deleted. - </doc> - <rule implement="SHOULD"> - <test>amq_queue_02</test> - The server SHOULD allow for a reasonable delay between the point - when it determines that a queue is not being used (or no longer - used), and the point when it deletes the queue. At the least it - must allow a client to create a queue and then create a consumer - to read from it, with a small but non-zero delay between these - two actions. The server should equally allow for clients that may - be disconnected prematurely, and wish to re-consume from the same - queue without losing messages. We would recommend a configurable - timeout, with a suitable default value being one minute. - </rule> - <rule implement="MUST"> - <test>amq_queue_31</test> - The server MUST ignore the auto-delete field if the queue already - exists. - </rule> - </field> - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table"> - arguments for declaration - <doc> - A set of arguments for the declaration. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - </doc> - </field> - </method> - <method name="declare-ok" synchronous="1" index="11"> - confirms a queue definition - <doc> - This method confirms a Declare method and confirms the name of the - queue, essential for automatically-named queues. - </doc> - <chassis name="client" implement="MUST"/> - <field name="queue" domain="queue name"> - <doc> - Reports the name of the queue. If the server generated a queue - name, this field contains that name. - </doc> - <assert check="notnull"/> - </field> - <field name="message count" type="long"> - number of messages in queue - <doc> - Reports the number of messages in the queue, which will be zero - for newly-created queues. - </doc> - </field> - <field name="consumer count" type="long"> - number of consumers - <doc> - Reports the number of active consumers for the queue. Note that - consumers can suspend activity (Channel.Flow) in which case they - do not appear in this count. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="bind" synchronous="1" index="20"> - bind queue to an exchange - <doc> - This method binds a queue to an exchange. Until a queue is - bound it will not receive any messages. In a classic messaging - model, store-and-forward queues are bound to a dest exchange - and subscription queues are bound to a dest_wild exchange. - </doc> - <rule implement="MUST"> - <test>amq_queue_25</test> - A server MUST allow ignore duplicate bindings - that is, two or - more bind methods for a specific queue, with identical arguments - - without treating these as an error. - </rule> - <rule implement="MUST"> - <test>amq_queue_39</test> - If a bind fails, the server MUST raise a connection exception. - </rule> - <rule implement="MUST"> - <test>amq_queue_12</test> - The server MUST NOT allow a durable queue to bind to a transient - exchange. If the client attempts this the server MUST raise a - channel exception. - </rule> - <rule implement="SHOULD"> - <test>amq_queue_13</test> - Bindings for durable queues are automatically durable and the - server SHOULD restore such bindings after a server restart. - </rule> - <rule implement="MUST"> - <test>amq_queue_17</test> - If the client attempts to an exchange that was declared as internal, - the server MUST raise a connection exception with reply code 530 - (not allowed). - </rule> - <rule implement="SHOULD"> - <test>amq_queue_40</test> - The server SHOULD support at least 4 bindings per queue, and - ideally, impose no limit except as defined by available resources. - </rule> - <chassis name="server" implement="MUST"/> - <response name="bind-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to bind. If the queue name is - empty, refers to the current queue for the channel, which is - the last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - </doc> - <doc name = "rule" test = "amq_queue_26"> - If the queue does not exist the server MUST raise a channel exception - with reply code 404 (not found). - </doc> - </field> - - <field name="exchange" domain="exchange name"> - The name of the exchange to bind to. - <rule implement="MUST"> - <test>amq_queue_14</test> - If the exchange does not exist the server MUST raise a channel - exception with reply code 404 (not found). - </rule> - </field> - <field name="routing key" type="shortstr"> - message routing key - <doc> - Specifies the routing key for the binding. The routing key is - used for routing messages depending on the exchange configuration. - Not all exchanges use a routing key - refer to the specific - exchange documentation. If the routing key is empty and the queue - name is empty, the routing key will be the current queue for the - channel, which is the last declared queue. - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table"> - arguments for binding - <doc> - A set of arguments for the binding. The syntax and semantics of - these arguments depends on the exchange class. - </doc> - </field> - </method> - <method name="bind-ok" synchronous="1" index="21"> - confirm bind successful - <doc> - This method confirms that the bind was successful. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="purge" synchronous="1" index="30"> - purge a queue - <doc> - This method removes all messages from a queue. It does not cancel - consumers. Purged messages are deleted without any formal "undo" - mechanism. - </doc> - <rule implement="MUST"> - <test>amq_queue_15</test> - A call to purge MUST result in an empty queue. - </rule> - <rule implement="MUST"> - <test>amq_queue_41</test> - On transacted channels the server MUST not purge messages that have - already been sent to a client but not yet acknowledged. - </rule> - <rule implement="MAY"> - <test>amq_queue_42</test> - The server MAY implement a purge queue or log that allows system - administrators to recover accidentally-purged messages. The server - SHOULD NOT keep purged messages in the same storage spaces as the - live messages since the volumes of purged messages may get very - large. - </rule> - <chassis name="server" implement="MUST"/> - <response name="purge-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - The access ticket must be for the access realm that holds the - queue. - </doc> - <rule implement="MUST"> - The client MUST provide a valid access ticket giving "read" access - rights to the queue's access realm. Note that purging a queue is - equivalent to reading all messages and discarding them. - </rule> - </field> - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to purge. If the queue name is - empty, refers to the current queue for the channel, which is - the last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - </doc> - <doc name = "rule" test = "amq_queue_16"> - The queue must exist. Attempting to purge a non-existing queue - causes a channel exception. - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - </method> - <method name="purge-ok" synchronous="1" index="31"> - confirms a queue purge - <doc> - This method confirms the purge of a queue. - </doc> - <chassis name="client" implement="MUST"/> - <field name="message count" type="long"> - number of messages purged - <doc> - Reports the number of messages purged. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="delete" synchronous="1" index="40"> - delete a queue - <doc> - This method deletes a queue. When a queue is deleted any pending - messages are sent to a dead-letter queue if this is defined in the - server configuration, and all consumers on the queue are cancelled. - </doc> - <rule implement="SHOULD"> - <test>amq_queue_43</test> - The server SHOULD use a dead-letter queue to hold messages that - were pending on a deleted queue, and MAY provide facilities for - a system administrator to move these messages back to an active - queue. - </rule> - <chassis name="server" implement="MUST"/> - <response name="delete-ok"/> - <field name="ticket" domain="access ticket"> - <doc> - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to delete. If the queue name is - empty, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue - name in this method is empty, the server MUST raise a connection - exception with reply code 530 (not allowed). - </doc> - <doc name = "rule" test = "amq_queue_21"> - The queue must exist. Attempting to delete a non-existing queue - causes a channel exception. - </doc> - </field> - - <field name="if unused" type="bit"> - delete only if unused - <doc> - If set, the server will only delete the queue if it has no - consumers. If the queue has consumers the server does does not - delete it but raises a channel exception instead. - </doc> - <rule implement="MUST"> - <test>amq_queue_29</test> - <test>amq_queue_30</test> - The server MUST respect the if-unused flag when deleting a queue. - </rule> - </field> - <field name="if empty" type="bit"> - delete only if empty - <test>amq_queue_27</test> - <doc> - If set, the server will only delete the queue if it has no - messages. If the queue is not empty the server raises a channel - exception. - </doc> - </field> - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - </method> - - <method name="delete-ok" synchronous="1" index="41"> - confirm deletion of a queue - <doc> - This method confirms the deletion of a queue. - </doc> - <chassis name="client" implement="MUST"/> - <field name="message count" type="long"> - number of messages purged - <doc> - Reports the number of messages purged. - </doc> - </field> - </method> - </class> - <class name="basic" handler="channel" index="60"> - <!-- -====================================================== -== BASIC MIDDLEWARE -====================================================== ---> - work with basic content -<doc> - The Basic class provides methods that support an industry-standard - messaging model. -</doc> - -<doc name = "grammar"> - basic = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT -</doc> - -<chassis name = "server" implement = "MUST" /> -<chassis name = "client" implement = "MAY" /> - -<doc name = "rule" test = "amq_basic_08"> - The server SHOULD respect the persistent property of basic messages - and SHOULD make a best-effort to hold persistent basic messages on a - reliable storage mechanism. -</doc> -<doc name = "rule" test = "amq_basic_09"> - The server MUST NOT discard a persistent basic message in case of a - queue overflow. The server MAY use the Channel.Flow method to slow - or stop a basic message publisher when necessary. -</doc> -<doc name = "rule" test = "amq_basic_10"> - The server MAY overflow non-persistent basic messages to persistent - storage and MAY discard or dead-letter non-persistent basic messages - on a priority basis if the queue size exceeds some configured limit. -</doc> -<doc name = "rule" test = "amq_basic_11"> - The server MUST implement at least 2 priority levels for basic - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. -</doc> -<doc name = "rule" test = "amq_basic_12"> - The server MUST deliver messages of the same priority in order - irrespective of their individual persistence. -</doc> -<doc name = "rule" test = "amq_basic_13"> - The server MUST support both automatic and explicit acknowledgements - on Basic content. -</doc> - -<!-- These are the properties for a Basic content --> - -<field name = "content type" type = "shortstr"> - MIME content type -</field> -<field name = "content encoding" type = "shortstr"> - MIME content encoding -</field> -<field name = "headers" type = "table"> - Message header field table -</field> -<field name = "delivery mode" type = "octet"> - Non-persistent (1) or persistent (2) -</field> -<field name = "priority" type = "octet"> - The message priority, 0 to 9 -</field> -<field name = "correlation id" type = "shortstr"> - The application correlation identifier -</field> -<field name = "reply to" type = "shortstr"> - The destination to reply to -</field> -<field name = "expiration" type = "shortstr"> - Message expiration specification -</field> -<field name = "message id" type = "shortstr"> - The application message identifier -</field> -<field name = "timestamp" type = "timestamp"> - The message timestamp -</field> -<field name = "type" type = "shortstr"> - The message type name -</field> -<field name = "user id" type = "shortstr"> - The creating user id -</field> -<field name = "app id" type = "shortstr"> - The creating application id -</field> -<field name = "cluster id" type = "shortstr"> - Intra-cluster routing identifier -</field> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "qos" synchronous = "1" index = "10"> - specify quality of service - <doc> - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch size" type = "long"> - prefetch window in octets - <doc> - The client can request that messages be sent in advance so that - when the client finishes processing a message, the following - message is already held locally, rather than needing to be sent - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. The - server will send a message in advance if it is equal to or - smaller in size than the available prefetch size (and also falls - into other prefetch limits). May be set to zero, meaning "no - specific limit", although other prefetch limits may still apply. - The prefetch-size is ignored if the no-ack option is set. - </doc> - <doc name = "rule" test = "amq_basic_17"> - The server MUST ignore this setting when the client is not - processing any messages - i.e. the prefetch size does not limit - the transfer of single messages to a client, only the sending in - advance of more messages while the client still has one or more - unacknowledged messages. - </doc> - </field> - - <field name = "prefetch count" type = "short"> - prefetch window in messages - <doc> - Specifies a prefetch window in terms of whole messages. This - field may be used in combination with the prefetch-size field; - a message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - The prefetch-count is ignored if the no-ack option is set. - </doc> - <doc name = "rule" test = "amq_basic_18"> - The server MAY send less data in advance than allowed by the - client's specified prefetch windows but it MUST NOT send more. - </doc> - </field> - - <field name = "global" type = "bit"> - apply to entire connection - <doc> - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - </doc> - </field> -</method> - -<method name = "qos-ok" synchronous = "1" index = "11"> - confirm the requested qos - <doc> - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - </doc> - <chassis name = "client" implement = "MUST" /> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "consume" synchronous = "1" index = "20"> - start a queue consumer - <doc> - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - </doc> - <doc name = "rule" test = "amq_basic_01"> - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - </doc> - <doc name = "rule" test = "todo"> - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - </doc> - </field> - - <field name = "no local" domain = "no local" /> - - <field name = "no ack" domain = "no ack" /> - - <field name = "exclusive" type = "bit"> - request exclusive access - <doc> - Request exclusive consumer access, meaning only this consumer can - access the queue. - </doc> - <doc name = "rule" test = "amq_basic_02"> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 403 (access refused). - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> - - <field name="arguments" type="table" label="arguments for consuming"> - <doc> - A set of arguments for the consume. The syntax and semantics - of these arguments depends on the server implementation. This - field is ignored if passive is 1. - </doc> - </field> -</method> - -<method name = "consume-ok" synchronous = "1" index = "21"> - confirm a new consumer - <doc> - The server provides the client with a consumer tag, which is used - by the client for methods called on the consumer at a later stage. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Holds the consumer tag specified by the client or provided by - the server. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "cancel" synchronous = "1" index = "30"> - end a queue consumer - <doc test = "amq_basic_04"> - This method cancels a consumer. This does not affect already - delivered messages, but it does mean the server will not send any - more messages for that consumer. The client may receive an - abitrary number of messages in between sending the cancel method - and receiving the cancel-ok reply. - </doc> - <doc name = "rule" test = "todo"> - If the queue no longer exists when the client sends a cancel command, - or the consumer has been cancelled for other reasons, this command - has no effect. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "cancel-ok" synchronous = "1" index = "31"> - confirm a cancelled consumer - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "publish" content = "1" index = "40"> - publish a message - <doc> - This method publishes a message to a specific exchange. The message - will be routed to queues as defined by the exchange configuration - and distributed to any active consumers when the transaction, if any, - is committed. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - </doc> - </field> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - </doc> - <doc name = "rule" test = "amq_basic_06"> - The server MUST accept a blank exchange name to mean the default - exchange. - </doc> - <doc name = "rule" test = "amq_basic_14"> - If the exchange was declared as an internal exchange, the server - MUST raise a channel exception with a reply code 403 (access - refused). - </doc> - <doc name = "rule" test = "amq_basic_15"> - The exchange MAY refuse basic content in which case it MUST raise - a channel exception with reply code 540 (not implemented). - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" type = "bit"> - indicate mandatory routing - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - </doc> - <doc name = "rule" test = "amq_basic_07"> - The server SHOULD implement the mandatory flag. - </doc> - </field> - - <field name = "immediate" type = "bit"> - request immediate delivery - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - <doc name = "rule" test = "amq_basic_16"> - The server SHOULD implement the immediate flag. - </doc> - </field> -</method> - -<method name = "return" content = "1" index = "50"> - return a failed message - <doc> - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "reply code" domain = "reply code" /> - <field name = "reply text" domain = "reply text" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "deliver" content = "1" index = "60"> - notify the client of a consumer message - <doc> - This method delivers a message to the client, via a consumer. In - the asynchronous message delivery model, the client starts a - consumer using the Consume method, then the server responds with - Deliver methods as and when messages arrive for that consumer. - </doc> - <doc name = "rule" test = "amq_basic_19"> - The server SHOULD track the number of times a message has been - delivered to clients and when a message is redelivered a certain - number of times - e.g. 5 times - without being acknowledged, the - server SHOULD consider the message to be unprocessable (possibly - causing client applications to abort), and move the message to a - dead letter queue. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "get" synchronous = "1" index = "70"> - direct access to a queue - <doc> - This method provides a direct access to the messages in a queue - using a synchronous dialogue that is designed for specific types of - application where synchronous functionality is more important than - performance. - </doc> - <response name = "get-ok" /> - <response name = "get-empty" /> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" - access rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "no ack" domain = "no ack" /> -</method> - -<method name = "get-ok" synchronous = "1" content = "1" index = "71"> - provide client with a message - <doc> - This method delivers a message to the client following a get - method. A message delivered by 'get-ok' must be acknowledged - unless the no-ack option was set in the get method. - </doc> - <chassis name = "client" implement = "MAY" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was originally - published to. If empty, the message was published to the default - exchange. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> - - <field name = "message count" type = "long" > - number of messages pending - <doc> - This field reports the number of messages pending on the queue, - excluding the message being delivered. Note that this figure is - indicative, not reliable, and can change arbitrarily as messages - are added to the queue and removed by other clients. - </doc> - </field> -</method> - - -<method name = "get-empty" synchronous = "1" index = "72"> - indicate no messages available - <doc> - This method tells the client that the queue has no messages - available for the client. - </doc> - <chassis name = "client" implement = "MAY" /> - - <field name = "cluster id" type = "shortstr"> - Cluster id - <doc> - For use by cluster applications, should not be used by - client applications. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "ack" index = "80"> - acknowledge one or more messages - <doc> - This method acknowledges one or more messages delivered via the - Deliver or Get-Ok methods. The client can ask to confirm a - single message or a set of messages up to and including a specific - message. - </doc> - <chassis name = "server" implement = "MUST" /> - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "multiple" type = "bit"> - acknowledge multiple messages - <doc> - If set to 1, the delivery tag is treated as "up to and including", - so that the client can acknowledge multiple messages with a single - method. If set to zero, the delivery tag refers to a single - message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding mesages. - </doc> - <doc name = "rule" test = "amq_basic_20"> - The server MUST validate that a non-zero delivery-tag refers to an - delivered message, and raise a channel exception if this is not the - case. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "reject" index = "90"> - reject an incoming message - <doc> - This method allows a client to reject a message. It can be used to - interrupt and cancel large incoming messages, or return untreatable - messages to their original queue. - </doc> - <doc name = "rule" test = "amq_basic_21"> - The server SHOULD be capable of accepting and process the Reject - method while sending message content with a Deliver or Get-Ok - method. I.e. the server should read and process incoming methods - while sending output frames. To cancel a partially-send content, - the server sends a content body frame of size 1 (i.e. with no data - except the frame-end octet). - </doc> - <doc name = "rule" test = "amq_basic_22"> - The server SHOULD interpret this method as meaning that the client - is unable to process the message at this time. - </doc> - <doc name = "rule"> - A client MUST NOT use this method as a means of selecting messages - to process. A rejected message MAY be discarded or dead-lettered, - not necessarily passed to another client. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be discarded. If this bit - is 1, the server will attempt to requeue the message. - </doc> - <doc name = "rule" test = "amq_basic_23"> - The server MUST NOT deliver the message to the same client within - the context of the current channel. The recommended strategy is - to attempt to deliver the message to an alternative consumer, and - if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold - the message on the queue and redeliver it to the same client at - a later stage. - </doc> - </field> -</method> - -<method name = "recover" index = "100"> - redeliver unacknowledged messages - <doc> - This method asks the broker to redeliver all unacknowledged messages on a - specified channel. Zero or more messages may be redelivered. This method - is only allowed on non-transacted channels. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the - message, potentially then delivering it to an alternative subscriber. - </doc> - </field> - <doc name="rule"> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - <doc name="rule"> - The server MUST raise a channel exception if this is called on a - transacted channel. - </doc> - <response name="recover-ok"/> - </method> - <method name="recover-ok" synchronous="1" index="101"> - confirm a successful recover - <doc> - This method confirms to the client that the recover succeeded. - Note that if an recover fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - -</class> - - - <class name="file" handler="channel" index="70"> - <!-- -====================================================== -== FILE TRANSFER -====================================================== ---> - work with file content -<doc> - The file class provides methods that support reliable file transfer. - File messages have a specific set of properties that are required for - interoperability with file transfer applications. File messages and - acknowledgements are subject to channel transactions. Note that the - file class does not provide message browsing methods; these are not - compatible with the staging model. Applications that need browsable - file transfer should use Basic content and the Basic class. -</doc> - -<doc name = "grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT -</doc> - -<chassis name = "server" implement = "MAY" /> -<chassis name = "client" implement = "MAY" /> - -<doc name = "rule"> - The server MUST make a best-effort to hold file messages on a - reliable storage mechanism. -</doc> -<doc name = "rule"> - The server MUST NOT discard a file message in case of a queue - overflow. The server MUST use the Channel.Flow method to slow or stop - a file message publisher when necessary. -</doc> -<doc name = "rule"> - The server MUST implement at least 2 priority levels for file - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. -</doc> -<doc name = "rule"> - The server MUST support both automatic and explicit acknowledgements - on file content. -</doc> - -<!-- These are the properties for a File content --> - -<field name = "content type" type = "shortstr"> - MIME content type -</field> -<field name = "content encoding" type = "shortstr"> - MIME content encoding -</field> -<field name = "headers" type = "table"> - Message header field table -</field> -<field name = "priority" type = "octet"> - The message priority, 0 to 9 -</field> -<field name = "reply to" type = "shortstr"> - The destination to reply to -</field> -<field name = "message id" type = "shortstr"> - The application message identifier -</field> -<field name = "filename" type = "shortstr"> - The message filename -</field> -<field name = "timestamp" type = "timestamp"> - The message timestamp -</field> -<field name = "cluster id" type = "shortstr"> - Intra-cluster routing identifier -</field> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "qos" synchronous = "1" index = "10"> - specify quality of service - <doc> - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch size" type = "long"> - prefetch window in octets - <doc> - The client can request that messages be sent in advance so that - when the client finishes processing a message, the following - message is already held locally, rather than needing to be sent - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. May be - set to zero, meaning "no specific limit". Note that other - prefetch limits may still apply. The prefetch-size is ignored - if the no-ack option is set. - </doc> - </field> - - <field name = "prefetch count" type = "short"> - prefetch window in messages - <doc> - Specifies a prefetch window in terms of whole messages. This - is compatible with some file API implementations. This field - may be used in combination with the prefetch-size field; a - message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - The prefetch-count is ignored if the no-ack option is set. - </doc> - <doc name = "rule"> - The server MAY send less data in advance than allowed by the - client's specified prefetch windows but it MUST NOT send more. - </doc> - </field> - - <field name = "global" type = "bit"> - apply to entire connection - <doc> - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - </doc> - </field> -</method> - -<method name = "qos-ok" synchronous = "1" index = "11"> - confirm the requested qos - <doc> - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - </doc> - <chassis name = "client" implement = "MUST" /> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "consume" synchronous = "1" index = "20"> - start a queue consumer - <doc> - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - </doc> - <doc name = "rule"> - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - </doc> - <doc name = "rule" test = "todo"> - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - </doc> - </field> - - <field name = "no local" domain = "no local" /> - - <field name = "no ack" domain = "no ack" /> - - <field name = "exclusive" type = "bit"> - request exclusive access - <doc> - Request exclusive consumer access, meaning only this consumer can - access the queue. - </doc> - <doc name = "rule" test = "amq_file_00"> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 405 (resource locked). - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "consume-ok" synchronous = "1" index = "21"> - confirm a new consumer - <doc> - This method provides the client with a consumer tag which it MUST - use in methods that work with the consumer. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Holds the consumer tag specified by the client or provided by - the server. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "cancel" synchronous = "1" index = "30"> - end a queue consumer - <doc> - This method cancels a consumer. This does not affect already - delivered messages, but it does mean the server will not send any - more messages for that consumer. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "cancel-ok" synchronous = "1" index = "31"> - confirm a cancelled consumer - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "open" synchronous = "1" index = "40"> - request to start staging - <doc> - This method requests permission to start staging a message. Staging - means sending the message into a temporary area at the recipient end - and then delivering the message by referring to this temporary area. - Staging is how the protocol handles partial file transfers - if a - message is partially staged and the connection breaks, the next time - the sender starts to stage it, it can restart from where it left off. - </doc> - <response name = "open-ok" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "identifier" type = "shortstr"> - staging identifier - <doc> - This is the staging identifier. This is an arbitrary string chosen - by the sender. For staging to work correctly the sender must use - the same staging identifier when staging the same message a second - time after recovery from a failure. A good choice for the staging - identifier would be the SHA1 hash of the message properties data - (including the original filename, revised time, etc.). - </doc> - </field> - - <field name = "content size" type = "longlong"> - message content size - <doc> - The size of the content in octets. The recipient may use this - information to allocate or check available space in advance, to - avoid "disk full" errors during staging of very large messages. - </doc> - <doc name = "rule"> - The sender MUST accurately fill the content-size field. - Zero-length content is permitted. - </doc> - </field> -</method> - -<method name = "open-ok" synchronous = "1" index = "41"> - confirm staging ready - <doc> - This method confirms that the recipient is ready to accept staged - data. If the message was already partially-staged at a previous - time the recipient will report the number of octets already staged. - </doc> - <response name = "stage" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "staged size" type = "longlong"> - already staged amount - <doc> - The amount of previously-staged content in octets. For a new - message this will be zero. - </doc> - <doc name = "rule"> - The sender MUST start sending data from this octet offset in the - message, counting from zero. - </doc> - <doc name = "rule"> - The recipient MAY decide how long to hold partially-staged content - and MAY implement staging by always discarding partially-staged - content. However if it uses the file content type it MUST support - the staging methods. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "stage" content = "1" index = "50"> - stage message content - <doc> - This method stages the message, sending the message content to the - recipient from the octet offset specified in the Open-Ok method. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "publish" index = "60"> - publish a message - <doc> - This method publishes a staged file message to a specific exchange. - The file message will be routed to queues as defined by the exchange - configuration and distributed to any active consumers when the - transaction, if any, is committed. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - </doc> - </field> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - </doc> - <doc name = "rule"> - The server MUST accept a blank exchange name to mean the default - exchange. - </doc> - <doc name = "rule"> - If the exchange was declared as an internal exchange, the server - MUST respond with a reply code 403 (access refused) and raise a - channel exception. - </doc> - <doc name = "rule"> - The exchange MAY refuse file content in which case it MUST respond - with a reply code 540 (not implemented) and raise a channel - exception. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" type = "bit"> - indicate mandatory routing - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - </doc> - <doc name = "rule" test = "amq_file_00"> - The server SHOULD implement the mandatory flag. - </doc> - </field> - - <field name = "immediate" type = "bit"> - request immediate delivery - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - <doc name = "rule" test = "amq_file_00"> - The server SHOULD implement the immediate flag. - </doc> - </field> - - <field name = "identifier" type = "shortstr"> - staging identifier - <doc> - This is the staging identifier of the message to publish. The - message must have been staged. Note that a client can send the - Publish method asynchronously without waiting for staging to - finish. - </doc> - </field> -</method> - -<method name = "return" content = "1" index = "70"> - return a failed message - <doc> - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "reply code" domain = "reply code" /> - <field name = "reply text" domain = "reply text" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "deliver" index = "80"> - notify the client of a consumer message - <doc> - This method delivers a staged file message to the client, via a - consumer. In the asynchronous message delivery model, the client - starts a consumer using the Consume method, then the server - responds with Deliver methods as and when messages arrive for - that consumer. - </doc> - <doc name = "rule"> - The server SHOULD track the number of times a message has been - delivered to clients and when a message is redelivered a certain - number of times - e.g. 5 times - without being acknowledged, the - server SHOULD consider the message to be unprocessable (possibly - causing client applications to abort), and move the message to a - dead letter queue. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was originally - published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> - - <field name = "identifier" type = "shortstr"> - staging identifier - <doc> - This is the staging identifier of the message to deliver. The - message must have been staged. Note that a server can send the - Deliver method asynchronously without waiting for staging to - finish. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "ack" index = "90"> - acknowledge one or more messages - <doc> - This method acknowledges one or more messages delivered via the - Deliver method. The client can ask to confirm a single message or - a set of messages up to and including a specific message. - </doc> - <chassis name = "server" implement = "MUST" /> - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "multiple" type = "bit"> - acknowledge multiple messages - <doc> - If set to 1, the delivery tag is treated as "up to and including", - so that the client can acknowledge multiple messages with a single - method. If set to zero, the delivery tag refers to a single - message. If the multiple field is 1, and the delivery tag is zero, - tells the server to acknowledge all outstanding mesages. - </doc> - <doc name = "rule"> - The server MUST validate that a non-zero delivery-tag refers to an - delivered message, and raise a channel exception if this is not the - case. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "reject" index = "100"> - reject an incoming message - <doc> - This method allows a client to reject a message. It can be used to - return untreatable messages to their original queue. Note that file - content is staged before delivery, so the client will not use this - method to interrupt delivery of a large message. - </doc> - <doc name = "rule"> - The server SHOULD interpret this method as meaning that the client - is unable to process the message at this time. - </doc> - <doc name = "rule"> - A client MUST NOT use this method as a means of selecting messages - to process. A rejected message MAY be discarded or dead-lettered, - not necessarily passed to another client. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be discarded. If this bit - is 1, the server will attempt to requeue the message. - </doc> - <doc name = "rule"> - The server MUST NOT deliver the message to the same client within - the context of the current channel. The recommended strategy is - to attempt to deliver the message to an alternative consumer, and - if that is not possible, to move the message to a dead-letter - queue. The server MAY use more sophisticated tracking to hold - the message on the queue and redeliver it to the same client at - a later stage. - </doc> - </field> -</method> - -</class> - - <class name="stream" handler="channel" index="80"> - <!-- -====================================================== -== STREAMING -====================================================== ---> - work with streaming content - -<doc> - The stream class provides methods that support multimedia streaming. - The stream class uses the following semantics: one message is one - packet of data; delivery is unacknowleged and unreliable; the consumer - can specify quality of service parameters that the server can try to - adhere to; lower-priority messages may be discarded in favour of high - priority messages. -</doc> - -<doc name = "grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN - / S:DELIVER content -</doc> - -<chassis name = "server" implement = "MAY" /> -<chassis name = "client" implement = "MAY" /> - -<doc name = "rule"> - The server SHOULD discard stream messages on a priority basis if - the queue size exceeds some configured limit. -</doc> -<doc name = "rule"> - The server MUST implement at least 2 priority levels for stream - messages, where priorities 0-4 and 5-9 are treated as two distinct - levels. The server MAY implement up to 10 priority levels. -</doc> -<doc name = "rule"> - The server MUST implement automatic acknowledgements on stream - content. That is, as soon as a message is delivered to a client - via a Deliver method, the server must remove it from the queue. -</doc> - - -<!-- These are the properties for a Stream content --> - -<field name = "content type" type = "shortstr"> - MIME content type -</field> -<field name = "content encoding" type = "shortstr"> - MIME content encoding -</field> -<field name = "headers" type = "table"> - Message header field table -</field> -<field name = "priority" type = "octet"> - The message priority, 0 to 9 -</field> -<field name = "timestamp" type = "timestamp"> - The message timestamp -</field> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "qos" synchronous = "1" index = "10"> - specify quality of service - <doc> - This method requests a specific quality of service. The QoS can - be specified for the current channel or for all channels on the - connection. The particular properties and semantics of a qos method - always depend on the content class semantics. Though the qos method - could in principle apply to both peers, it is currently meaningful - only for the server. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch size" type = "long"> - prefetch window in octets - <doc> - The client can request that messages be sent in advance so that - when the client finishes processing a message, the following - message is already held locally, rather than needing to be sent - down the channel. Prefetching gives a performance improvement. - This field specifies the prefetch window size in octets. May be - set to zero, meaning "no specific limit". Note that other - prefetch limits may still apply. - </doc> - </field> - - <field name = "prefetch count" type = "short"> - prefetch window in messages - <doc> - Specifies a prefetch window in terms of whole messages. This - field may be used in combination with the prefetch-size field; - a message will only be sent in advance if both prefetch windows - (and those at the channel and connection level) allow it. - </doc> - </field> - - <field name = "consume rate" type = "long"> - transfer rate in octets/second - <doc> - Specifies a desired transfer rate in octets per second. This is - usually determined by the application that uses the streaming - data. A value of zero means "no limit", i.e. as rapidly as - possible. - </doc> - <doc name = "rule"> - The server MAY ignore the prefetch values and consume rates, - depending on the type of stream and the ability of the server - to queue and/or reply it. The server MAY drop low-priority - messages in favour of high-priority messages. - </doc> - </field> - - <field name = "global" type = "bit"> - apply to entire connection - <doc> - By default the QoS settings apply to the current channel only. If - this field is set, they are applied to the entire connection. - </doc> - </field> -</method> - -<method name = "qos-ok" synchronous = "1" index = "11"> - confirm the requested qos - <doc> - This method tells the client that the requested QoS levels could - be handled by the server. The requested QoS applies to all active - consumers until a new QoS is defined. - </doc> - <chassis name = "client" implement = "MUST" /> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "consume" synchronous = "1" index = "20"> - start a queue consumer - <doc> - This method asks the server to start a "consumer", which is a - transient request for messages from a specific queue. Consumers - last as long as the channel they were created on, or until the - client cancels them. - </doc> - <doc name = "rule"> - The server SHOULD support at least 16 consumers per queue, unless - the queue was declared as private, and ideally, impose no limit - except as defined by available resources. - </doc> - <doc name = "rule"> - Streaming applications SHOULD use different channels to select - different streaming resolutions. AMQP makes no provision for - filtering and/or transforming streams except on the basis of - priority-based selective delivery of individual messages. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "read" access - rights to the realm for the queue. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue to consume from. If the queue name - is null, refers to the current queue for the channel, which is the - last declared queue. - </doc> - <doc name = "rule"> - If the client did not previously declare a queue, and the queue name - in this method is empty, the server MUST raise a connection exception - with reply code 530 (not allowed). - </doc> - </field> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is - local to a connection, so two clients can use the same consumer - tags. If this field is empty the server will generate a unique - tag. - </doc> - <doc name = "rule" test = "todo"> - The tag MUST NOT refer to an existing consumer. If the client - attempts to create two consumers with the same non-empty tag - the server MUST raise a connection exception with reply code - 530 (not allowed). - </doc> - </field> - - <field name = "no local" domain = "no local" /> - - <field name = "exclusive" type = "bit"> - request exclusive access - <doc> - Request exclusive consumer access, meaning only this consumer can - access the queue. - </doc> - <doc name = "rule" test = "amq_file_00"> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel - exception with return code 405 (resource locked). - </doc> - </field> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - - -<method name = "consume-ok" synchronous = "1" index = "21"> - confirm a new consumer - <doc> - This method provides the client with a consumer tag which it may - use in methods that work with the consumer. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag"> - <doc> - Holds the consumer tag specified by the client or provided by - the server. - </doc> - </field> -</method> - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "cancel" synchronous = "1" index = "30"> - end a queue consumer - <doc> - This method cancels a consumer. Since message delivery is - asynchronous the client may continue to receive messages for - a short while after canceling a consumer. It may process or - discard these as appropriate. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "nowait" type = "bit"> - do not send a reply method - <doc> - If set, the server will not respond to the method. The client should - not wait for a reply method. If the server could not complete the - method it will raise a channel or connection exception. - </doc> - </field> -</method> - -<method name = "cancel-ok" synchronous = "1" index = "31"> - confirm a cancelled consumer - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "publish" content = "1" index = "40"> - publish a message - <doc> - This method publishes a message to a specific exchange. The message - will be routed to queues as defined by the exchange configuration - and distributed to any active consumers as appropriate. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access ticket"> - <doc name = "rule"> - The client MUST provide a valid access ticket giving "write" - access rights to the access realm for the exchange. - </doc> - </field> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange to publish to. The exchange - name can be empty, meaning the default exchange. If the exchange - name is specified, and that exchange does not exist, the server - will raise a channel exception. - </doc> - <doc name = "rule"> - The server MUST accept a blank exchange name to mean the default - exchange. - </doc> - <doc name = "rule"> - If the exchange was declared as an internal exchange, the server - MUST respond with a reply code 403 (access refused) and raise a - channel exception. - </doc> - <doc name = "rule"> - The exchange MAY refuse stream content in which case it MUST - respond with a reply code 540 (not implemented) and raise a - channel exception. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" type = "bit"> - indicate mandatory routing - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue. If this flag is set, the server will return an - unroutable message with a Return method. If this flag is zero, the - server silently drops the message. - </doc> - <doc name = "rule" test = "amq_stream_00"> - The server SHOULD implement the mandatory flag. - </doc> - </field> - - <field name = "immediate" type = "bit"> - request immediate delivery - <doc> - This flag tells the server how to react if the message cannot be - routed to a queue consumer immediately. If this flag is set, the - server will return an undeliverable message with a Return method. - If this flag is zero, the server will queue the message, but with - no guarantee that it will ever be consumed. - </doc> - <doc name = "rule" test = "amq_stream_00"> - The server SHOULD implement the immediate flag. - </doc> - </field> -</method> - -<method name = "return" content = "1" index = "50"> - return a failed message - <doc> - This method returns an undeliverable message that was published - with the "immediate" flag set, or an unroutable message published - with the "mandatory" flag set. The reply code and text provide - information about the reason that the message was undeliverable. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "reply code" domain = "reply code" /> - <field name = "reply text" domain = "reply text" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was - originally published to. - </doc> - </field> - - <field name = "routing key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key name specified when the message was - published. - </doc> - </field> -</method> - - -<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - -<method name = "deliver" content = "1" index = "60"> - notify the client of a consumer message - <doc> - This method delivers a message to the client, via a consumer. In - the asynchronous message delivery model, the client starts a - consumer using the Consume method, then the server responds with - Deliver methods as and when messages arrive for that consumer. - </doc> - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer tag" domain = "consumer tag" /> - - <field name = "delivery tag" domain = "delivery tag" /> - - <field name = "exchange" domain = "exchange name"> - <doc> - Specifies the name of the exchange that the message was originally - published to. - </doc> - </field> - - <field name = "queue" domain = "queue name"> - <doc> - Specifies the name of the queue that the message came from. Note - that a single channel can start many consumers on different - queues. - </doc> - <assert check = "notnull" /> - </field> -</method> - </class> - - <class name="tx" handler="channel" index="90"> - <!-- -====================================================== -== TRANSACTIONS -====================================================== ---> - work with standard transactions - -<doc> - Standard transactions provide so-called "1.5 phase commit". We can - ensure that work is never lost, but there is a chance of confirmations - being lost, so that messages may be resent. Applications that use - standard transactions must be able to detect and ignore duplicate - messages. -</doc> - <rule implement="SHOULD"> - An client using standard transactions SHOULD be able to track all - messages received within a reasonable period, and thus detect and - reject duplicates of the same message. It SHOULD NOT pass these to - the application layer. -</rule> - <doc name="grammar"> - tx = C:SELECT S:SELECT-OK - / C:COMMIT S:COMMIT-OK - / C:ROLLBACK S:ROLLBACK-OK -</doc> - <chassis name="server" implement="SHOULD"/> - <chassis name="client" implement="MAY"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="select" synchronous="1" index="10"> -select standard transaction mode - <doc> - This method sets the channel to use standard transactions. The - client must use this method at least once on a channel before - using the Commit or Rollback methods. - </doc> - <chassis name="server" implement="MUST"/> - <response name="select-ok"/> - </method> - <method name="select-ok" synchronous="1" index="11"> -confirm transaction mode - <doc> - This method confirms to the client that the channel was successfully - set to use standard transactions. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="commit" synchronous="1" index="20"> -commit the current transaction - <doc> - This method commits all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a commit. - </doc> - <chassis name="server" implement="MUST"/> - <response name="commit-ok"/> - </method> - <method name="commit-ok" synchronous="1" index="21"> -confirm a successful commit - <doc> - This method confirms to the client that the commit succeeded. - Note that if a commit fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="rollback" synchronous="1" index="30"> -abandon the current transaction - <doc> - This method abandons all messages published and acknowledged in - the current transaction. A new transaction starts immediately - after a rollback. - </doc> - <chassis name="server" implement="MUST"/> - <response name="rollback-ok"/> - </method> - <method name="rollback-ok" synchronous="1" index="31"> -confirm a successful rollback - <doc> - This method confirms to the client that the rollback succeeded. - Note that if an rollback fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - </class> - <class name="dtx" handler="channel" index="100"> - <!-- -====================================================== -== DISTRIBUTED TRANSACTIONS -====================================================== ---> - work with distributed transactions - -<doc> - Distributed transactions provide so-called "2-phase commit". The - AMQP distributed transaction model supports the X-Open XA - architecture and other distributed transaction implementations. - The Dtx class assumes that the server has a private communications - channel (not AMQP) to a distributed transaction coordinator. -</doc> - <doc name="grammar"> - dtx = C:SELECT S:SELECT-OK - C:START S:START-OK -</doc> - <chassis name="server" implement="MAY"/> - <chassis name="client" implement="MAY"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="select" synchronous="1" index="10"> -select standard transaction mode - <doc> - This method sets the channel to use distributed transactions. The - client must use this method at least once on a channel before - using the Start method. - </doc> - <chassis name="server" implement="MUST"/> - <response name="select-ok"/> - </method> - <method name="select-ok" synchronous="1" index="11"> -confirm transaction mode - <doc> - This method confirms to the client that the channel was successfully - set to use distributed transactions. - </doc> - <chassis name="client" implement="MUST"/> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="start" synchronous="1" index="20"> - start a new distributed transaction - <doc> - This method starts a new distributed transaction. This must be - the first method on a new channel that uses the distributed - transaction mode, before any methods that publish or consume - messages. - </doc> - <chassis name="server" implement="MAY"/> - <response name="start-ok"/> - <field name="dtx identifier" type="shortstr"> - transaction identifier - <doc> - The distributed transaction key. This identifies the transaction - so that the AMQP server can coordinate with the distributed - transaction coordinator. - </doc> - <assert check="notnull"/> - </field> - </method> - <method name="start-ok" synchronous="1" index="21"> - confirm the start of a new distributed transaction - <doc> - This method confirms to the client that the transaction started. - Note that if a start fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - </class> - <class name="tunnel" handler="tunnel" index="110"> - <!-- -====================================================== -== TUNNEL -====================================================== ---> - methods for protocol tunneling. - -<doc> - The tunnel methods are used to send blocks of binary data - which - can be serialised AMQP methods or other protocol frames - between - AMQP peers. -</doc> - <doc name="grammar"> - tunnel = C:REQUEST - / S:REQUEST -</doc> - <chassis name="server" implement="MAY"/> - <chassis name="client" implement="MAY"/> - <field name="headers" type="table"> - Message header field table -</field> - <field name="proxy name" type="shortstr"> - The identity of the tunnelling proxy -</field> - <field name="data name" type="shortstr"> - The name or type of the message being tunnelled -</field> - <field name="durable" type="octet"> - The message durability indicator -</field> - <field name="broadcast" type="octet"> - The message broadcast mode -</field> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="request" content="1" index="10"> - sends a tunnelled method - <doc> - This method tunnels a block of binary data, which can be an - encoded AMQP method or other data. The binary data is sent - as the content for the Tunnel.Request method. - </doc> - <chassis name="server" implement="MUST"/> - <field name="meta data" type="table"> - meta data for the tunnelled block - <doc> - This field table holds arbitrary meta-data that the sender needs - to pass to the recipient. - </doc> - </field> - </method> - </class> - <class name="test" handler="channel" index="120"> - <!-- -====================================================== -== TEST - CHECK FUNCTIONAL CAPABILITIES OF AN IMPLEMENTATION -====================================================== ---> - test functional primitives of the implementation - -<doc> - The test class provides methods for a peer to test the basic - operational correctness of another peer. The test methods are - intended to ensure that all peers respect at least the basic - elements of the protocol, such as frame and content organisation - and field types. We assume that a specially-designed peer, a - "monitor client" would perform such tests. -</doc> - <doc name="grammar"> - test = C:INTEGER S:INTEGER-OK - / S:INTEGER C:INTEGER-OK - / C:STRING S:STRING-OK - / S:STRING C:STRING-OK - / C:TABLE S:TABLE-OK - / S:TABLE C:TABLE-OK - / C:CONTENT S:CONTENT-OK - / S:CONTENT C:CONTENT-OK -</doc> - <chassis name="server" implement="MUST"/> - <chassis name="client" implement="SHOULD"/> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="integer" synchronous="1" index="10"> - test integer handling - <doc> - This method tests the peer's capability to correctly marshal integer - data. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="integer-ok"/> - <field name="integer 1" type="octet"> - octet test value - <doc> - An octet integer test value. - </doc> - </field> - <field name="integer 2" type="short"> - short test value - <doc> - A short integer test value. - </doc> - </field> - <field name="integer 3" type="long"> - long test value - <doc> - A long integer test value. - </doc> - </field> - <field name="integer 4" type="longlong"> - long-long test value - <doc> - A long long integer test value. - </doc> - </field> - <field name="operation" type="octet"> - operation to test - <doc> - The client must execute this operation on the provided integer - test fields and return the result. - </doc> - <assert check="enum"> - <value name="add">return sum of test values</value> - <value name="min">return lowest of test values</value> - <value name="max">return highest of test values</value> - </assert> - </field> - </method> - <method name="integer-ok" synchronous="1" index="11"> - report integer test result - <doc> - This method reports the result of an Integer method. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="result" type="longlong"> - result value - <doc> - The result of the tested operation. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="string" synchronous="1" index="20"> - test string handling - <doc> - This method tests the peer's capability to correctly marshal string - data. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="string-ok"/> - <field name="string 1" type="shortstr"> - short string test value - <doc> - An short string test value. - </doc> - </field> - <field name="string 2" type="longstr"> - long string test value - <doc> - A long string test value. - </doc> - </field> - <field name="operation" type="octet"> - operation to test - <doc> - The client must execute this operation on the provided string - test fields and return the result. - </doc> - <assert check="enum"> - <value name="add">return concatentation of test strings</value> - <value name="min">return shortest of test strings</value> - <value name="max">return longest of test strings</value> - </assert> - </field> - </method> - <method name="string-ok" synchronous="1" index="21"> - report string test result - <doc> - This method reports the result of a String method. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="result" type="longstr"> - result value - <doc> - The result of the tested operation. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="table" synchronous="1" index="30"> - test field table handling - <doc> - This method tests the peer's capability to correctly marshal field - table data. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="table-ok"/> - <field name="table" type="table"> - field table of test values - <doc> - A field table of test values. - </doc> - </field> - <field name="integer op" type="octet"> - operation to test on integers - <doc> - The client must execute this operation on the provided field - table integer values and return the result. - </doc> - <assert check="enum"> - <value name="add">return sum of numeric field values</value> - <value name="min">return min of numeric field values</value> - <value name="max">return max of numeric field values</value> - </assert> - </field> - <field name="string op" type="octet"> - operation to test on strings - <doc> - The client must execute this operation on the provided field - table string values and return the result. - </doc> - <assert check="enum"> - <value name="add">return concatenation of string field values</value> - <value name="min">return shortest of string field values</value> - <value name="max">return longest of string field values</value> - </assert> - </field> - </method> - <method name="table-ok" synchronous="1" index="31"> - report table test result - <doc> - This method reports the result of a Table method. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="integer result" type="longlong"> - integer result value - <doc> - The result of the tested integer operation. - </doc> - </field> - <field name="string result" type="longstr"> - string result value - <doc> - The result of the tested string operation. - </doc> - </field> - </method> - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="content" synchronous="1" content="1" index="40"> - test content handling - <doc> - This method tests the peer's capability to correctly marshal content. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <response name="content-ok"/> - </method> - <method name="content-ok" synchronous="1" content="1" index="41"> - report content test result - <doc> - This method reports the result of a Content method. It contains the - content checksum and echoes the original content as provided. - </doc> - <chassis name="client" implement="MUST"/> - <chassis name="server" implement="MUST"/> - <field name="content checksum" type="long"> - content hash - <doc> - The 32-bit checksum of the content, calculated by adding the - content into a 32-bit accumulator. - </doc> - </field> - </method> - </class> -</amqp> diff --git a/qpid/specs/amqp.0-9.xml b/qpid/specs/amqp.0-9.xml deleted file mode 100644 index 73cace7015..0000000000 --- a/qpid/specs/amqp.0-9.xml +++ /dev/null @@ -1,5248 +0,0 @@ -<?xml version = "1.0"?> - -<!-- - EDITORS: (PH) Pieter Hintjens <ph@imatix.com> - (KvdR) Kim van der Riet <kim.vdriet@redhat.com> - - These editors have been assigned by the AMQP working group. - Please do not edit/commit this file without consulting with - one of the above editors. - ======================================================== - - TODOs - - see TODO comments in the text ---> - -<!-- - Copyright Notice - ================ - (c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., - iMatix Corporation, IONA\ufffd Technologies, Red Hat, Inc., - TWIST Process Innovations, and 29West Inc. 2006. All rights reserved. - - License - ======= - JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy Technologies Inc., iMatix - Corporation, IONA Technologies, Red Hat, Inc., TWIST Process Innovations, and - 29West Inc. (collectively, the "Authors") each hereby grants to you a worldwide, - perpetual, royalty-free, nontransferable, nonexclusive license to - (i) copy, display, distribute and implement the Advanced Messaging Queue Protocol - ("AMQP") Specification and (ii) the Licensed Claims that are held by - the Authors, all for the purpose of implementing the Advanced Messaging - Queue Protocol Specification. Your license and any rights under this - Agreement will terminate immediately without notice from - any Author if you bring any claim, suit, demand, or action related to - the Advanced Messaging Queue Protocol Specification against any Author. - Upon termination, you shall destroy all copies of the Advanced Messaging - Queue Protocol Specification in your possession or control. - - As used hereunder, "Licensed Claims" means those claims of a patent or - patent application, throughout the world, excluding design patents and - design registrations, owned or controlled, or that can be sublicensed - without fee and in compliance with the requirements of this - Agreement, by an Author or its affiliates now or at any - future time and which would necessarily be infringed by implementation - of the Advanced Messaging Queue Protocol Specification. A claim is - necessarily infringed hereunder only when it is not possible to avoid - infringing it because there is no plausible non-infringing alternative - for implementing the required portions of the Advanced Messaging Queue - Protocol Specification. Notwithstanding the foregoing, Licensed Claims - shall not include any claims other than as set forth above even if - contained in the same patent as Licensed Claims; or that read solely - on any implementations of any portion of the Advanced Messaging Queue - Protocol Specification that are not required by the Advanced Messaging - Queue Protocol Specification, or that, if licensed, would require a - payment of royalties by the licensor to unaffiliated third parties. - Moreover, Licensed Claims shall not include (i) any enabling technologies - that may be necessary to make or use any Licensed Product but are not - themselves expressly set forth in the Advanced Messaging Queue Protocol - Specification (e.g., semiconductor manufacturing technology, compiler - technology, object oriented technology, networking technology, operating - system technology, and the like); or (ii) the implementation of other - published standards developed elsewhere and merely referred to in the - body of the Advanced Messaging Queue Protocol Specification, or - (iii) any Licensed Product and any combinations thereof the purpose or - function of which is not required for compliance with the Advanced - Messaging Queue Protocol Specification. For purposes of this definition, - the Advanced Messaging Queue Protocol Specification shall be deemed to - include both architectural and interconnection requirements essential - for interoperability and may also include supporting source code artifacts - where such architectural, interconnection requirements and source code - artifacts are expressly identified as being required or documentation to - achieve compliance with the Advanced Messaging Queue Protocol Specification. - - As used hereunder, "Licensed Products" means only those specific portions - of products (hardware, software or combinations thereof) that implement - and are compliant with all relevant portions of the Advanced Messaging - Queue Protocol Specification. - - The following disclaimers, which you hereby also acknowledge as to any - use you may make of the Advanced Messaging Queue Protocol Specification: - - THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED "AS IS," - AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR - IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, - FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE - CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE - SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED - MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY - PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. - - THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, - INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY - USE, IMPLEMENTATION OR DISTRIBUTION OF THE ADVANCED MESSAGING QUEUE - PROTOCOL SPECIFICATION. - - The name and trademarks of the Authors may NOT be used in any manner, - including advertising or publicity pertaining to the Advanced Messaging - Queue Protocol Specification or its contents without specific, written - prior permission. Title to copyright in the Advanced Messaging Queue - Protocol Specification will at all times remain with the Authors. - - No other rights are granted by implication, estoppel or otherwise. - - Upon termination of your license or rights under this Agreement, you - shall destroy all copies of the Advanced Messaging Queue Protocol - Specification in your possession or control. - - Trademarks - ========== - "JPMorgan", "JPMorgan Chase", "Chase", the JPMorgan Chase logo and the - Octagon Symbol are trademarks of JPMorgan Chase & Co. - - IMATIX and the iMatix logo are trademarks of iMatix Corporation sprl. - - IONA, IONA Technologies, and the IONA logos are trademarks of IONA - Technologies PLC and/or its subsidiaries. - - LINUX is a trademark of Linus Torvalds. RED HAT and JBOSS are registered - trademarks of Red Hat, Inc. in the US and other countries. - - Java, all Java-based trademarks and OpenOffice.org are trademarks of - Sun Microsystems, Inc. in the United States, other countries, or both. - - Other company, product, or service names may be trademarks or service - marks of others. - - Links to full AMQP specification: - ================================= - http://www.envoytech.org/spec/amq/ - http://www.iona.com/opensource/amqp/ - http://www.redhat.com/solutions/specifications/amqp/ - http://www.twiststandards.org/tiki-index.php?page=AMQ - http://www.imatix.com/amqp ---> - -<!-- - <!DOCTYPE amqp SYSTEM "amqp.dtd"> ---> - -<!-- 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 spaces to seperate words in names, so that we can print names in - their natural form depending on the context - underlines for source code, - hyphens for written text, etc. - - 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. - - --> - -<amqp major = "0" minor = "9" port = "5672" comment = "AMQ Protocol version 0-9"> - <!-- - ====================================================== - == CONSTANTS - ====================================================== - --> - <!-- Frame types --> - <constant name = "frame-method" value = "1" /> - <constant name = "frame-header" value = "2" /> - <constant name = "frame-body" value = "3" /> - <constant name = "frame-oob-method" value = "4" /> - <constant name = "frame-oob-header" value = "5" /> - <constant name = "frame-oob-body" value = "6" /> - <constant name = "frame-trace" value = "7" /> - <constant name = "frame-heartbeat" value = "8" /> - - <!-- Protocol constants --> - <constant name = "frame-min-size" value = "4096" /> - <constant name = "frame-end" value = "206" /> - - <!-- Reply codes --> - <constant name = "reply-success" value = "200"> - <doc> - Indicates that the method completed successfully. This reply code is - reserved for future use - the current protocol design does not use positive - confirmation and reply codes are sent only in case of an error. - </doc> - </constant> - - <constant name = "not-delivered" value = "310" class = "soft-error"> - <doc> - The client asked for a specific message that is no longer available. - The message was delivered to another client, or was purged from the queue - for some other reason. - </doc> - </constant> - - <constant name = "content-too-large" value = "311" class = "soft-error"> - <doc> - The client attempted to transfer content larger than the server could accept - at the present time. The client may retry at a later time. - </doc> - </constant> - - <constant name = "no-route" value = "312" class = "soft-error"> - <doc> - When the exchange cannot route the result of a .Publish, most likely due - to an invalid routing key. Only when the mandatory flag is set. - </doc> - </constant> - - <constant name = "no-consumers" value = "313" class = "soft-error"> - <doc> - When the exchange cannot deliver to a consumer when the immediate flag is - set. As a result of pending data on the queue or the absence of any - consumers of the queue. - </doc> - </constant> - - <constant name = "connection-forced" value = "320" class = "hard-error"> - <doc> - An operator intervened to close the connection for some reason. The client - may retry at some later date. - </doc> - </constant> - - <constant name = "invalid-path" value = "402" class = "hard-error"> - <doc> - The client tried to work with an unknown virtual host. - </doc> - </constant> - - <constant name = "access-refused" value = "403" class = "soft-error"> - <doc> - The client attempted to work with a server entity to which it has no - access due to security settings. - </doc> - </constant> - - <constant name = "not-found" value = "404" class = "soft-error"> - <doc>The client attempted to work with a server entity that does not exist.</doc> - </constant> - - <constant name = "resource-locked" value = "405" class = "soft-error"> - <doc> - The client attempted to work with a server entity to which it has no - access because another client is working with it. - </doc> - </constant> - - <constant name = "precondition-failed" value = "406" class = "soft-error"> - <doc> - The client requested a method that was not allowed because some precondition - failed. - </doc> - </constant> - - <constant name = "frame-error" value = "501" class = "hard-error"> - <doc> - The client sent a malformed frame that the server could not decode. This - strongly implies a programming error in the client. - </doc> - </constant> - - <constant name = "syntax-error" value = "502" class = "hard-error"> - <doc> - The client sent a frame that contained illegal values for one or more - fields. This strongly implies a programming error in the client. - </doc> - </constant> - - <constant name = "command-invalid" value = "503" class = "hard-error"> - <doc> - The client sent an invalid sequence of frames, attempting to perform an - operation that was considered invalid by the server. This usually implies - a programming error in the client. - </doc> - </constant> - - <constant name = "channel-error" value = "504" class = "hard-error"> - <doc> - The client attempted to work with a channel that had not been correctly - opened. This most likely indicates a fault in the client layer. - </doc> - </constant> - - <constant name = "resource-error" value = "506" class = "hard-error"> - <doc> - The server could not complete the method because it lacked sufficient - resources. This may be due to the client creating too many of some type - of entity. - </doc> - </constant> - - <constant name = "not-allowed" value = "530" class = "hard-error"> - <doc> - The client tried to work with some entity in a manner that is prohibited - by the server, due to security settings or by some other criteria. - </doc> - </constant> - - <constant name = "not-implemented" value = "540" class = "hard-error"> - <doc> - The client tried to use functionality that is not implemented in the - server. - </doc> - </constant> - - <constant name = "internal-error" value = "541" class = "hard-error"> - <doc> - The server could not complete the method because of an internal error. - The server may require intervention by an operator in order to resume - normal operations. - </doc> - </constant> - - <!-- - ====================================================== - == DOMAIN TYPES - ====================================================== - --> - - <domain name = "access-ticket" type = "short" label = "access ticket granted by server"> - <doc> - An access ticket granted by the server for a certain set of access rights - within a specific realm. Access tickets are valid within the channel where - they were created, and expire when the channel closes. - </doc> - <assert check = "ne" value = "0" /> - </domain> - - <domain name = "class-id" type = "short" /> - - <domain name = "consumer-tag" type = "shortstr" label = "consumer tag"> - <doc> - Identifier for the consumer, valid within the current connection. - </doc> - </domain> - - <domain name = "delivery-tag" type = "longlong" label = "server-assigned delivery tag"> - <doc> - The server-assigned and channel-specific delivery tag - </doc> - <rule name = "channel-local"> - <doc> - The delivery tag is valid only within the channel from which the message was - received. I.e. a client MUST NOT receive a message on one channel and then - acknowledge it on another. - </doc> - </rule> - <rule name = "non-zero"> - <doc> - The server MUST NOT use a zero value for delivery tags. Zero is reserved - for client use, meaning "all messages so far received". - </doc> - </rule> - </domain> - - <domain name = "exchange-name" type = "shortstr" label = "exchange name"> - <doc> - The exchange name is a client-selected string that identifies the exchange for publish - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - </doc> - <assert check = "length" value = "127" /> - </domain> - - <domain name = "known-hosts" type = "shortstr" label = "list of known hosts"> - <doc> - Specifies the list of equivalent or alternative hosts that the server knows about, - which will normally include the current server itself. Clients can cache this - information and use it when reconnecting to a server after a failure. This field - may be empty. - </doc> - </domain> - - <domain name = "method-id" type = "short" /> - - <domain name = "no-ack" type = "bit" label = "no acknowledgement needed"> - <doc> - If this field is set the server does not expect acknowledgements for - messages. That is, when a message is delivered to the client the server - automatically and silently acknowledges it on behalf of the client. This - functionality increases performance but at the cost of reliability. - Messages can get lost if a client dies before it can deliver them to the - application. - </doc> - </domain> - - <domain name = "no-local" type = "bit" label = "do not deliver own messages"> - <doc> - If the no-local field is set the server will not send messages to the connection that - published them. - </doc> - </domain> - - <domain name = "path" type = "shortstr"> - <doc> - Must start with a slash "/" and continue with path names separated by slashes. A path - name consists of any combination of at least one of [A-Za-z0-9] plus zero or more of - [.-_+!=:]. - </doc> - - <assert check = "notnull" /> - <assert check = "syntax" rule = "path" /> - <assert check = "length" value = "127" /> - </domain> - - <domain name = "peer-properties" type = "table"> - <doc> - This string provides a set of peer properties, used for identification, debugging, and - general information. - </doc> - </domain> - - <domain name = "queue-name" type = "shortstr" label = "queue name"> - <doc> - The queue name identifies the queue within the vhost. Queue names may consist of any - mixture of digits, letters, and underscores. - </doc> - <assert check = "length" value = "127" /> - </domain> - - <domain name = "redelivered" type = "bit" label = "message is being redelivered"> - <doc> - This indicates that the message has been previously delivered to this or - another client. - </doc> - <rule name = "implementation"> - <doc> - The server SHOULD try to signal redelivered messages when it can. When - redelivering a message that was not successfully acknowledged, the server - SHOULD deliver it to the original client if possible. - </doc> - <doc type = "scenario"> - Create a shared queue and publish a message to the queue. Consume the - message using explicit acknowledgements, but do not acknowledge the - message. Close the connection, reconnect, and consume from the queue - again. The message should arrive with the redelivered flag set. - </doc> - </rule> - <rule name = "hinting"> - <doc> - The client MUST NOT rely on the redelivered field but should take it as a - hint that the message may already have been processed. A fully robust - client must be able to track duplicate received messages on non-transacted, - and locally-transacted channels. - </doc> - </rule> - </domain> - - <domain name = "reply-code" type = "short" label = "reply code from server"> - <doc> - The reply code. The AMQ reply codes are defined as constants at the start - of this formal specification. - </doc> - <assert check = "notnull" /> - </domain> - - <domain name = "reply-text" type = "shortstr" label = "localised reply text"> - <doc> - The localised reply text. This text can be logged as an aid to resolving - issues. - </doc> - <assert check = "notnull" /> - </domain> - - <domain name = "channel-id" type = "longstr" label = "unique identifier for a channel" /> - - <!-- Domains for the message class --> - <domain name = "duration" type = "longlong" label = "duration in milliseconds" /> - <domain name = "offset" type = "longlong" label = "offset into a message body" /> - <domain name = "reference" type = "longstr" label = "pointer to a message body" /> - <domain name = "destination" type = "shortstr" label = "destination for a message"> - <doc> - Specifies the destination to which the message is to be - transferred. The destination can be empty, meaning the - default exchange or consumer. - </doc> - </domain> - <domain name = "reject-code" type = "short" label = "reject code for transfer"> - <rule name = "01"> - <doc> - The reject code must be one of 0 (generic) or 1 (immediate - delivery was attempted but failed). - </doc> - </rule> - </domain> - <domain name = "reject-text" type = "shortstr" label = "informational text for message reject"/> - <domain name = "security-token" type = "longstr" label = "security token"> - <doc> - Used for authentication, replay prevention, and encrypted bodies. - </doc> - </domain> - - <!-- Elementary domains --> - <domain name = "bit" type = "bit" label = "single bit" /> - <domain name = "octet" type = "octet" label = "single octet" /> - <domain name = "short" type = "short" label = "16-bit integer" /> - <domain name = "long" type = "long" label = "32-bit integer" /> - <domain name = "longlong" type = "longlong" label = "64-bit integer" /> - <domain name = "shortstr" type = "shortstr" label = "short string" /> - <domain name = "longstr" type = "longstr" label = "long string" /> - <domain name = "timestamp" type = "timestamp" label = "64-bit timestamp" /> - <domain name = "table" type = "table" label = "field table" /> - - <!-- == CONNECTION ======================================================= --> - - <!-- TODO 0.81 - the 'handler' attribute of methods needs to be reviewed, and if - no current implementations use it, removed. /PH 2006/07/20 - --> - - <class name = "connection" handler = "connection" index = "10" label = "work with socket connections"> - <doc> - The connection class provides methods for a client to establish a network connection to - a server, and for both peers to operate the connection thereafter. - </doc> - - <doc type = "grammar"> - connection = open-connection *use-connection close-connection - open-connection = C:protocol-header - S:START C:START-OK - *challenge - S:TUNE C:TUNE-OK - C:OPEN S:OPEN-OK | S:REDIRECT - challenge = S:SECURE C:SECURE-OK - use-connection = *channel - close-connection = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "start" synchronous = "1" index = "10" label = "start connection negotiation"> - <doc> - This method starts the connection negotiation process by telling the client the - protocol version that the server proposes, along with a list of security mechanisms - which the client can use for authentication. - </doc> - - <rule name = "protocol-name"> - <doc> - If the server cannot support the protocol specified in the protocol header, - it MUST close the socket connection without sending any response method. - </doc> - <doc type = "scenario"> - The client sends a protocol header containing an invalid protocol name. - The server must respond by closing the connection. - </doc> - </rule> - <rule name = "server-support"> - <doc> - The server MUST provide a protocol version that is lower than or equal to - that requested by the client in the protocol header. - </doc> - <doc type = "scenario"> - The client requests a protocol version that is higher than any valid - implementation, e.g. 9.0. The server must respond with a current - protocol version, e.g. 1.0. - </doc> - </rule> - <rule name = "client-support"> - <doc> - If the client cannot handle the protocol version suggested by the server - it MUST close the socket connection. - </doc> - <doc type = "scenario"> - The server sends a protocol version that is lower than any valid - implementation, e.g. 0.1. The client must respond by closing the - connection. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - <response name = "start-ok" /> - - <field name = "version-major" domain = "octet" label = "protocol major version"> - <doc> - The protocol version, major component, as transmitted in the AMQP protocol - header. This, combined with the protocol minor component fully describe the - protocol version, which is written in the format major-minor. Hence, with - major=1, minor=3, the protocol version would be "1-3". - </doc> - </field> - - <field name = "version-minor" domain = "octet" label = "protocol minor version"> - <doc> - The protocol version, minor component, as transmitted in the AMQP protocol - header. This, combined with the protocol major component fully describe the - protocol version, which is written in the format major-minor. Hence, with - major=1, minor=3, the protocol version would be "1-3". - </doc> - </field> - - <field name = "server-properties" domain = "peer-properties" label = "server properties"> - <rule name = "required-fields"> - <doc> - The properties SHOULD contain at least these fields: "host", specifying the - server host name or address, "product", giving the name of the server product, - "version", giving the name of the server version, "platform", giving the name - of the operating system, "copyright", if appropriate, and "information", giving - other general information. - </doc> - <doc type = "scenario"> - Client connects to server and inspects the server properties. It checks for - the presence of the required fields. - </doc> - </rule> - </field> - - <field name = "mechanisms" domain = "longstr" label = "available security mechanisms"> - <doc> - A list of the security mechanisms that the server supports, delimited by spaces. - </doc> - <assert check = "notnull" /> - </field> - - <field name = "locales" domain = "longstr" label = "available message locales"> - <doc> - A list of the message locales that the server supports, delimited by spaces. The - locale defines the language in which the server will send reply texts. - </doc> - <rule name = "required-support"> - <doc> - The server MUST support at least the en_US locale. - </doc> - <doc type = "scenario"> - Client connects to server and inspects the locales field. It checks for - the presence of the required locale(s). - </doc> - </rule> - <assert check = "notnull" /> - </field> - </method> - - <method name = "start-ok" synchronous = "1" index = "11" - label = "select security mechanism and locale"> - <doc> - This method selects a SASL security mechanism. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "client-properties" domain = "peer-properties" label = "client properties"> - <rule name = "required-fields"> - <!-- This rule is not testable from the client side --> - <doc> - The properties SHOULD contain at least these fields: "product", giving the name - of the client product, "version", giving the name of the client version, "platform", - giving the name of the operating system, "copyright", if appropriate, and - "information", giving other general information. - </doc> - </rule> - </field> - - <field name = "mechanism" domain = "shortstr" label = "selected security mechanism"> - <doc> - A single security mechanisms selected by the client, which must be one of those - specified by the server. - </doc> - <rule name = "security"> - <doc> - The client SHOULD authenticate using the highest-level security profile it - can handle from the list provided by the server. - </doc> - </rule> - <rule name = "validity"> - <doc> - If the mechanism field does not contain one of the security mechanisms - proposed by the server in the Start method, the server MUST close the - connection without sending any further data. - </doc> - <doc type = "scenario"> - Client connects to server and sends an invalid security mechanism. The - server must respond by closing the connection (a socket close, with no - connection close negotiation). - </doc> - </rule> - <assert check = "notnull" /> - </field> - - <field name = "response" domain = "longstr" label = "security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this - data are defined by the SASL security mechanism. - </doc> - <assert check = "notnull" /> - </field> - - <field name = "locale" domain = "shortstr" label = "selected message locale"> - <doc> - A single message locale selected by the client, which must be one of those - specified by the server. - </doc> - <assert check = "notnull" /> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "secure" synchronous = "1" index = "20" label = "security mechanism challenge"> - <doc> - The SASL protocol works by exchanging challenges and responses until both peers have - received sufficient information to authenticate each other. This method challenges - the client to provide more information. - </doc> - - <chassis name = "client" implement = "MUST" /> - <response name = "secure-ok" /> - - <field name = "challenge" domain = "longstr" label = "security challenge data"> - <doc> - Challenge information, a block of opaque binary data passed to the security - mechanism. - </doc> - </field> - </method> - - <method name = "secure-ok" synchronous = "1" index = "21" label = "security mechanism response"> - <doc> - This method attempts to authenticate, passing a block of SASL data for the security - mechanism at the server side. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "response" domain = "longstr" label = "security response data"> - <doc> - A block of opaque data passed to the security mechanism. The contents of this - data are defined by the SASL security mechanism. - </doc> - <assert check = "notnull" /> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "tune" synchronous = "1" index = "30" - label = "propose connection tuning parameters"> - <doc> - This method proposes a set of connection configuration values to the client. The - client can accept and/or adjust these. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <response name = "tune-ok" /> - - <field name = "channel-max" domain = "short" label = "proposed maximum channels"> - <doc> - The maximum total number of channels that the server allows per connection. Zero - means that the server does not impose a fixed limit, but the number of allowed - channels may be limited by available server resources. - </doc> - </field> - - <field name = "frame-max" domain = "long" label = "proposed maximum frame size"> - <doc> - The largest frame size that the server proposes for the connection. The client - can negotiate a lower value. Zero means that the server does not impose any - specific limit but may reject very large frames if it cannot allocate resources - for them. - </doc> - <rule name = "minimum"> - <doc> - Until the frame-max has been negotiated, both peers MUST accept frames of up - to frame-min-size octets large, and the minimum negotiated value for frame-max - is also frame-min-size. - </doc> - <doc type = "scenario"> - Client connects to server and sends a large properties field, creating a frame - of frame-min-size octets. The server must accept this frame. - </doc> - </rule> - </field> - - <field name = "heartbeat" domain = "short" label = "desired heartbeat delay"> - <!-- TODO 0.82 - the heartbeat negotiation mechanism was changed during - implementation because the model documented here does not actually - work properly. The best model we found is that the server proposes - a heartbeat value to the client; the client can reply with zero, meaning - 'do not use heartbeats (as documented here), or can propose its own - heartbeat value, which the server should then accept. This is different - from the model here which is disconnected - e.g. each side requests a - heartbeat independently. Basically a connection is heartbeated in - both ways, or not at all, depending on whether both peers support - heartbeating or not, and the heartbeat value should itself be chosen - by the client so that remote links can get a higher value. Also, the - actual heartbeat mechanism needs documentation, and is as follows: so - long as there is activity on a connection - in or out - both peers - assume the connection is active. When there is no activity, each peer - must send heartbeat frames. When no heartbeat frame is received after - N cycles (where N is at least 2), the connection can be considered to - have died. /PH 2006/07/19 - --> - <doc> - The delay, in seconds, of the connection heartbeat that the server wants. - Zero means the server does not want a heartbeat. - </doc> - </field> - </method> - - <method name = "tune-ok" synchronous = "1" index = "31" - label = "negotiate connection tuning parameters"> - <doc> - This method sends the client's connection tuning parameters to the server. - Certain fields are negotiated, others provide capability information. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "channel-max" domain = "short" label = "negotiated maximum channels"> - <doc> - The maximum total number of channels that the client will use per connection. - </doc> - <rule name = "upper-limit"> - <doc> - If the client specifies a channel max that is higher than the value provided - by the server, the server MUST close the connection without attempting a - negotiated close. The server may report the error in some fashion to assist - implementors. - </doc> - </rule> - <assert check = "notnull" /> - <assert check = "le" method = "tune" field = "channel-max" /> - </field> - - <field name = "frame-max" domain = "long" label = "negotiated maximum frame size"> - <doc> - The largest frame size that the client and server will use for the connection. - Zero means that the client does not impose any specific limit but may reject - very large frames if it cannot allocate resources for them. Note that the - frame-max limit applies principally to content frames, where large contents can - be broken into frames of arbitrary size. - </doc> - <rule name = "minimum"> - <doc> - Until the frame-max has been negotiated, both peers MUST accept frames of up - to frame-min-size octets large, and the minimum negotiated value for frame-max - is also frame-min-size. - </doc> - </rule> - <rule name = "upper-limit"> - <doc> - If the client specifies a frame max that is higher than the value provided - by the server, the server MUST close the connection without attempting a - negotiated close. The server may report the error in some fashion to assist - implementors. - </doc> - </rule> - </field> - - <field name = "heartbeat" domain = "short" label = "desired heartbeat delay"> - <doc> - The delay, in seconds, of the connection heartbeat that the client wants. Zero - means the client does not want a heartbeat. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" synchronous = "1" index = "40" label = "open connection to virtual host"> - <doc> - This method opens a connection to a virtual host, which is a collection of - resources, and acts to separate multiple application domains within a server. - The server may apply arbitrary limits per virtual host, such as the number - of each type of entity that may be used, per connection and/or in total. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "open-ok" /> - <response name = "redirect" /> - - <field name = "virtual-host" domain = "path" label = "virtual host name"> - <!-- TODO 0.82 - the entire vhost model needs review. This concept was - prompted by the HTTP vhost concept but does not fit very well into - AMQP. Currently we use the vhost as a "cluster identifier" which is - inaccurate usage. /PH 2006/07/19 - --> - <assert check = "regexp" value = "^[a-zA-Z0-9/-_]+$" /> - <doc> - The name of the virtual host to work with. - </doc> - <rule name = "separation"> - <doc> - If the server supports multiple virtual hosts, it MUST enforce a full - separation of exchanges, queues, and all associated entities per virtual - host. An application, connected to a specific virtual host, MUST NOT be able - to access resources of another virtual host. - </doc> - </rule> - <rule name = "security"> - <doc> - The server SHOULD verify that the client has permission to access the - specified virtual host. - </doc> - </rule> - </field> - - <field name = "capabilities" domain = "shortstr" label = "required capabilities"> - <doc> - The client can specify zero or more capability names, delimited by spaces. - The server can use this string to how to process the client's connection - request. - </doc> - </field> - - <field name = "insist" domain = "bit" label = "insist on connecting to server"> - <doc> - In a configuration with multiple collaborating servers, the server may respond - to a Connection.Open method with a Connection.Redirect. The insist option tells - the server that the client is insisting on a connection to the specified server. - </doc> - <rule name = "behaviour"> - <doc> - When the client uses the insist option, the server MUST NOT respond with a - Connection.Redirect method. If it cannot accept the client's connection - request it should respond by closing the connection with a suitable reply - code. - </doc> - </rule> - </field> - </method> - - <method name = "open-ok" synchronous = "1" index = "41" label = "signal that connection is ready"> - <doc> - This method signals to the client that the connection is ready for use. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "known-hosts" domain = "known-hosts" /> - </method> - - <method name = "redirect" synchronous = "1" index = "42" label = "redirects client to other server"> - <doc> - This method redirects the client to another server, based on the requested virtual - host and/or capabilities. - </doc> - <rule name = "usage"> - <doc> - When getting the Connection.Redirect method, the client SHOULD reconnect to - the host specified, and if that host is not present, to any of the hosts - specified in the known-hosts list. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <field name = "host" domain = "shortstr" label = "server to connect to"> - <doc> - Specifies the server to connect to. This is an IP address or a DNS name, - optionally followed by a colon and a port number. If no port number is - specified, the client should use the default port number for the protocol. - </doc> - <assert check = "notnull" /> - </field> - <field name = "known-hosts" domain = "known-hosts" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "close" synchronous = "1" index = "50" label = "request a connection close"> - <doc> - This method indicates that the sender wants to close the connection. This may be - due to internal conditions (e.g. a forced shut-down) or due to an error handling - a specific method, i.e. an exception. When a close is due to an exception, the - sender provides the class and method id of the method which caused the exception. - </doc> - <!-- TODO: the connection close mechanism needs to be reviewed from the ODF - documentation and better expressed as rules here. /PH 2006/07/20 - --> - <rule name = "stability"> - <doc> - After sending this method any received method except the Close-OK method MUST - be discarded. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - <response name = "close-ok" /> - - <field name = "reply-code" domain = "reply-code" /> - <field name = "reply-text" domain = "reply-text" /> - - <field name = "class-id" domain = "class-id" label = "failing method class"> - <doc> - When the close is provoked by a method exception, this is the class of the - method. - </doc> - </field> - - <field name = "method-id" domain = "method-id" label = "failing method ID"> - <doc> - When the close is provoked by a method exception, this is the ID of the method. - </doc> - </field> - </method> - - <method name = "close-ok" synchronous = "1" index = "51" label = "confirm a connection close"> - <doc> - This method confirms a Connection.Close method and tells the recipient that it is - safe to release resources for the connection and close the socket. - </doc> - <rule name = "reporting"> - <doc> - A peer that detects a socket closure without having received a Close-Ok - handshake method SHOULD log the error. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - </method> - </class> - - <!-- == CHANNEL ========================================================== --> - - <class name = "channel" handler = "channel" index = "20" label = "work with channels"> - <doc> - The channel class provides methods for a client to establish a channel to a - server and for both peers to operate the channel thereafter. - </doc> - - <doc type = "grammar"> - channel = open-channel *use-channel close-channel - open-channel = C:OPEN S:OPEN-OK - / C:RESUME S:OK - use-channel = C:FLOW S:FLOW-OK - / S:FLOW C:FLOW-OK - / S:PING C:OK - / C:PONG S:OK - / C:PING S:OK - / S:PONG C:OK - / functional-class - close-channel = C:CLOSE S:CLOSE-OK - / S:CLOSE C:CLOSE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" synchronous = "1" index = "10" label = "open a channel for use"> - <doc> - This method opens a channel to the server. - </doc> - <rule name = "state" on-failure = "channel-error"> - <doc> - The client MUST NOT use this method on an already-opened channel. - </doc> - <doc type = "scenario"> - Client opens a channel and then reopens the same channel. - </doc> - </rule> - <chassis name = "server" implement = "MUST" /> - <response name = "open-ok" /> - <field name = "out-of-band" domain = "shortstr" label = "out-of-band settings"> - <doc> - Configures out-of-band transfers on this channel. The syntax and meaning of this - field will be formally defined at a later date. - </doc> - <assert check = "null" /> - </field> - </method> - - <method name = "open-ok" synchronous = "1" index = "11" label = "signal that the channel is ready"> - <doc> - This method signals to the client that the channel is ready for use. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "channel-id" domain = "channel-id" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "flow" synchronous = "1" index = "20" label = "enable/disable flow from peer"> - <doc> - This method asks the peer to pause or restart the flow of content data. This is a - simple flow-control mechanism that a peer can use to avoid overflowing its queues or - otherwise finding itself receiving more messages than it can process. Note that this - method is not intended for window control. The peer that receives a disable flow - method should finish sending the current content frame, if any, then pause. - </doc> - - <rule name = "initial-state"> - <doc> - When a new channel is opened, it is active (flow is active). Some applications - assume that channels are inactive until started. To emulate this behaviour a - client MAY open the channel, then pause it. - </doc> - </rule> - - <rule name = "bidirectional"> - <doc> - When sending content frames, a peer SHOULD monitor the channel for incoming - methods and respond to a Channel.Flow as rapidly as possible. - </doc> - </rule> - - <rule name = "throttling"> - <doc> - A peer MAY use the Channel.Flow method to throttle incoming content data for - internal reasons, for example, when exchanging data over a slower connection. - </doc> - </rule> - - <rule name = "expected-behaviour"> - <doc> - The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer - that does not respect the request. This is to prevent badly-behaved clients - from overwhelming a broker. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <response name = "flow-ok" /> - - <field name = "active" domain = "bit" label = "start/stop content frames"> - <doc> - If 1, the peer starts sending content frames. If 0, the peer stops sending - content frames. - </doc> - </field> - </method> - - <method name = "flow-ok" index = "21" label = "confirm a flow method"> - <doc> - Confirms to the peer that a flow command was received and processed. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <field name = "active" domain = "bit" label = "current flow setting"> - <doc> - Confirms the setting of the processed flow method: 1 means the peer will start - sending or continue to send content frames; 0 means it will not. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "close" synchronous = "1" index = "40" label = "request a channel close"> - <doc> - This method indicates that the sender wants to close the channel. This may be due to - internal conditions (e.g. a forced shut-down) or due to an error handling a specific - method, i.e. an exception. When a close is due to an exception, the sender provides - the class and method id of the method which caused the exception. - </doc> - - <!-- TODO: the channel close behaviour needs to be reviewed from the ODF - documentation and better expressed as rules here. /PH 2006/07/20 - --> - <rule name = "stability"> - <doc> - After sending this method any received method except the Close-OK method MUST - be discarded. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - <response name = "close-ok" /> - - <field name = "reply-code" domain = "reply-code" /> - <field name = "reply-text" domain = "reply-text" /> - - <field name = "class-id" domain = "class-id" label = "failing method class"> - <doc> - When the close is provoked by a method exception, this is the class of the - method. - </doc> - </field> - - <field name = "method-id" domain = "method-id" label = "failing method ID"> - <doc> - When the close is provoked by a method exception, this is the ID of the method. - </doc> - </field> - </method> - - <method name = "close-ok" synchronous = "1" index = "41" label = "confirm a channel close"> - <doc> - This method confirms a Channel.Close method and tells the recipient that it is safe - to release resources for the channel. - </doc> - <rule name = "reporting"> - <doc> - A peer that detects a socket closure without having received a Channel.Close-Ok - handshake method SHOULD log the error. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <chassis name = "server" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "resume" index = "50" label = "resume an interrupted channel"> - <doc> - This method resume a previously interrupted channel. - </doc> - <response name = "ok" /> - <chassis name = "server" implement = "MAY" /> - <field name = "channel-id" domain = "channel-id" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "ping" index = "60" label = "[WORK IN PROGRESS] initiates a pong"> - <doc> - [WORK IN PROGRESS] Request that the recipient issue a pong request. - </doc> - <response name = "ok" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "pong" index = "70" label = "[WORK IN PROGRESS] issued after receiving a ping"> - <doc> - [WORK IN PROGRESS] Issued after a ping request is received. Note that this is a - request issued after receiving a ping, not a response to - receiving a ping. - </doc> - <response name = "ok" /> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "ok" index = "80" label = "[WORK IN PROGRESS] signals normal completion"> - <doc> - [WORK IN PROGRESS] Signals normal completion of a method. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - </class> - - <!-- == ACCESS =========================================================== --> - - <!-- TODO 0.82 - this class must be implemented by two teams before we can - consider it matured. - --> - - <class name = "access" handler = "connection" index = "30" label = "work with access tickets"> - <doc> - The protocol control access to server resources using access tickets. A - client must explicitly request access tickets before doing work. An access - ticket grants a client the right to use a specific set of resources - - called a "realm" - in specific ways. - </doc> - - <doc type = "grammar"> - access = C:REQUEST S:REQUEST-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "request" synchronous = "1" index = "10" label = "request an access ticket"> - <doc> - This method requests an access ticket for an access realm. The server - responds by granting the access ticket. If the client does not have - access rights to the requested realm this causes a connection exception. - Access tickets are a per-channel resource. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "request-ok" /> - - <field name = "realm" domain = "shortstr" label = "name of requested realm"> - <doc> - Specifies the name of the realm to which the client is requesting access. - The realm is a configured server-side object that collects a set of - resources (exchanges, queues, etc.). If the channel has already requested - an access ticket onto this realm, the previous ticket is destroyed and a - new ticket is created with the requested access rights, if allowed. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST specify a realm that is known to the server. The server - makes an identical response for undefined realms as it does for realms - that are defined but inaccessible to this client. - </doc> - <doc type = "scenario"> - Client specifies an undefined realm. - </doc> - </rule> - </field> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive access to the realm, meaning that this will be the only - channel that uses the realm's resources. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MAY NOT request exclusive access to a realm that has active - access tickets, unless the same channel already had the only access - ticket onto that realm. - </doc> - <doc type = "scenario"> - Client opens two channels and requests exclusive access to the same realm. - </doc> - </rule> - </field> - <field name = "passive" domain = "bit" label = "request passive access"> - <doc> - Request message passive access to the specified access realm. Passive - access lets a client get information about resources in the realm but - not to make any changes to them. - </doc> - </field> - <field name = "active" domain = "bit" label = "request active access"> - <doc> - Request message active access to the specified access realm. Active access lets - a client get create and delete resources in the realm. - </doc> - </field> - <field name = "write" domain = "bit" label = "request write access"> - <doc> - Request write access to the specified access realm. Write access lets a client - publish messages to all exchanges in the realm. - </doc> - </field> - <field name = "read" domain = "bit" label = "request read access"> - <doc> - Request read access to the specified access realm. Read access lets a client - consume messages from queues in the realm. - </doc> - </field> - </method> - - <method name = "request-ok" synchronous = "1" index = "11" label = "grant access to server resources"> - <doc> - This method provides the client with an access ticket. The access ticket is valid - within the current channel and for the lifespan of the channel. - </doc> - <rule name = "per-channel" on-failure = "not-allowed"> - <doc> - The client MUST NOT use access tickets except within the same channel as - originally granted. - </doc> - <doc type = "scenario"> - Client opens two channels, requests a ticket on one channel, and then - tries to use that ticket in a second channel. - </doc> - </rule> - <chassis name = "client" implement = "MUST" /> - <field name = "ticket" domain = "access-ticket" /> - </method> - </class> - - <!-- == EXCHANGE ========================================================= --> - - <class name = "exchange" handler = "channel" index = "40" label = "work with exchanges"> - <doc> - Exchanges match and distribute messages across queues. Exchanges can be configured in - the server or created at runtime. - </doc> - - <doc type = "grammar"> - exchange = C:DECLARE S:DECLARE-OK - / C:DELETE S:DELETE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <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. - </doc> - <doc> - The server MUST, in each virtual host, pre-declare at least two direct - exchange instances: one named "amq.direct", the other with no public name - that serves as a default exchange for Publish methods. - </doc> - <doc type = "scenario"> - Client creates a temporary queue and attempts to bind to each required - exchange instance ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers" - if those types are defined). - </doc> - </rule> - <rule name = "default-exchange"> - <doc> - The server MUST pre-declare a direct exchange with no public name to act as - the default exchange for content Publish methods and for default queue bindings. - </doc> - <doc type = "scenario"> - Client checks that the default exchange is active by specifying a queue - binding with no exchange name, and 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 server MUST NOT allow clients to access the default exchange except - by specifying an empty exchange name in the Queue.Bind and content Publish - methods. - </doc> - </rule> - <rule name = "extensions"> - <doc> - The server MAY implement other exchange types as wanted. - </doc> - </rule> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "declare" synchronous = "1" index = "10" label = "verify exchange exists, create if needed"> - <doc> - This method creates an exchange if it does not already exist, and if the exchange - exists, verifies that it is of the correct and expected class. - </doc> - <rule name = "minimum"> - <doc> - The server SHOULD support a minimum of 16 exchanges per virtual host and - ideally, impose no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - The client creates as many exchanges as it can until the server reports - an error; the number of exchanges successfully created must be at least - sixteen. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "declare-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - When a client defines a new exchange, this belongs to the access realm of the - ticket used. All further work done with that exchange must be done with an - access ticket for the same realm. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access to - the realm in which the exchange exists or will be created, or "passive" - access if the if-exists flag is set. - </doc> - <doc type = "scenario"> - Client creates access ticket with wrong access rights and attempts to use - in this method. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <rule name = "reserved" on-failure = "access-refused"> - <doc> - Exchange names starting with "amq." are reserved for pre-declared and - standardised exchanges. The client MUST NOT attempt to create an exchange - starting with "amq.". - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <assert check = "regexp" value = "^[a-zA-Z0-9-_.:]+$" /> - </field> - - <field name = "type" domain = "shortstr" label = "exchange type"> - <doc> - Each exchange belongs to one of a set of exchange types implemented by the - server. The exchange types define the functionality of the exchange - i.e. how - messages are routed through it. It is not valid or meaningful to attempt to - change the type of an existing exchange. - </doc> - <rule name = "typed" on-failure = "not-allowed"> - <doc> - Exchanges cannot be redeclared with different types. The client MUST not - attempt to redeclare an existing exchange with a different type than used - in the original Exchange.Declare method. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <rule name = "support" on-failure = "command-invalid"> - <doc> - The client MUST NOT attempt to create an exchange with a type that the - server does not support. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <assert check = "regexp" value = "^[a-zA-Z0-9-_.:]+$" /> - </field> - - <field name = "passive" domain = "bit" label = "do not create exchange"> - <doc> - If set, the server will not create the exchange. The client can use this to - check whether an exchange exists without modifying the server state. - </doc> - <rule name = "not-found"> - <doc> - If set, and the exchange does not already exist, the server MUST raise a - channel exception with reply code 404 (not found). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "durable" domain = "bit" label = "request a durable exchange"> - <doc> - If set when creating a new exchange, the exchange will be marked as durable. - Durable exchanges remain active when a server restarts. Non-durable exchanges - (transient exchanges) are purged if/when a server restarts. - </doc> - <rule name = "support"> - <doc> - The server MUST support both durable and transient exchanges. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - <rule name = "sticky"> - <doc> - The server MUST ignore the durable field if the exchange already exists. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <!-- TODO 0.82 - clarify how this works; there is no way to cancel a binding - except by deleting a queue. - --> - <field name = "auto-delete" domain = "bit" label = "auto-delete when unused"> - <doc> - If set, the exchange is deleted when all queues have finished using it. - </doc> - <rule name = "sticky"> - <doc> - The server MUST ignore the auto-delete field if the exchange already - exists. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "internal" domain = "bit" label = "create internal exchange"> - <doc> - If set, the exchange may not be used directly by publishers, but only when bound - to other exchanges. Internal exchanges are used to construct wiring that is not - visible to applications. - </doc> - </field> - - <field name = "nowait" domain = "bit" label = "do not send reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these - arguments depends on the server implementation. This field is ignored if passive - is 1. - </doc> - </field> - </method> - - <method name = "declare-ok" synchronous = "1" index = "11" label = "confirm exchange declaration"> - <doc> - This method confirms a Declare method and confirms the name of the exchange, - essential for automatically-named exchanges. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "delete" synchronous = "1" index = "20" label = "delete an exchange"> - <doc> - This method deletes an exchange. When an exchange is deleted all queue bindings on - the exchange are cancelled. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "delete-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access - rights to the exchange's access realm. - </doc> - <doc type = "scenario"> - Client creates access ticket with wrong access rights and attempts to use - in this method. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <rule name = "exists" on-failure = "not-found"> - <doc> - The client MUST NOT attempt to delete an exchange that does not exist. - </doc> - </rule> - <assert check = "notnull" /> - </field> - - <!-- TODO 0.82 - discuss whether this option is useful or not. I don't have - any real use case for it. /PH 2006-07-23. - --> - <field name = "if-unused" domain = "bit" label = "delete only if unused"> - <doc> - If set, the server will only delete the exchange if it has no queue bindings. If - the exchange has queue bindings the server does not delete it but raises a - channel exception instead. - </doc> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "delete-ok" synchronous = "1" index = "21" - label = "confirm deletion of an exchange"> - <doc>This method confirms the deletion of an exchange.</doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- RG : Added Exchange.bound and Exchange.bound-ok --> - <method name="bound" synchronous="1" index="22"> - <chassis name="server" implement="SHOULD"/> - <response name="bound-ok"/> - <field name="exchange" domain="exchange-name"/> - <field name = "routing-key" type = "shortstr"> - Message routing key - <doc> - Specifies the routing key for the message. The routing key is - used for routing messages depending on the exchange configuration. - </doc> - </field> - <field name = "queue" domain = "queue name"/> - </method> - - <method name="bound-ok" synchronous="1" index="23"> - <field name="reply-code" domain="reply-code"/> - <field name="reply-text" domain="reply-text"/> - <chassis name="client" implement="SHOULD"/> - </method> - - </class> - - <!-- == QUEUE ============================================================ --> - - <class name = "queue" handler = "channel" index = "50" label = "work with queues"> - <doc> - Queues store and forward messages. Queues can be configured in the server or created at - runtime. Queues must be attached to at least one exchange in order to receive messages - from publishers. - </doc> - - <doc type = "grammar"> - queue = C:DECLARE S:DECLARE-OK - / C:BIND S:BIND-OK - / C:PURGE S:PURGE-OK - / C:DELETE S:DELETE-OK - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <rule name = "any-content"> - <doc> - A server MUST allow any content class to be sent to any queue, in any mix, and - queue and deliver these content classes independently. Note that all methods - that fetch content off queues are specific to a given content class. - </doc> - <doc type = "scenario"> - Client creates an exchange of each standard type and several queues that - it binds to each exchange. It must then successfully send each of the standard - content types to each of the available queues. - </doc> - </rule> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "declare" synchronous = "1" index = "10" label = "declare queue, create if needed"> - <doc> - This method creates or checks a queue. When creating a new queue the client can - specify various properties that control the durability of the queue and its - contents, and the level of sharing for the queue. - </doc> - - <rule name = "default-binding"> - <doc> - The server MUST create a default binding for a newly-created queue to the - default exchange, which is an exchange of type 'direct' and use the queue - name as the routing key. - </doc> - <doc type = "scenario"> - Client creates a new queue, and then without explicitly binding it to an - exchange, attempts to send a message through the default exchange binding, - i.e. publish a message to the empty exchange, with the queue name as routing - key. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_35" --> - <rule name = "minimum-queues"> - <doc> - The server SHOULD support a minimum of 256 queues per virtual host and ideally, - impose no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - Client attempts to create as many queues as it can until the server reports - an error. The resulting count must at least be 256. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "declare-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - When a client defines a new queue, this belongs to the access realm of the - ticket used. All further work done with that queue must be done with an access - ticket for the same realm. - </doc> - <rule name = "validity" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "active" access to - the realm in which the queue exists or will be created. - </doc> - <doc type = "scenario"> - Client creates access ticket with wrong access rights and attempts to use - in this method. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <rule name = "default-name"> - <doc> - The queue name MAY be empty, in which case the server MUST create a new - queue with a unique generated name and return this to the client in the - Declare-Ok method. - </doc> - <doc type = "scenario"> - Client attempts to create several queues with an empty name. The client then - verifies that the server-assigned names are unique and different. - </doc> - </rule> - <rule name = "reserved-prefix" on-failure = "not-allowed"> - <doc> - Queue names starting with "amq." are reserved for pre-declared and - standardised server queues. A client MAY NOT attempt to declare a queue with a - name that starts with "amq." and the passive option set to zero. - </doc> - <doc type = "scenario"> - A client attempts to create a queue with a name starting with "amq." and with - the passive option set to zero. - </doc> - </rule> - <assert check = "regexp" value = "^[a-zA-Z0-9-_.:]*$" /> - </field> - - <field name = "passive" domain = "bit" label = "do not create queue"> - <doc> - If set, the server will not create the queue. This field allows the client - to assert the presence of a queue without modifying the server state. - </doc> - <rule name = "passive" on-failure = "not-found"> - <doc> - The client MAY ask the server to assert that a queue exists without - creating the queue if not. If the queue does not exist, the server - treats this as a failure. - </doc> - <doc type = "scenario"> - Client declares an existing queue with the passive option and expects - the server to respond with a declare-ok. Client then attempts to declare - a non-existent queue with the passive option, and the server must close - the channel with the correct reply-code. - </doc> - </rule> - </field> - - <field name = "durable" domain = "bit" label = "request a durable queue"> - <doc> - If set when creating a new queue, the queue will be marked as durable. Durable - queues remain active when a server restarts. Non-durable queues (transient - queues) are purged if/when a server restarts. Note that durable queues do not - necessarily hold persistent messages, although it does not make sense to send - persistent messages to a transient queue. - </doc> - <!-- Rule test name: was "amq_queue_03" --> - <rule name = "persistence"> - <doc>The server MUST recreate the durable queue after a restart.</doc> - - <!-- TODO: use 'client does something' rather than 'a client does something'. --> - <doc type = "scenario"> - A client creates a durable queue. The server is then restarted. The client - then attempts to send a message to the queue. The message should be successfully - delivered. - </doc> - </rule> - <!-- Rule test name: was "amq_queue_36" --> - <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 test name: was "amq_queue_37" --> - <rule name = "pre-existence"> - <doc>The server MUST ignore the durable field if the queue already exists.</doc> - <doc type = "scenario"> - A client creates two named queues, one durable and one transient. The client - then attempts to declare the two queues using the same names again, but reversing - the value of the durable flag in each case. Verify that the queues still exist - with the original durable flag values. - <!-- TODO: but how? --> - </doc> - </rule> - </field> - - <field name = "exclusive" domain = "bit" label = "request an exclusive queue"> - <doc> - Exclusive queues may only be consumed from by the current connection. Setting - the 'exclusive' flag always implies 'auto-delete'. - </doc> - - <!-- Rule test name: was "amq_queue_38" --> - <rule name = "types"> - <doc> - The server MUST support both exclusive (private) and non-exclusive (shared) - queues. - </doc> - <doc type = "scenario"> - A client creates two named queues, one exclusive and one non-exclusive. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_04" --> - <rule name = "02" on-failure = "channel-error"> - <doc> - The client MAY NOT attempt to declare any existing and exclusive queue - on multiple connections. - </doc> - <doc type = "scenario"> - A client declares an exclusive named queue. A second client on a different - connection attempts to declare a queue of the same name. - </doc> - </rule> - </field> - - <field name = "auto-delete" domain = "bit" label = "auto-delete queue when unused"> - <doc> - If set, the queue is deleted when all consumers have finished using it. Last - consumer can be cancelled either explicitly or because its channel is closed. If - there was no consumer ever on the queue, it won't be deleted. - </doc> - - <!-- Rule test name: was "amq_queue_31" --> - <rule name = "pre-existence"> - <doc> - The server MUST ignore the auto-delete field if the queue already exists. - </doc> - <doc type = "scenario"> - A client creates two named queues, one as auto-delete and one explicit-delete. - The client then attempts to declare the two queues using the same names again, - but reversing the value of the auto-delete field in each case. Verify that the - queues still exist with the original auto-delete flag values. - <!-- TODO: but how? --> - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments for declaration"> - <doc> - A set of arguments for the declaration. The syntax and semantics of these - arguments depends on the server implementation. This field is ignored if passive - is 1. - </doc> - </field> - </method> - - <method name = "declare-ok" synchronous = "1" index = "11" label = "confirms a queue definition"> - <doc> - This method confirms a Declare method and confirms the name of the queue, essential - for automatically-named queues. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "queue" domain = "queue-name"> - <doc> - Reports the name of the queue. If the server generated a queue name, this field - contains that name. - </doc> - <assert check = "notnull" /> - </field> - - <field name = "message-count" domain = "long" label = "number of messages in queue"> - <doc> - Reports the number of messages in the queue, which will be zero for - newly-created queues. - </doc> - </field> - - <field name = "consumer-count" domain = "long" label = "number of consumers"> - <doc> - Reports the number of active consumers for the queue. Note that consumers can - suspend activity (Channel.Flow) in which case they do not appear in this count. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "bind" synchronous = "1" index = "20" label = "bind queue to an exchange"> - <doc> - This method binds a queue to an exchange. Until a queue is bound it will not receive - any messages. In a classic messaging model, store-and-forward queues are bound to a - direct exchange and subscription queues are bound to a topic exchange. - </doc> - - <!-- Rule test name: was "amq_queue_25" --> - <rule name = "duplicates"> - <doc> - A server MUST allow ignore duplicate bindings - that is, two or more bind - methods for a specific queue, with identical arguments - without treating these - as an error. - </doc> - <doc type = "scenario"> - A client binds a named queue to an exchange. The client then repeats the bind - (with identical arguments). - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_39" --> - <rule name = "failure"> - <!-- - TODO: Find correct on-failure code. The on-failure code returned should depend on why the bind - failed. Assuming that failures owing to bad parameters are covered in the rules relating - to those parameters, the only remaining reason for a failure would be the lack of - server resorces or some internal error - such as too many queues open. Would these - cases qualify as "resource error" 506 or "internal error" 541? - --> - <doc>If a bind fails, the server MUST raise a connection exception.</doc> - <doc type = "scenario"> - TODO - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_12" --> - <rule name = "transient-exchange" on-failure = "not-allowed"> - <doc> - The server MUST NOT allow a durable queue to bind to a transient exchange. - </doc> - <doc type = "scenario"> - A client creates a transient exchange. The client then declares a named durable - queue and then attempts to bind the transient exchange to the durable queue. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_13" --> - <rule name = "durable-exchange"> - <doc> - Bindings for durable queues are automatically durable and the server SHOULD - restore such bindings after a server restart. - </doc> - <doc type = "scenario"> - A server creates a named durable queue and binds it to a durable exchange. The - server is restarted. The client then attempts to use the queue/exchange combination. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_17" --> - <rule name = "internal-exchange"> - <doc> - If the client attempts to bind to an exchange that was declared as internal, the server - MUST raise a connection exception with reply code 530 (not allowed). - </doc> - <doc type = "scenario"> - A client attempts to bind a named queue to an internal exchange. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_40" --> - <rule name = "binding-count"> - <doc> - The server SHOULD support at least 4 bindings per queue, and ideally, impose no - limit except as defined by available resources. - </doc> - <doc type = "scenario"> - A client creates a named queue and attempts to bind it to 4 different non-internal - exchanges. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "bind-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - The client provides a valid access ticket giving "active" access rights to the - queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to bind. If the queue name is empty, refers to - the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "empty-queue" on-failure = "not-allowed"> - <doc> - A client MUST NOT be allowed to bind a non-existent and unnamed queue (i.e. - empty queue name) to an exchange. - </doc> - <doc type = "scenario"> - A client attempts to bind with an unnamed (empty) queue name to an exchange. - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_26" --> - <rule name = "queue-existence" on-failure = "not-found"> - <doc> - A client MUST NOT be allowed to bind a non-existent queue (i.e. not previously - declared) to an exchange. - </doc> - <doc type = "scenario"> - A client attempts to bind an undeclared queue name to an exchange. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name" label = "name of the exchange to bind to"> - <!-- Rule test name: was "amq_queue_14" --> - <rule name = "exchange-existence" on-failure = "not-found"> - <doc> - A client MUST NOT be allowed to bind a queue to a non-existent exchange. - </doc> - <doc type = "scenario"> - A client attempts to bind an named queue to a undeclared exchange. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "message routing key"> - <doc> - Specifies the routing key for the binding. The routing key is used for routing - messages depending on the exchange configuration. Not all exchanges use a - routing key - refer to the specific exchange documentation. If the queue name - is empty, the server uses the last queue declared on the channel. If the - routing key is also empty, the server uses this queue name for the routing - key as well. If the queue name is provided but the routing key is empty, the - server does the binding with that empty routing key. The meaning of empty - routing keys depends on the exchange implementation. - </doc> - <rule name = "direct-exchange-key-matching"> - <doc> - If a message queue binds to a direct exchange using routing key K and a - publisher sends the exchange a message with routing key R, then the message - MUST be passed to the message queue if K = R. - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments for binding"> - <doc> - A set of arguments for the binding. The syntax and semantics of these arguments - depends on the exchange class. - </doc> - </field> - </method> - - <method name = "bind-ok" synchronous = "1" index = "21" label = "confirm bind successful"> - <doc>This method confirms that the bind was successful.</doc> - - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "unbind" synchronous = "1" index = "50" label = "unbind a queue from an exchange"> - <doc>This method unbinds a queue from an exchange.</doc> - <rule name = "01"> - <doc>If a unbind fails, the server MUST raise a connection exception.</doc> - </rule> - <chassis name="server" implement="MUST"/> - <response name="unbind-ok"/> - - <field name = "ticket" domain = "access-ticket"> - <doc> - The client provides a valid access ticket giving "active" - access rights to the queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc>Specifies the name of the queue to unbind.</doc> - <rule name = "02"> - <doc> - If the queue does not exist the server MUST raise a channel exception - with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc>The name of the exchange to unbind from.</doc> - <rule name = "03"> - <doc> - If the exchange does not exist the server MUST raise a channel - exception with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "routing key of binding"> - <doc>Specifies the routing key of the binding to unbind.</doc> - </field> - - <field name = "arguments" domain = "table" label = "arguments of binding"> - <doc>Specifies the arguments of the binding to unbind.</doc> - </field> - </method> - - <method name = "unbind-ok" synchronous = "1" index = "51" label = "confirm unbind successful"> - <doc>This method confirms that the unbind was successful.</doc> - <chassis name = "client" implement = "MUST"/> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "purge" synchronous = "1" index = "30" label = "purge a queue"> - <doc> - This method removes all messages from a queue. It does not cancel consumers. Purged - messages are deleted without any formal "undo" mechanism. - </doc> - - <!-- Rule test name: was "amq_queue_15" --> - <rule name = "01"> - <doc>A call to purge MUST result in an empty queue.</doc> - </rule> - - <!-- Rule test name: was "amq_queue_41" --> - <rule name = "02"> - <doc> - On transacted channels the server MUST not purge messages that have already been - sent to a client but not yet acknowledged. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <!-- Rule test name: was "amq_queue_42" --> - <rule name = "03"> - <doc> - The server MAY implement a purge queue or log that allows system administrators - to recover accidentally-purged messages. The server SHOULD NOT keep purged - messages in the same storage spaces as the live messages since the volumes of - purged messages may get very large. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "purge-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc>The access ticket must be for the access realm that holds the queue.</doc> - - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the queue's access realm. Note that purging a queue is equivalent to reading - all messages and discarding them. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to purge. If the queue name is empty, refers to - the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - - <!-- TODO Rule split? --> - - <!-- Rule test name: was "amq_queue_16" --> - <rule name = "02"> - <doc> - The queue MUST exist. Attempting to purge a non-existing queue MUST cause a - channel exception. - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "purge-ok" synchronous = "1" index = "31" label = "confirms a queue purge"> - <doc>This method confirms the purge of a queue.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "message-count" domain = "long" label = "number of messages purged"> - <doc>Reports the number of messages purged.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "delete" synchronous = "1" index = "40" label = "delete a queue"> - <doc> - This method deletes a queue. When a queue is deleted any pending messages are sent - to a dead-letter queue if this is defined in the server configuration, and all - consumers on the queue are cancelled. - </doc> - - <!-- TODO: Rule split? --> - - <!-- Rule test name: was "amq_queue_43" --> - <rule name = "01"> - <doc> - The server SHOULD use a dead-letter queue to hold messages that were pending on - a deleted queue, and MAY provide facilities for a system administrator to move - these messages back to an active queue. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "delete-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <doc> - The client provides a valid access ticket giving "active" access rights to the - queue's access realm. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to delete. If the queue name is empty, refers to - the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - - <!-- Rule test name: was "amq_queue_21" --> - <rule name = "02"> - <doc> - The queue must exist. If the client attempts to delete a non-existing queue - the server MUST raise a channel exception with reply code 404 (not found). - </doc> - </rule> - </field> - - <field name = "if-unused" domain = "bit" label = "delete only if unused"> - <doc> - If set, the server will only delete the queue if it has no consumers. If the - queue has consumers the server does does not delete it but raises a channel - exception instead. - </doc> - - <!-- Rule test name: was "amq_queue_29" and "amq_queue_30" --> - <rule name = "01"> - <doc>The server MUST respect the if-unused flag when deleting a queue.</doc> - </rule> - </field> - - <field name = "if-empty" domain = "bit" label = "delete only if empty"> - <doc> - If set, the server will only delete the queue if it has no messages. - </doc> - <rule name = "01"> - <doc> - If the queue is not empty the server MUST raise a channel exception with - reply code 406 (precondition failed). - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "delete-ok" synchronous = "1" index = "41" label = "confirm deletion of a queue"> - <doc>This method confirms the deletion of a queue.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "message-count" domain = "long" label = "number of messages purged"> - <doc>Reports the number of messages purged.</doc> - </field> - </method> - </class> - - <!-- == BASIC ============================================================ --> - - <class name = "basic" handler = "channel" index = "60" label = "work with basic content"> - <doc> - The Basic class provides methods that support an industry-standard messaging model. - </doc> - - <doc type = "grammar"> - basic = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN content - / S:DELIVER content - / C:GET ( S:GET-OK content / S:GET-EMPTY ) - / C:ACK - / C:REJECT - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MAY" /> - - <!-- Rule test name: was "amq_basic_08" --> - <rule name = "01"> - <doc> - The server SHOULD respect the persistent property of basic messages and - SHOULD make a best-effort to hold persistent basic messages on a reliable - storage mechanism. - </doc> - <doc type = "scenario"> - Send a persistent message to queue, stop server, restart server and then - verify whether message is still present. Assumes that queues are durable. - Persistence without durable queues makes no sense. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_09" --> - <rule name = "02"> - <doc> - The server MUST NOT discard a persistent basic message in case of a queue - overflow. - </doc> - <doc type = "scenario"> - Create a queue overflow situation with persistent messages and verify that - messages do not get lost (presumably the server will write them to disk). - </doc> - </rule> - - <rule name = "03"> - <doc> - The server MAY use the Channel.Flow method to slow or stop a basic message - publisher when necessary. - </doc> - <doc type = "scenario"> - Create a queue overflow situation with non-persistent messages and verify - whether the server responds with Channel.Flow or not. Repeat with persistent - messages. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_10" --> - <rule name = "04"> - <doc> - The server MAY overflow non-persistent basic messages to persistent - storage. - </doc> - <!-- Test scenario: untestable --> - </rule> - - <rule name = "05"> - <doc> - The server MAY discard or dead-letter non-persistent basic messages on a - priority basis if the queue size exceeds some configured limit. - </doc> - <!-- Test scenario: untestable --> - </rule> - - <!-- Rule test name: was "amq_basic_11" --> - <rule name = "06"> - <doc> - The server MUST implement at least 2 priority levels for basic messages, - where priorities 0-4 and 5-9 are treated as two distinct levels. - </doc> - <doc type = "scenario"> - Send a number of priority 0 messages to a queue. Send one priority 9 - message. Consume messages from the queue and verify that the first message - received was priority 9. - </doc> - </rule> - - <rule name = "07"> - <doc> - The server MAY implement up to 10 priority levels. - </doc> - <doc type = "scenario"> - Send a number of messages with mixed priorities to a queue, so that all - priority values from 0 to 9 are exercised. A good scenario would be ten - messages in low-to-high priority. Consume from queue and verify how many - priority levels emerge. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_12" --> - <rule name = "08"> - <doc> - The server MUST deliver messages of the same priority in order irrespective of - their individual persistence. - </doc> - <doc type = "scenario"> - Send a set of messages with the same priority but different persistence - settings to a queue. Consume and verify that messages arrive in same order - as originally published. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_13" --> - <rule name = "09"> - <doc> - The server MUST support automatic acknowledgements on Basic content, i.e. - consumers with the no-ack field set to FALSE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using automatic acknowledgements. Publish - a set of messages to the queue. Consume the messages and verify that all - messages are received. - </doc> - </rule> - - <rule name = "10"> - <doc> - The server MUST support explicit acknowledgements on Basic content, i.e. - consumers with the no-ack field set to TRUE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using explicit acknowledgements. Publish a - set of messages to the queue. Consume the messages but acknowledge only - half of them. Disconnect and reconnect, and consume from the queue. - Verify that the remaining messages are received. - </doc> - </rule> - - <!-- These are the properties for a Basic content --> - - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "delivery-mode" domain = "octet" label = "non-persistent (1) or persistent (2)" /> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "correlation-id" domain = "shortstr" label = "application correlation identifier" /> - <field name = "reply-to" domain = "shortstr" label = "destination to reply to" /> - <field name = "expiration" domain = "shortstr" label = "message expiration specification" /> - <field name = "message-id" domain = "shortstr" label = "application message identifier" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp" /> - <field name = "type" domain = "shortstr" label = "message type name" /> - <field name = "user-id" domain = "shortstr" label = "creating user id" /> - <field name = "app-id" domain = "shortstr" label = "creating application id" /> - <!-- This field is deprecated pending review --> - <field name = "cluster-id" domain = "shortstr" label = "intra-cluster routing identifier" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "qos-ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. The server - will send a message in advance if it is equal to or smaller in size than the - available prefetch size (and also falls into other prefetch limits). May be set - to zero, meaning "no specific limit", although other prefetch limits may still - apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - <!-- Rule test name: was "amq_basic_17" --> - <rule name = "01"> - <doc> - The server MUST ignore this setting when the client is not processing any - messages - i.e. the prefetch size does not limit the transfer of single - messages to a client, only the sending in advance of more messages while - the client still has one or more unacknowledged messages. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and send a single message that exceeds - that limit. Verify that the message arrives correctly. - </doc> - </rule> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used - in combination with the prefetch-size field; a message will only be sent in - advance if both prefetch windows (and those at the channel and connection level) - allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - <!-- Rule test name: was "amq_basic_18" --> - <rule name = "01"> - <doc> - The server may send less data in advance than allowed by the client's - specified prefetch windows but it MUST NOT send more. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and a prefetch-count limit greater than - one. Send multiple messages that exceed the prefetch size. Verify that - no more than one message arrives at once. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the - server. The requested QoS applies to all active consumers until a new QoS is - defined. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <!-- Rule test name: was "amq_basic_01" --> - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, and ideally, impose - no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - Create a queue and create consumers on that queue until the server closes the - connection. Verify that the number of consumers created was at least sixteen - and report the total number. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an invalid (non-zero) access ticket. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - If the queue name is empty the client MUST have previously declared a - queue using this channel. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an empty queue name and no previously - declared queue on the channel. - </doc> - </rule> - </field> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a - connection, so two clients can use the same consumer tags. If this field is - empty the server will generate a unique tag. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - The client MUST NOT specify a tag that refers to an existing consumer. - </doc> - <doc type = "scenario"> - Attempt to create two consumers with the same non-empty tag. - </doc> - </rule> - <rule name = "02" on-failure = "not-allowed"> - <doc> - The consumer tag is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in one - channel and then use it in another. - </doc> - <doc type = "scenario"> - Attempt to create a consumer in one channel, then use in another channel, - in which consumers have also been created (to test that the server uses - unique consumer tags). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "no-ack" domain = "no-ack" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - <!-- Rule test name: was "amq_basic_02" --> - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MAY NOT gain exclusive access to a queue that already has - active consumers. - </doc> - <doc type = "scenario"> - Open two connections to a server, and in one connection create a shared - (non-exclusive) queue and then consume from the queue. In the second - connection attempt to consume from the same queue using the exclusive - option. - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise - a channel or connection exception. - </doc> - </field> - - <!-- RG changed name from filter to arguments on basic.consume: this is inline with qpid0-8 and 0-10 and has no effect on the wire level encoding - <field name = "arguments" domain = "table" label = "arguments for consuming"> --> - <field name = "arguments" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer"> - <doc> - The server provides the client with a consumer tag, which is used by the client - for methods called on the consumer at a later stage. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Holds the consumer tag specified by the client or provided by the server. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer"> - <doc> - This method cancels a consumer. This does not affect already delivered - messages, but it does mean the server will not send any more messages for - that consumer. The client may receive an arbitrary number of messages in - between sending the cancel method and receiving the cancel-ok reply. - </doc> - - <rule name = "01"> - <doc> - If the queue does not exist the server MUST ignore the cancel method, so - long as the consumer tag is valid for that channel. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "cancel-ok" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer"> - <doc> - This method confirms that the cancellation was completed. - </doc> - <chassis name = "client" implement = "MUST" /> - <field name = "consumer-tag" domain = "consumer-tag" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "publish" content = "1" index = "40" label = "publish a message"> - <doc> - This method publishes a message to a specific exchange. The message will be routed - to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be - empty, meaning the default exchange. If the exchange name is specified, and that - exchange does not exist, the server will raise a channel exception. - </doc> - - <!-- Rule test name: was "amq_basic_06" --> - <rule name = "01"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_14" --> - <rule name = "02"> - <doc> - If the exchange was declared as an internal exchange, the server MUST raise - a channel exception with a reply code 403 (access refused). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_15" --> - <rule name = "03"> - <doc> - The exchange MAY refuse basic content in which case it MUST raise a channel - exception with reply code 540 (not implemented). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing - messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" domain = "bit" label = "indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue. If this flag is set, the server will return an unroutable message with a - Return method. If this flag is zero, the server silently drops the message. - </doc> - <!-- Rule test name: was "amq_basic_07" --> - <rule name = "01"> - <doc> - The server SHOULD implement the mandatory flag. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue consumer immediately. If this flag is set, the server will return an - undeliverable message with a Return method. If this flag is zero, the server - will queue the message, but with no guarantee that it will ever be consumed. - </doc> - <!-- Rule test name: was "amq_basic_16" --> - <rule name = "01"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - </method> - - <method name = "return" content = "1" index = "50" label = "return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" - flag set, or an unroutable message published with the "mandatory" flag set. The - reply code and text provide information about the reason that the message was - undeliverable. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "reply-code" domain = "reply-code" /> - - <field name = "reply-text" domain = "reply-text" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key name specified when the message was published. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "deliver" content = "1" index = "60" - label = "notify the client of a consumer message"> - <doc> - This method delivers a message to the client, via a consumer. In the asynchronous - message delivery model, the client starts a consumer using the Consume method, then - the server responds with Deliver methods as and when messages arrive for that - consumer. - </doc> - - <!-- Rule test name: was "amq_basic_19" --> - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server SHOULD track the number of times a message has been delivered to - clients and when a message is redelivered a certain number of times - e.g. 5 - times - without being acknowledged, the server SHOULD consider the message to be - unprocessable (possibly causing client applications to abort), and move the - message to a dead letter queue. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "get" synchronous = "1" index = "70" label = "direct access to a queue"> - <doc> - This method provides a direct access to the messages in a queue using a synchronous - dialogue that is designed for specific types of application where synchronous - functionality is more important than performance. - </doc> - - <response name = "get-ok" /> - <response name = "get-empty" /> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - - <field name = "no-ack" domain = "no-ack" /> - </method> - - <method name = "get-ok" synchronous = "1" content = "1" index = "71" - label = "provide client with a message"> - <doc> - This method delivers a message to the client following a get method. A message - delivered by 'get-ok' must be acknowledged unless the no-ack option was set in the - get method. - </doc> - - <chassis name = "client" implement = "MAY" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - If empty, the message was published to the default exchange. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - - <field name = "message-count" domain = "long" label = "number of messages pending"> - <doc> - This field reports the number of messages pending on the queue, excluding the - message being delivered. Note that this figure is indicative, not reliable, and - can change arbitrarily as messages are added to the queue and removed by other - clients. - </doc> - </field> - </method> - - <method name = "get-empty" synchronous = "1" index = "72" - label = "indicate no messages available"> - <doc> - This method tells the client that the queue has no messages available for the - client. - </doc> - - <chassis name = "client" implement = "MAY" /> - - <!-- This field is deprecated pending review --> - <field name = "cluster-id" domain = "shortstr" label = "Cluster id"> - <doc> - For use by cluster applications, should not be used by client applications. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "ack" index = "80" label = "acknowledge one or more messages"> - <doc> - This method acknowledges one or more messages delivered via the Deliver or Get-Ok - methods. The client can ask to confirm a single message or a set of messages up to - and including a specific message. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "multiple" domain = "bit" label = "acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the - client can acknowledge multiple messages with a single method. If set to zero, - the delivery tag refers to a single message. If the multiple field is 1, and the - delivery tag is zero, tells the server to acknowledge all outstanding messages. - </doc> - - <!-- Rule test name: was "amq_basic_20" --> - <rule name = "01"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered - message, and raise a channel exception if this is not the case. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "reject" index = "90" label = "reject an incoming message"> - <doc> - This method allows a client to reject a message. It can be used to interrupt and - cancel large incoming messages, or return untreatable messages to their original - queue. - </doc> - - <!-- Rule test name: was "amq_basic_21" --> - <rule name = "01"> - <doc> - The server SHOULD be capable of accepting and process the Reject method while - sending message content with a Deliver or Get-Ok method. I.e. the server should - read and process incoming methods while sending output frames. To cancel a - partially-send content, the server sends a content body frame of size 1 (i.e. - with no data except the frame-end octet). - </doc> - </rule> - - <!-- Rule test name: was "amq_basic_22" --> - <rule name = "02"> - <doc> - The server SHOULD interpret this method as meaning that the client is unable to - process the message at this time. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <rule name = "03"> - <!-- TODO: Rule split? --> - <doc> - A client MUST NOT use this method as a means of selecting messages to process. A - rejected message MAY be discarded or dead-lettered, not necessarily passed to - another client. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the - server will attempt to requeue the message. - </doc> - - <!-- Rule test name: was "amq_basic_23" --> - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MUST NOT deliver the message to the same client within the - context of the current channel. The recommended strategy is to attempt to - deliver the message to an alternative consumer, and if that is not possible, - to move the message to a dead-letter queue. The server MAY use more - sophisticated tracking to hold the message on the queue and redeliver it to - the same client at a later stage. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - </field> - </method> - - <method name = "recover" index = "100" label = "redeliver unacknowledged messages"> - <doc> - This method asks the broker to redeliver all unacknowledged messages on a specified - channel. Zero or more messages may be redelivered. This method is only allowed on - non-transacted channels. - </doc> - - <rule name = "01"> - <doc> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <rule name = "02"> - <doc> - The server MUST raise a channel exception if this is called on a transacted - channel. - </doc> - <doc type = "scenario"> - TODO. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the message, - potentially then delivering it to an alternative subscriber. - </doc> - </field> - </method> - - - <!-- RG : Added recover-sync and recover-sync-ok to give a synchronous recover without interfering with the correct 0-9 recover method --> - <method name = "recover-sync" index = "102"> - redeliver unacknowledged messages - <doc> - This method asks the broker to redeliver all unacknowledged messages on a - specified channel. Zero or more messages may be redelivered. This method - is only allowed on non-transacted channels. - </doc> - <chassis name = "server" implement = "MUST" /> - - <field name = "requeue" type = "bit"> - requeue the message - <doc> - If this field is zero, the message will be redelivered to the original - recipient. If this bit is 1, the server will attempt to requeue the - message, potentially then delivering it to an alternative subscriber. - </doc> - </field> - <doc name="rule"> - The server MUST set the redelivered flag on all messages that are resent. - </doc> - <doc name="rule"> - The server MUST raise a channel exception if this is called on a - transacted channel. - </doc> - <response name="recover-sync-ok"/> - </method> - <method name="recover-sync-ok" synchronous="1" index="101"> - confirm a successful recover - <doc> - This method confirms to the client that the recover succeeded. - Note that if an recover fails, the server raises a channel exception. - </doc> - <chassis name="client" implement="MUST"/> - </method> - - - </class> - - <!-- == FILE ============================================================= --> - - <class name = "file" handler = "channel" index = "70" label = "work with file content"> - <doc> - The file class provides methods that support reliable file transfer. File - messages have a specific set of properties that are required for interoperability - with file transfer applications. File messages and acknowledgements are subject to - channel transactions. Note that the file class does not provide message browsing - methods; these are not compatible with the staging model. Applications that need - browsable file transfer should use Basic content and the Basic class. - </doc> - - <doc type = "grammar"> - file = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:OPEN S:OPEN-OK C:STAGE content - / S:OPEN C:OPEN-OK S:STAGE content - / C:PUBLISH - / S:DELIVER - / S:RETURN - / C:ACK - / C:REJECT - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <rule name = "01"> - <doc> - The server MUST make a best-effort to hold file messages on a reliable storage - mechanism. - </doc> - </rule> - - <!-- TODO Rule implement attr inverse? --> - - <!-- TODO: Rule split? --> - - <rule name = "02"> - <doc> - The server MUST NOT discard a file message in case of a queue overflow. The server - MUST use the Channel.Flow method to slow or stop a file message publisher when - necessary. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <rule name = "03"> - <doc> - The server MUST implement at least 2 priority levels for file messages, where - priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement - up to 10 priority levels. - </doc> - </rule> - - <rule name = "04"> - <doc> - The server MUST support both automatic and explicit acknowledgements on file - content. - </doc> - </rule> - - <!-- These are the properties for a File content --> - - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "reply-to" domain = "shortstr" label = "destination to reply to" /> - <field name = "message-id" domain = "shortstr" label = "application message identifier" /> - <field name = "filename" domain = "shortstr" label = "message filename" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp" /> - <!-- This field is deprecated pending review --> - <field name = "cluster-id" domain = "shortstr" label = "intra-cluster routing identifier" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <response name = "qos-ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. May be set - to zero, meaning "no specific limit". Note that other prefetch limits may still - apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This is compatible with - some file API implementations. This field may be used in combination with the - prefetch-size field; a message will only be sent in advance if both prefetch - windows (and those at the channel and connection level) allow it. The - prefetch-count is ignored if the no-ack option is set. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MAY send less data in advance than allowed by the client's - specified prefetch windows but it MUST NOT send more. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the - server. The requested QoS applies to all active consumers until a new QoS is - defined. - </doc> - - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was - declared as private, and ideally, impose no limit except as defined by available - resources. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a - connection, so two clients can use the same consumer tags. If this field is - empty the server will generate a unique tag. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to - create two consumers with the same non-empty tag the server MUST raise a - connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "no-ack" domain = "no-ack" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel exception - with return code 405 (resource locked). - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "filter" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer"> - <doc> - This method provides the client with a consumer tag which it MUST use in methods - that work with the consumer. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc>Holds the consumer tag specified by the client or provided by the server.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer"> - <doc> - This method cancels a consumer. This does not affect already delivered messages, but - it does mean the server will not send any more messages for that consumer. - </doc> - - <response name = "cancel-ok" /> - - <chassis name = "server" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer"> - <doc>This method confirms that the cancellation was completed.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" synchronous = "1" index = "40" label = "request to start staging"> - <doc> - This method requests permission to start staging a message. Staging means sending - the message into a temporary area at the recipient end and then delivering the - message by referring to this temporary area. Staging is how the protocol handles - partial file transfers - if a message is partially staged and the connection breaks, - the next time the sender starts to stage it, it can restart from where it left off. - </doc> - - <response name = "open-ok" /> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "identifier" domain = "shortstr" label = "staging identifier"> - <doc> - This is the staging identifier. This is an arbitrary string chosen by the - sender. For staging to work correctly the sender must use the same staging - identifier when staging the same message a second time after recovery from a - failure. A good choice for the staging identifier would be the SHA1 hash of the - message properties data (including the original filename, revised time, etc.). - </doc> - </field> - - <field name = "content-size" domain = "longlong" label = "message content size"> - <doc> - The size of the content in octets. The recipient may use this information to - allocate or check available space in advance, to avoid "disk full" errors during - staging of very large messages. - </doc> - - <rule name = "01"> - <doc> - The sender MUST accurately fill the content-size field. Zero-length content - is permitted. - </doc> - </rule> - </field> - </method> - - <method name = "open-ok" synchronous = "1" index = "41" label = "confirm staging ready"> - <doc> - This method confirms that the recipient is ready to accept staged data. If the - message was already partially-staged at a previous time the recipient will report - the number of octets already staged. - </doc> - - <response name = "stage" /> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <field name = "staged-size" domain = "longlong" label = "already staged amount"> - <doc> - The amount of previously-staged content in octets. For a new message this will - be zero. - </doc> - - <rule name = "01"> - <doc> - The sender MUST start sending data from this octet offset in the message, - counting from zero. - </doc> - </rule> - - <rule name = "02"> - <!-- TODO: Rule split? --> - <doc> - The recipient MAY decide how long to hold partially-staged content and MAY - implement staging by always discarding partially-staged content. However if - it uses the file content type it MUST support the staging methods. - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "stage" content = "1" index = "50" label = "stage message content"> - <doc> - This method stages the message, sending the message content to the recipient from - the octet offset specified in the Open-Ok method. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "publish" index = "60" label = "publish a message"> - <doc> - This method publishes a staged file message to a specific exchange. The file message - will be routed to queues as defined by the exchange configuration and distributed to - any active consumers when the transaction, if any, is committed. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be - empty, meaning the default exchange. If the exchange name is specified, and that - exchange does not exist, the server will raise a channel exception. - </doc> - - <rule name = "01"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name = "02"> - <doc> - If the exchange was declared as an internal exchange, the server MUST - respond with a reply code 403 (access refused) and raise a channel - exception. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <rule name = "03"> - <doc> - The exchange MAY refuse file content in which case it MUST respond with a - reply code 540 (not implemented) and raise a channel exception. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing - messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" domain = "bit" label = "indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue. If this flag is set, the server will return an unroutable message with a - Return method. If this flag is zero, the server silently drops the message. - </doc> - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the mandatory flag.</doc> - </rule> - </field> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue consumer immediately. If this flag is set, the server will return an - undeliverable message with a Return method. If this flag is zero, the server - will queue the message, but with no guarantee that it will ever be consumed. - </doc> - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the immediate flag.</doc> - </rule> - </field> - - <field name = "identifier" domain = "shortstr" label = "staging identifier"> - <doc> - This is the staging identifier of the message to publish. The message must have - been staged. Note that a client can send the Publish method asynchronously - without waiting for staging to finish. - </doc> - </field> - </method> - - <method name = "return" content = "1" index = "70" label = "return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" - flag set, or an unroutable message published with the "mandatory" flag set. The - reply code and text provide information about the reason that the message was - undeliverable. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "reply-code" domain = "reply-code" /> - - <field name = "reply-text" domain = "reply-text" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "deliver" index = "80" label = "notify the client of a consumer message"> - <doc> - This method delivers a staged file message to the client, via a consumer. In the - asynchronous message delivery model, the client starts a consumer using the Consume - method, then the server responds with Deliver methods as and when messages arrive - for that consumer. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server SHOULD track the number of times a message has been delivered to - clients and when a message is redelivered a certain number of times - e.g. 5 - times - without being acknowledged, the server SHOULD consider the message to be - unprocessable (possibly causing client applications to abort), and move the - message to a dead letter queue. - </doc> - </rule> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - - <field name = "identifier" domain = "shortstr" label = "staging identifier"> - <doc> - This is the staging identifier of the message to deliver. The message must have - been staged. Note that a server can send the Deliver method asynchronously - without waiting for staging to finish. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "ack" index = "90" label = "acknowledge one or more messages"> - <doc> - This method acknowledges one or more messages delivered via the Deliver method. The - client can ask to confirm a single message or a set of messages up to and including - a specific message. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "multiple" domain = "bit" label = "acknowledge multiple messages"> - <doc> - If set to 1, the delivery tag is treated as "up to and including", so that the - client can acknowledge multiple messages with a single method. If set to zero, - the delivery tag refers to a single message. If the multiple field is 1, and the - delivery tag is zero, tells the server to acknowledge all outstanding messages. - </doc> - - <rule name = "01"> - <doc> - The server MUST validate that a non-zero delivery-tag refers to an delivered - message, and raise a channel exception if this is not the case. - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "reject" index = "100" label = "reject an incoming message"> - <doc> - This method allows a client to reject a message. It can be used to return - untreatable messages to their original queue. Note that file content is staged - before delivery, so the client will not use this method to interrupt delivery of a - large message. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD interpret this method as meaning that the client is unable to - process the message at this time. - </doc> - </rule> - - <!-- TODO: Rule split? --> - - <rule name = "02"> - <doc> - A client MUST NOT use this method as a means of selecting messages to process. A - rejected message MAY be discarded or dead-lettered, not necessarily passed to - another client. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be discarded. If this bit is 1, the - server will attempt to requeue the message. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MUST NOT deliver the message to the same client within the - context of the current channel. The recommended strategy is to attempt to - deliver the message to an alternative consumer, and if that is not possible, - to move the message to a dead-letter queue. The server MAY use more - sophisticated tracking to hold the message on the queue and redeliver it to - the same client at a later stage. - </doc> - </rule> - </field> - </method> - </class> - - <!-- == STREAM =========================================================== --> - - <class name = "stream" handler = "channel" index = "80" label = "work with streaming content"> - <doc> - The stream class provides methods that support multimedia streaming. The stream class - uses the following semantics: one message is one packet of data; delivery is - unacknowledged and unreliable; the consumer can specify quality of service parameters - that the server can try to adhere to; lower-priority messages may be discarded in favour - of high priority messages. - </doc> - - <doc type = "grammar"> - stream = C:QOS S:QOS-OK - / C:CONSUME S:CONSUME-OK - / C:CANCEL S:CANCEL-OK - / C:PUBLISH content - / S:RETURN - / S:DELIVER content - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <rule name = "01"> - <doc> - The server SHOULD discard stream messages on a priority basis if the queue size - exceeds some configured limit. - </doc> - </rule> - - <rule name = "02"> - <!-- TODO: Rule split? --> - <doc> - The server MUST implement at least 2 priority levels for stream messages, where - priorities 0-4 and 5-9 are treated as two distinct levels. The server MAY implement - up to 10 priority levels. - </doc> - </rule> - - <rule name = "03"> - <doc> - The server MUST implement automatic acknowledgements on stream content. That is, as - soon as a message is delivered to a client via a Deliver method, the server must - remove it from the queue. - </doc> - </rule> - - <!-- These are the properties for a Stream content --> - - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" synchronous = "1" index = "10" label = "specify quality of service"> - <doc> - This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <response name = "qos-ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. May be set - to zero, meaning "no specific limit". Note that other prefetch limits may still - apply. - </doc> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used - in combination with the prefetch-size field; a message will only be sent in - advance if both prefetch windows (and those at the channel and connection level) - allow it. - </doc> - </field> - - <field name = "consume-rate" domain = "long" label = "transfer rate in octets/second"> - <doc> - Specifies a desired transfer rate in octets per second. This is usually - determined by the application that uses the streaming data. A value of zero - means "no limit", i.e. as rapidly as possible. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The server MAY ignore the prefetch values and consume rates, depending on - the type of stream and the ability of the server to queue and/or reply it. - The server MAY drop low-priority messages in favour of high-priority - messages. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos"> - <doc> - This method tells the client that the requested QoS levels could be handled by the - server. The requested QoS applies to all active consumers until a new QoS is - defined. - </doc> - - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer"> - <doc> - This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, unless the queue was - declared as private, and ideally, impose no limit except as defined by available - resources. - </doc> - </rule> - - <rule name = "02"> - <doc> - Streaming applications SHOULD use different channels to select different - streaming resolutions. AMQP makes no provision for filtering and/or transforming - streams except on the basis of priority-based selective delivery of individual - messages. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "consume-ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc> - Specifies the identifier for the consumer. The consumer tag is local to a - connection, so two clients can use the same consumer tags. If this field is - empty the server will generate a unique tag. - </doc> - - <rule name = "01"> - <!-- TODO: Rule split? --> - <doc> - The tag MUST NOT refer to an existing consumer. If the client attempts to - create two consumers with the same non-empty tag the server MUST raise a - connection exception with reply code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - - - <!-- Rule test name: was "amq_file_00" --> - <rule name = "01"> - <doc> - If the server cannot grant exclusive access to the queue when asked, - - because there are other consumers active - it MUST raise a channel exception - with return code 405 (resource locked). - </doc> - </rule> - </field> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - - <field name = "filter" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer"> - <doc> - This method provides the client with a consumer tag which it may use in methods that - work with the consumer. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag"> - <doc>Holds the consumer tag specified by the client or provided by the server.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer"> - <doc> - This method cancels a consumer. Since message delivery is asynchronous the client - may continue to receive messages for a short while after cancelling a consumer. It - may process or discard these as appropriate. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <response name = "cancel-ok" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "nowait" domain = "bit" label = "do not send a reply method"> - <doc> - If set, the server will not respond to the method. The client should not wait - for a reply method. If the server could not complete the method it will raise a - channel or connection exception. - </doc> - </field> - </method> - - <method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer"> - <doc>This method confirms that the cancellation was completed.</doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "publish" content = "1" index = "40" label = "publish a message"> - <doc> - This method publishes a message to a specific exchange. The message will be routed - to queues as defined by the exchange configuration and distributed to any active - consumers as appropriate. - </doc> - - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - </rule> - </field> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange to publish to. The exchange name can be - empty, meaning the default exchange. If the exchange name is specified, and that - exchange does not exist, the server will raise a channel exception. - </doc> - - <rule name = "01"> - <doc> - The server MUST accept a blank exchange name to mean the default exchange. - </doc> - </rule> - - <rule name = "02"> - <doc> - If the exchange was declared as an internal exchange, the server MUST - respond with a reply code 403 (access refused) and raise a channel - exception. - </doc> - </rule> - - <rule name = "03"> - <doc> - The exchange MAY refuse stream content in which case it MUST respond with a - reply code 540 (not implemented) and raise a channel exception. - </doc> - </rule> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc> - Specifies the routing key for the message. The routing key is used for routing - messages depending on the exchange configuration. - </doc> - </field> - - <field name = "mandatory" domain = "bit" label = "indicate mandatory routing"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue. If this flag is set, the server will return an unroutable message with a - Return method. If this flag is zero, the server silently drops the message. - </doc> - - <!-- Rule test name: was "amq_stream_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the mandatory flag.</doc> - </rule> - </field> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message cannot be routed to a - queue consumer immediately. If this flag is set, the server will return an - undeliverable message with a Return method. If this flag is zero, the server - will queue the message, but with no guarantee that it will ever be consumed. - </doc> - - <!-- Rule test name: was "amq_stream_00" --> - <rule name = "01"> - <doc>The server SHOULD implement the immediate flag.</doc> - </rule> - </field> - </method> - - <method name = "return" content = "1" index = "50" label = "return a failed message"> - <doc> - This method returns an undeliverable message that was published with the "immediate" - flag set, or an unroutable message published with the "mandatory" flag set. The - reply code and text provide information about the reason that the message was - undeliverable. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "reply-code" domain = "reply-code" /> - - <field name = "reply-text" domain = "reply-text" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "routing-key" domain = "shortstr" label = "Message routing key"> - <doc>Specifies the routing key name specified when the message was published.</doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "deliver" content = "1" index = "60" - label = "notify the client of a consumer message"> - <doc> - This method delivers a message to the client, via a consumer. In the asynchronous - message delivery model, the client starts a consumer using the Consume method, then - the server responds with Deliver methods as and when messages arrive for that - consumer. - </doc> - - <chassis name = "client" implement = "MUST" /> - - <field name = "consumer-tag" domain = "consumer-tag" /> - - <field name = "delivery-tag" domain = "delivery-tag" /> - - <field name = "exchange" domain = "exchange-name"> - <doc> - Specifies the name of the exchange that the message was originally published to. - </doc> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue that the message came from. Note that a single - channel can start many consumers on different queues. - </doc> - <assert check = "notnull" /> - </field> - </method> - </class> - - <!-- == TX =============================================================== --> - - <class name = "tx" handler = "channel" index = "90" label = "work with standard transactions"> - <doc> - Standard transactions provide so-called "1.5 phase commit". We can ensure that work is - never lost, but there is a chance of confirmations being lost, so that messages may be - resent. Applications that use standard transactions must be able to detect and ignore - duplicate messages. - </doc> - - <!-- TODO: Rule split? --> - - <rule name = "01"> - <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> - - <doc type = "grammar"> - tx = C:SELECT S:SELECT-OK - / C:COMMIT S:COMMIT-OK - / C:ROLLBACK S:ROLLBACK-OK - </doc> - - <chassis name = "server" implement = "SHOULD" /> - <chassis name = "client" implement = "MAY" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "select" synchronous = "1" index = "10" label = "select standard transaction mode"> - <doc> - This method sets the channel to use standard transactions. The client must use this - method at least once on a channel before using the Commit or Rollback methods. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "select-ok" /> - </method> - - <method name = "select-ok" synchronous = "1" index = "11" label = "confirm transaction mode"> - <doc> - This method confirms to the client that the channel was successfully set to use - standard transactions. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "commit" synchronous = "1" index = "20" label = "commit the current transaction"> - <doc> - This method commits all messages published and acknowledged in the current - transaction. A new transaction starts immediately after a commit. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "commit-ok" /> - </method> - - <method name = "commit-ok" synchronous = "1" index = "21" label = "confirm a successful commit"> - <doc> - This method confirms to the client that the commit succeeded. Note that if a commit - fails, the server raises a channel exception. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "rollback" synchronous = "1" index = "30" - label = "abandon the current transaction"> - <doc> - This method abandons all messages published and acknowledged in the current - transaction. A new transaction starts immediately after a rollback. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "rollback-ok" /> - </method> - - <method name = "rollback-ok" synchronous = "1" index = "31" label = "confirm successful rollback"> - <doc> - This method confirms to the client that the rollback succeeded. Note that if an - rollback fails, the server raises a channel exception. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - </class> - - <!-- == DTX ============================================================== --> - - <class name = "dtx" handler = "channel" index = "100" label = "work with distributed transactions"> - <doc> - Distributed transactions provide so-called "2-phase commit". The AMQP distributed - transaction model supports the X-Open XA architecture and other distributed transaction - implementations. The Dtx class assumes that the server has a private communications - channel (not AMQP) to a distributed transaction coordinator. - </doc> - - <doc type = "grammar"> - dtx = C:SELECT S:SELECT-OK - C:START S:START-OK - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "select" synchronous = "1" index = "10" label = "select standard transaction mode"> - <doc> - This method sets the channel to use distributed transactions. The client must use - this method at least once on a channel before using the Start method. - </doc> - <chassis name = "server" implement = "MUST" /> - <response name = "select-ok" /> - </method> - - <method name = "select-ok" synchronous = "1" index = "11" label = "confirm transaction mode"> - <doc> - This method confirms to the client that the channel was successfully set to use - distributed transactions. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "start" synchronous = "1" index = "20" - label = "start a new distributed transaction"> - <doc> - This method starts a new distributed transaction. This must be the first method on a - new channel that uses the distributed transaction mode, before any methods that - publish or consume messages. - </doc> - <chassis name = "server" implement = "MAY" /> - <response name = "start-ok" /> - <field name = "dtx-identifier" domain = "shortstr" label = "transaction identifier"> - <doc> - The distributed transaction key. This identifies the transaction so that the - AMQP server can coordinate with the distributed transaction coordinator. - </doc> - <assert check = "notnull" /> - </field> - </method> - - <method name = "start-ok" synchronous = "1" index = "21" - label = "confirm the start of a new distributed transaction"> - <doc> - This method confirms to the client that the transaction started. Note that if a - start fails, the server raises a channel exception. - </doc> - <chassis name = "client" implement = "MUST" /> - </method> - </class> - - <!-- == TUNNEL =========================================================== --> - - <class name = "tunnel" handler = "tunnel" index = "110" label = "methods for protocol tunnelling"> - <doc> - The tunnel methods are used to send blocks of binary data - which can be serialised AMQP - methods or other protocol frames - between AMQP peers. - </doc> - - <doc type = "grammar"> - tunnel = C:REQUEST - / S:REQUEST - </doc> - - <chassis name = "server" implement = "MAY" /> - <chassis name = "client" implement = "MAY" /> - - <field name = "headers" domain = "table" label = "message header field table" /> - <field name = "proxy-name" domain = "shortstr" label = "identity of tunnelling proxy" /> - <field name = "data-name" domain = "shortstr" label = "name or type of message being tunnelled" /> - <field name = "durable" domain = "octet" label = "message durability indicator" /> - <field name = "broadcast" domain = "octet" label = "message broadcast mode" /> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "request" content = "1" index = "10" label = "sends a tunnelled method"> - <doc> - This method tunnels a block of binary data, which can be an encoded - AMQP method or other data. The binary data is sent as the content for - the Tunnel.Request method. - </doc> - <chassis name = "server" implement = "MUST" /> - <field name = "meta-data" domain = "table" label = "meta data for the tunnelled block"> - <doc> - This field table holds arbitrary meta-data that the sender needs to - pass to the recipient. - </doc> - </field> - </method> - </class> - - <!-- == MESSAGE ============================================================ --> - - <class name = "message" index = "120" handler = "channel" label = "[WORK IN PROGRESS] message transfer"> - <doc> - [WORK IN PROGRESS] The message class provides methods that support an industry-standard messaging model. - </doc> - - <doc type = "grammar"> - message = C:QOS S:OK - / C:CONSUME S:OK - / C:CANCEL S:OK - / C:TRANSFER ( S:OK / S:REJECT ) - / S:TRANSFER ( C:OK / C:REJECT ) - / C:GET ( S:OK / S:EMPTY ) - / C:RECOVER S:OK - / C:OPEN S:OK - / S:OPEN C:OK - / C:APPEND S:OK - / S:APPEND C:OK - / C:CLOSE S:OK - / S:CLOSE C:OK - / C:CHECKPOINT S:OK - / S:CHECKPOINT C:OK - / C:RESUME S:OFFSET - / S:RESUME C:OFFSET - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <rule name = "01"> - <doc> - The server SHOULD respect the persistent property of messages - and SHOULD make a best-effort to hold persistent mess ages on - a reliable storage mechanism. - </doc> - <doc type = "scenario"> - Send a persistent message to queue, stop server, restart - server and then verify whether message is still present. - Assumes that queues are durable. Persistence without durable - queues makes no sense. - </doc> - </rule> - - <rule name = "02"> - <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 = "03"> - <doc> - The server MAY use the Channel.Flow method to slow or stop a - message publisher when necessary. - </doc> - <doc type = "scenario"> - Create a queue overflow situation with non-persistent messages - and verify whether the server responds with Channel.Flow or - not. Repeat with persistent messages. - </doc> - </rule> - - <rule name = "04"> - <doc> - The server MAY overflow non-persistent messages to persistent - storage. - </doc> - </rule> - - <rule name = "05"> - <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 = "06"> - <doc> - The server MUST implement at least 2 priority levels for - messages, where priorities 0-4 and 5-9 are treated as two - distinct levels. - </doc> - <doc type = "scenario"> - Send a number of priority 0 messages to a queue. Send one - priority 9 message. Consume messages from the queue and verify - that the first message received was priority 9. - </doc> - </rule> - - <rule name = "07"> - <doc> - The server MAY implement up to 10 priority levels. - </doc> - <doc type = "scenario"> - Send a number of messages with mixed priorities to a queue, so - that all priority values from 0 to 9 are exercised. A good - scenario would be ten messages in low-to-high priority. - Consume from queue and verify how many priority levels emerge. - </doc> - </rule> - - <rule name = "08"> - <doc> - The server MUST deliver messages of the same priority in order - irrespective of their individual persistence. - </doc> - <doc type = "scenario"> - Send a set of messages with the same priority but different - persistence settings to a queue. Consume and verify that - messages arrive in same order as originally published. - </doc> - </rule> - - <rule name = "09"> - <doc> - The server MUST support automatic acknowledgements on - messages, i.e. consumers with the no-ack field set to FALSE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using automatic - acknowledgements. Publish a set of messages to the queue. - Consume the messages and verify that all messages are - received. - </doc> - </rule> - - <rule name = "10"> - <doc> - The server MUST support explicit acknowledgements on messages, - i.e. consumers with the no-ack field set to TRUE. - </doc> - <doc type = "scenario"> - Create a queue and a consumer using explicit acknowledgements. - Publish a set of messages to the queue. Consume the messages - but acknowledge only half of them. Disconnect and reconnect, - and consume from the queue. Verify that the remaining messages - are received. - </doc> - </rule> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "transfer" index = "10" label = "[WORK IN PROGRESS] transfer a message"> - <doc> - [WORK IN PROGRESS] This method transfers a message between two peers. When a - client uses this method to publish a message to a broker, the - destination identifies a specific exchange. The message will - then be routed to queues as defined by the exchange - configuration and distributed to any active consumers when the - transaction, if any, is committed. - - In the asynchronous message delivery model, the client starts - a consumer using the Consume method and passing in a - destination, then the broker responds with transfer methods to - the specified destination as and when messages arrive for that - consumer. - - If synchronous message delivery is required, the client may - issue a get request which on success causes a single message - to be transferred to the specified destination. - - Message acknowledgement is signalled by the return result of - this method. - </doc> - - <rule name = "01"> - <doc> - The recipient MUST NOT return ok before the message has been - processed as defined by the QoS settings. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - <response name = "reject" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "write" access rights - to the access realm for the exchange. - </doc> - </rule> - </field> - - <field name = "destination" domain = "destination"> - <doc> - Specifies the destination to which the message is to be - transferred. The destination can be empty, meaning the - default exchange or consumer. If the destination is - specified, and that exchange or consumer does not exist, the - peer must raise a channel exception. - </doc> - - <rule name = "01"> - <doc> - The server MUST accept a blank destination to mean the - default exchange. - </doc> - </rule> - - <rule name = "02"> - <doc> - If the destination refers to an internal exchange, the - server MUST raise a channel exception with a reply code - 403 (access refused). - </doc> - </rule> - - <rule name = "03"> - <doc> - A destination MAY refuse message content in which case it - MUST raise a channel exception with reply code 540 (not - implemented). - </doc> - </rule> - </field> - - <field name = "redelivered" domain = "redelivered" /> - - <field name = "immediate" domain = "bit" label = "request immediate delivery"> - <doc> - This flag tells the server how to react if the message - cannot be routed to a queue consumer immediately. If this - flag is set, the server will reject the message. If this - flag is zero, the server will queue the message, but with no - guarantee that it will ever be consumed. - </doc> - <rule name = "01"> - <doc> - The server SHOULD implement the immediate flag. - </doc> - </rule> - </field> - - <field name = "ttl" domain = "duration" label = "time to live"> - <doc> - If this is set to a non zero value then a message expiration - time will be computed based on the current time plus this - value. Messages that live longer than their expiration time - will be discarded (or dead lettered). - </doc> - <rule name = "01"> - <doc> - If a message is transfered between brokers before delivery - to a final consumer the ttl should be decremented before - peer to peer transfer and both timestamp and expiration - should be cleared. - </doc> - </rule> - </field> - - <!-- begin headers --> - <field name = "priority" domain = "octet" label = "message priority, 0 to 9" /> - <field name = "timestamp" domain = "timestamp" label = "message timestamp"> - <doc> - Set on arrival by the broker. - </doc> - </field> - <field name = "delivery-mode" domain = "octet" label = "non-persistent (1) or persistent (2)" /> - <field name = "expiration" domain = "timestamp" label = "message expiration time"> - <doc> - The expiration header assigned by the broker. After - receiving the message the broker sets expiration to the sum - of the ttl specified in the publish method and the current - time. (ttl = expiration - timestamp) - </doc> - </field> - <field name = "exchange" domain = "exchange-name" label = "originating exchange" /> - <field name = "routing-key" domain = "shortstr" label = "message routing key" /> - <field name = "message-id" domain = "shortstr" label = "application message identifier" /> - <field name = "correlation-id" domain = "shortstr" label = "application correlation identifier" /> - <field name = "reply-to" domain = "shortstr" label = "destination to reply to" /> - <field name = "content-type" domain = "shortstr" label = "MIME content type" /> - <field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" /> - <field name = "user-id" domain = "shortstr" label = "creating user id" /> - <field name = "app-id" domain = "shortstr" label = "creating application id" /> - <field name = "transaction-id" domain = "shortstr" label = "distributed transaction id" /> - <field name = "security-token" domain = "security-token" /> - <field name = "application-headers" domain = "table" label = "application specific headers table" /> - <!-- end headers --> - - <field name = "body" domain = "content" label = "message body" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "consume" index = "20" label = "[WORK IN PROGRESS] start a queue consumer"> - <doc> - [WORK IN PROGRESS] This method asks the server to start a "consumer", which is a transient request for - messages from a specific queue. Consumers last as long as the channel they were - created on, or until the client cancels them. - </doc> - - <rule name = "01"> - <doc> - The server SHOULD support at least 16 consumers per queue, and ideally, impose - no limit except as defined by available resources. - </doc> - <doc type = "scenario"> - Create a queue and create consumers on that queue until the server closes the - connection. Verify that the number of consumers created was at least sixteen - and report the total number. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an invalid (non-zero) access ticket. - </doc> - </rule> - </field> - - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - If the queue name is empty the client MUST have previously declared a - queue using this channel. - </doc> - <doc type = "scenario"> - Attempt to create a consumer with an empty queue name and no previously - declared queue on the channel. - </doc> - </rule> - </field> - - <field name = "destination" domain = "destination" label = "incoming message destination"> - <doc> - Specifies the destination for the consumer. The destination is local to a - connection, so two clients can use the same destination. - </doc> - <rule name = "01" on-failure = "not-allowed"> - <doc> - The client MUST NOT specify a destination that refers to an existing consumer. - </doc> - <doc type = "scenario"> - Attempt to create two consumers with the same non-empty destination. - </doc> - </rule> - <rule name = "02" on-failure = "not-allowed"> - <doc> - The destination is valid only within the channel from which the - consumer was created. I.e. a client MUST NOT create a consumer in one - channel and then use it in another. - </doc> - <doc type = "scenario"> - Attempt to create a consumer in one channel, then use in another channel, - in which consumers have also been created (to test that the server uses - unique destinations). - </doc> - </rule> - </field> - - <field name = "no-local" domain = "no-local" /> - - <field name = "no-ack" domain = "no-ack" /> - - <field name = "exclusive" domain = "bit" label = "request exclusive access"> - <doc> - Request exclusive consumer access, meaning only this consumer can access the - queue. - </doc> - - <rule name = "01" on-failure = "access-refused"> - <doc> - The client MAY NOT gain exclusive access to a queue that already has - active consumers. - </doc> - <doc type = "scenario"> - Open two connections to a server, and in one connection create a shared - (non-exclusive) queue and then consume from the queue. In the second - connection attempt to consume from the same queue using the exclusive - option. - </doc> - </rule> - </field> - - <field name = "filter" domain = "table" label = "arguments for consuming"> - <doc> - A set of filters for the consume. The syntax and semantics - of these filters depends on the providers implementation. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "cancel" index = "30" label = "[WORK IN PROGRESS] end a queue consumer"> - <doc> - [WORK IN PROGRESS] This method cancels a consumer. This does not affect already delivered - messages, but it does mean the server will not send any more messages for - that consumer. The client may receive an arbitrary number of messages in - between sending the cancel method and receiving the cancel-ok reply. - </doc> - - <rule name = "01"> - <doc> - If the queue does not exist the server MUST ignore the cancel method, so - long as the consumer tag is valid for that channel. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "destination" domain = "destination"/> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "get" index = "40" label = "[WORK IN PROGRESS] direct access to a queue"> - <doc> - [WORK IN PROGRESS] This method provides a direct access to the messages in a queue using a synchronous - dialogue that is designed for specific types of application where synchronous - functionality is more important than performance. - </doc> - - <response name = "ok" /> - <response name = "empty" /> - <chassis name = "server" implement = "MUST" /> - - <field name = "ticket" domain = "access-ticket"> - <rule name = "01"> - <doc> - The client MUST provide a valid access ticket giving "read" access rights to - the realm for the queue. - </doc> - </rule> - </field> - <field name = "queue" domain = "queue-name"> - <doc> - Specifies the name of the queue to consume from. If the queue name is null, - refers to the current queue for the channel, which is the last declared queue. - </doc> - <rule name = "01"> - <doc> - If the client did not previously declare a queue, and the queue name in this - method is empty, the server MUST raise a connection exception with reply - code 530 (not allowed). - </doc> - </rule> - </field> - - <field name = "destination" domain = "destination"> - <doc> - On normal completion of the get request (i.e. a response of - ok). A message will be transferred to the supplied destination. - </doc> - </field> - - <field name = "no-ack" domain = "no-ack" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "recover" index = "50" label = "[WORK IN PROGRESS] redeliver unacknowledged messages"> - <doc> - [WORK IN PROGRESS] This method asks the broker to redeliver all unacknowledged - messages on a specified channel. Zero or more messages may be - redelivered. This method is only allowed on non-transacted - channels. - </doc> - - <rule name = "01"> - <doc> - The server MUST set the redelivered flag on all messages - that are resent. - </doc> - </rule> - - <rule name = "02"> - <doc> - The server MUST raise a channel exception if this is called - on a transacted channel. - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "requeue" domain = "bit" label = "requeue the message"> - <doc> - If this field is zero, the message will be redelivered to - the original recipient. If this bit is 1, the server will - attempt to requeue the message, potentially then delivering - it to an alternative subscriber. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "open" index = "60" label = "[WORK IN PROGRESS] create a reference to an empty message body"> - <doc> - [WORK IN PROGRESS] This method creates a reference. A references provides a means - to send a message body into a temporary area at the recipient - end and then deliver the message by referring to this - temporary area. This is how the protocol handles large message - transfers. - - The scope of a ref is defined to be between calls to - open (or resume) and close. Between these points it is valid - for a ref to be used from any content data type, and so the - receiver must hold onto its contents. Should the channel be - closed when a ref is still in scope, the receiver may discard - its contents (unless it is checkpointed). A ref that is in - scope is considered open. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - - <field name = "reference" domain = "reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - currently open (in scope). - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "close" index = "70" label = "[WORK IN PROGRESS] close a reference"> - <doc> - [WORK IN PROGRESS] This method signals the recipient that no more data will be - appended to the reference. - </doc> - - <rule name = "01"> - <doc> - A recipient CANNOT acknowledge a message until its reference - is closed (not in scope). - </doc> - </rule> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - - <response name = "ok" /> - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference was - not previously open (in scope). - </doc> - </rule> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "append" index = "80" label = "[WORK IN PROGRESS] append to a reference"> - <doc> - [WORK IN PROGRESS] This method appends data to a reference. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - not open (not in scope). - </doc> - </rule> - </field> - <field name = "bytes" domain = "longstr" label = "data to append" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "checkpoint" index = "90" label = "[WORK IN PROGRESS] checkpoint a message body"> - <doc> - [WORK IN PROGRESS] This method provides a means to checkpoint large message - transfer. The sender may ask the recipient to checkpoint the - contents of a reference using the supplied identifier. The - sender may then resume the transfer at a later point. It is at - the discretion of the recipient how much data to save with the - checkpoint, and the sender MUST honour the offset returned by - the resume method. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "ok" /> - - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - not open (not in scope). - </doc> - </rule> - </field> - <field name = "identifier" domain = "shortstr" label = "checkpoint identifier"> - <doc> - This is the checkpoint identifier. This is an arbitrary - string chosen by the sender. For checkpointing to work - correctly the sender must use the same checkpoint identifier - when resuming the message. A good choice for the checkpoint - identifier would be the SHA1 hash of the message properties - data (including the original filename, revised time, etc.). - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "resume" index = "100" label = "[WORK IN PROGRESS] open and resume a checkpointed message"> - <doc> - [WORK IN PROGRESS] This method resumes a reference from the last checkpoint. A - reference is considered to be open (in scope) after a resume - even though it will not have been opened via the open method - during this session. - </doc> - - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <response name = "offset" /> - - <field name = "reference" domain = "reference" label = "target reference"> - <rule name = "01"> - <doc> - The recipient MUST generate an error if the reference is - currently open (in scope). - </doc> - </rule> - </field> - <field name = "identifier" domain = "shortstr" label = "checkpoint identifier" /> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - - <method name = "qos" index = "110" label = "[WORK IN PROGRESS] specify quality of service"> - <doc> - [WORK IN PROGRESS] This method requests a specific quality of service. The QoS can be specified for the - current channel or for all channels on the connection. The particular properties and - semantics of a qos method always depend on the content class semantics. Though the - qos method could in principle apply to both peers, it is currently meaningful only - for the server. - </doc> - - <chassis name = "server" implement = "MUST" /> - <response name = "ok" /> - - <field name = "prefetch-size" domain = "long" label = "prefetch window in octets"> - <doc> - The client can request that messages be sent in advance so that when the client - finishes processing a message, the following message is already held locally, - rather than needing to be sent down the channel. Prefetching gives a performance - improvement. This field specifies the prefetch window size in octets. The server - will send a message in advance if it is equal to or smaller in size than the - available prefetch size (and also falls into other prefetch limits). May be set - to zero, meaning "no specific limit", although other prefetch limits may still - apply. The prefetch-size is ignored if the no-ack option is set. - </doc> - <rule name = "01"> - <doc> - The server MUST ignore this setting when the client is not processing any - messages - i.e. the prefetch size does not limit the transfer of single - messages to a client, only the sending in advance of more messages while - the client still has one or more unacknowledged messages. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and send a single message that exceeds - that limit. Verify that the message arrives correctly. - </doc> - </rule> - </field> - - <field name = "prefetch-count" domain = "short" label = "prefetch window in messages"> - <doc> - Specifies a prefetch window in terms of whole messages. This field may be used - in combination with the prefetch-size field; a message will only be sent in - advance if both prefetch windows (and those at the channel and connection level) - allow it. The prefetch-count is ignored if the no-ack option is set. - </doc> - <rule name = "01"> - <doc> - The server may send less data in advance than allowed by the client's - specified prefetch windows but it MUST NOT send more. - </doc> - <doc type = "scenario"> - Define a QoS prefetch-size limit and a prefetch-count limit greater than - one. Send multiple messages that exceed the prefetch size. Verify that - no more than one message arrives at once. - </doc> - </rule> - </field> - - <field name = "global" domain = "bit" label = "apply to entire connection"> - <doc> - By default the QoS settings apply to the current channel only. If this field is - set, they are applied to the entire connection. - </doc> - </field> - </method> - - <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <!-- === Responses === --> - - <method name = "ok" index = "500" label = "[WORK IN PROGRESS] normal completion"> - <doc> - [WORK IN PROGRESS] Signals the normal completion of a method. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "empty" index = "510" label = "[WORK IN PROGRESS] empty queue"> - <doc> - [WORK IN PROGRESS] Signals that a queue does not contain any messages. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - </method> - - <method name = "reject" index = "520" label = "[WORK IN PROGRESS] reject a message"> - <doc> - [WORK IN PROGRESS] This response rejects a message. A message may be rejected for - a number of reasons. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <field name = "code" domain = "reject-code" /> - <field name = "text" domain = "reject-text" /> - </method> - - <method name = "offset" index = "530" label = "[WORK IN PROGRESS] return an offset"> - <doc> - [WORK IN PROGRESS] Returns the data offset into a reference body. - </doc> - <chassis name = "server" implement = "MUST" /> - <chassis name = "client" implement = "MUST" /> - <field name = "value" domain = "offset" label = "offset into a reference body" /> - </method> - - </class> - -</amqp> diff --git a/qpid/specs/amqp0-8-qpid.stripped.xml b/qpid/specs/amqp0-8-qpid.stripped.xml new file mode 100644 index 0000000000..6975e17aa6 --- /dev/null +++ b/qpid/specs/amqp0-8-qpid.stripped.xml @@ -0,0 +1,784 @@ +<?xml version="1.0"?> + +<!-- +(c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy +Technologies Inc., iMatix Corporation, IONA\ufffd Technologies, Red +Hat, Inc., TWIST Process Innovations, and 29West Inc. 2006. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="8" minor="0" port="5672"> + <constant name="frame method" value="1"/> + <constant name="frame header" value="2"/> + <constant name="frame body" value="3"/> + <constant name="frame oob method" value="4"/> + <constant name="frame oob header" value="5"/> + <constant name="frame oob body" value="6"/> + <constant name="frame trace" value="7"/> + <constant name="frame heartbeat" value="8"/> + <constant name="frame min size" value="4096"/> + <constant name="frame end" value="206"/> + <constant name="reply success" value="200"/> + <constant name="not delivered" value="310" class="soft error"/> + <constant name="content too large" value="311" class="soft error"/> + <constant name="connection forced" value="320" class="hard error"/> + <constant name="invalid path" value="402" class="hard error"/> + <constant name="access refused" value="403" class="soft error"/> + <constant name="not found" value="404" class="soft error"/> + <constant name="resource locked" value="405" class="soft error"/> + <constant name="frame error" value="501" class="hard error"/> + <constant name="syntax error" value="502" class="hard error"/> + <constant name="command invalid" value="503" class="hard error"/> + <constant name="channel error" value="504" class="hard error"/> + <constant name="resource error" value="506" class="hard error"/> + <constant name="not allowed" value="530" class="hard error"/> + <constant name="not implemented" value="540" class="hard error"/> + <constant name="internal error" value="541" class="hard error"/> + <domain name="access ticket" type="short"> + <assert check="ne" value="0"/> + </domain> + <domain name="class id" type="short"/> + <domain name="consumer tag" type="shortstr"/> + <domain name="delivery tag" type="longlong"/> + <domain name="exchange name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="known hosts" type="shortstr"/> + <domain name="method id" type="short"/> + <domain name="no ack" type="bit"/> + <domain name="no local" type="bit"/> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="syntax" rule="path"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer properties" type="table"/> + <domain name="queue name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="reply code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply text" type="shortstr"> + <assert check="notnull"/> + </domain> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version major" type="octet"/> + <field name="version minor" type="octet"/> + <field name="server properties" domain="peer properties"/> + <field name="mechanisms" type="longstr"> + <see name="security mechanisms"/> + <assert check="notnull"/> + </field> + <field name="locales" type="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client properties" domain="peer properties"/> + <field name="mechanism" type="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" type="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" type="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="longstr"> + <see name="security mechanisms"/> + </field> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" type="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel max" type="short"/> + <field name="frame max" type="long"/> + <field name="heartbeat" type="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel max" type="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel max"/> + </field> + <field name="frame max" type="long"/> + <field name="heartbeat" type="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual host" domain="path"> + <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> + </field> + <field name="capabilities" type="shortstr"/> + <field name="insist" type="bit"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known hosts" domain="known hosts"/> + </method> + <method name="redirect" synchronous="1" index="50"> + <chassis name="client" implement="MAY"/> + <field name="host" type="shortstr"> + <assert check="notnull"/> + </field> + <field name="known hosts" domain="known hosts"/> + </method> + <method name="close" synchronous="1" index="60"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="class id" domain="class id"/> + <!-- Qpid difference : correct the domain --> + <field name="method id" domain="method id"/> + </method> + <method name="close-ok" synchronous="1" index="61"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out of band" type="shortstr"> + <assert check="null"/> + </field> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" type="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" type="bit"/> + </method> + <method name="alert" index="30"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="details" type="table"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="class id" domain="class id"/> + <field name="method id" domain="method id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="access" handler="connection" index="30"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="request" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="request-ok"/> + <field name="realm" domain="path"/> + <field name="exclusive" type="bit"/> + <field name="passive" type="bit"/> + <field name="active" type="bit"/> + <field name="write" type="bit"/> + <field name="read" type="bit"/> + </method> + <method name="request-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="type" type="shortstr"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="passive" type="bit"/> + <field name="durable" type="bit"/> + <field name="auto delete" type="bit"/> + <field name="internal" type="bit"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"> + <assert check="notnull"/> + </field> + <field name="if unused" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <!-- Qpid specific addition --> + <method name="bound" synchronous="1" index="22"> + <chassis name="server" implement="SHOULD"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="queue" domain="queue name"/> + </method> + <method name="bound-ok" synchronous="1" index="23"> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <chassis name="client" implement="SHOULD"/> + </method> + <!-- End Qpid specific addition --> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </field> + <field name="passive" type="bit"/> + <field name="durable" type="bit"/> + <field name="exclusive" type="bit"/> + <field name="auto delete" type="bit"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue name"> + <assert check="notnull"/> + </field> + <field name="message count" type="long"/> + <field name="consumer count" type="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="nowait" type="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message count" type="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="if unused" type="bit"/> + <field name="if empty" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message count" type="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="delivery mode" type="octet"/> + <field name="priority" type="octet"/> + <field name="correlation id" type="shortstr"/> + <field name="reply to" type="shortstr"/> + <field name="expiration" type="shortstr"/> + <field name="message id" type="shortstr"/> + <field name="timestamp" type="timestamp"/> + <field name="type" type="shortstr"/> + <field name="user id" type="shortstr"/> + <field name="app id" type="shortstr"/> + <field name="cluster id" type="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="no ack" domain="no ack"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + <!-- Qpid specific addition : interop issue extra field --> + <field name="arguments" type="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="no ack" domain="no ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="message count" type="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster id" type="shortstr"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="multiple" type="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="requeue" type="bit"/> + </method> + <!-- Qpid specific modification : interop issue, added synchronous reply --> + <method name="recover" index="100"> + <chassis name="server" implement="MUST"/> + <field name="requeue" type="bit"/> + <response name="recover-ok"/> + </method> + <method name="recover-ok" synchronous="1" index="101"> + <chassis name="client" implement="MUST"/> + </method> + <!-- End Qpid specific modification --> + </class> + <class name="file" handler="channel" index="70"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="priority" type="octet"/> + <field name="reply to" type="shortstr"/> + <field name="message id" type="shortstr"/> + <field name="filename" type="shortstr"/> + <field name="timestamp" type="timestamp"/> + <field name="cluster id" type="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="no ack" domain="no ack"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="open" synchronous="1" index="40"> + <response name="open-ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="identifier" type="shortstr"/> + <field name="content size" type="longlong"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <response name="stage"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="staged size" type="longlong"/> + </method> + <method name="stage" content="1" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="publish" index="60"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + <field name="identifier" type="shortstr"/> + </method> + <method name="return" content="1" index="70"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" index="80"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="identifier" type="shortstr"/> + </method> + <method name="ack" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="multiple" type="bit"/> + </method> + <method name="reject" index="100"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="requeue" type="bit"/> + </method> + </class> + <class name="stream" handler="channel" index="80"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="priority" type="octet"/> + <field name="timestamp" type="timestamp"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="consume rate" type="long"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="exchange" domain="exchange name"/> + <field name="queue" domain="queue name"> + <assert check="notnull"/> + </field> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="dtx" handler="channel" index="100"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="start" synchronous="1" index="20"> + <chassis name="server" implement="MAY"/> + <response name="start-ok"/> + <field name="dtx identifier" type="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tunnel" handler="tunnel" index="110"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="headers" type="table"/> + <field name="proxy name" type="shortstr"/> + <field name="data name" type="shortstr"/> + <field name="durable" type="octet"/> + <field name="broadcast" type="octet"/> + <method name="request" content="1" index="10"> + <chassis name="server" implement="MUST"/> + <field name="meta data" type="table"/> + </method> + </class> + <class name="test" handler="channel" index="120"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="SHOULD"/> + <method name="integer" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="integer-ok"/> + <field name="integer 1" type="octet"/> + <field name="integer 2" type="short"/> + <field name="integer 3" type="long"/> + <field name="integer 4" type="longlong"/> + <field name="operation" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="integer-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="result" type="longlong"/> + </method> + <method name="string" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="string-ok"/> + <field name="string 1" type="shortstr"/> + <field name="string 2" type="longstr"/> + <field name="operation" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="string-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="result" type="longstr"/> + </method> + <method name="table" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="table-ok"/> + <field name="table" type="table"/> + <field name="integer op" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + <field name="string op" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="table-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="integer result" type="longlong"/> + <field name="string result" type="longstr"/> + </method> + <method name="content" synchronous="1" content="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="content-ok"/> + </method> + <method name="content-ok" synchronous="1" content="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="content checksum" type="long"/> + </method> + </class> +</amqp> diff --git a/qpid/specs/amqp0-8.stripped.xml b/qpid/specs/amqp0-8.stripped.xml new file mode 100644 index 0000000000..c8497db07b --- /dev/null +++ b/qpid/specs/amqp0-8.stripped.xml @@ -0,0 +1,759 @@ +<?xml version="1.0"?> +<!-- +Copyright (c) 2009 AMQP Working Group. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> +<amqp major="8" minor="0" port="5672"> + <constant name="frame method" value="1"/> + <constant name="frame header" value="2"/> + <constant name="frame body" value="3"/> + <constant name="frame oob method" value="4"/> + <constant name="frame oob header" value="5"/> + <constant name="frame oob body" value="6"/> + <constant name="frame trace" value="7"/> + <constant name="frame heartbeat" value="8"/> + <constant name="frame min size" value="4096"/> + <constant name="frame end" value="206"/> + <constant name="reply success" value="200"/> + <constant name="not delivered" value="310" class="soft error"/> + <constant name="content too large" value="311" class="soft error"/> + <constant name="connection forced" value="320" class="hard error"/> + <constant name="invalid path" value="402" class="hard error"/> + <constant name="access refused" value="403" class="soft error"/> + <constant name="not found" value="404" class="soft error"/> + <constant name="resource locked" value="405" class="soft error"/> + <constant name="frame error" value="501" class="hard error"/> + <constant name="syntax error" value="502" class="hard error"/> + <constant name="command invalid" value="503" class="hard error"/> + <constant name="channel error" value="504" class="hard error"/> + <constant name="resource error" value="506" class="hard error"/> + <constant name="not allowed" value="530" class="hard error"/> + <constant name="not implemented" value="540" class="hard error"/> + <constant name="internal error" value="541" class="hard error"/> + <domain name="access ticket" type="short"> + <assert check="ne" value="0"/> + </domain> + <domain name="class id" type="short"/> + <domain name="consumer tag" type="shortstr"/> + <domain name="delivery tag" type="longlong"/> + <domain name="exchange name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="known hosts" type="shortstr"/> + <domain name="method id" type="short"/> + <domain name="no ack" type="bit"/> + <domain name="no local" type="bit"/> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="syntax" rule="path"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer properties" type="table"/> + <domain name="queue name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="reply code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply text" type="shortstr"> + <assert check="notnull"/> + </domain> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version major" type="octet"/> + <field name="version minor" type="octet"/> + <field name="server properties" domain="peer properties"/> + <field name="mechanisms" type="longstr"> + <see name="security mechanisms"/> + <assert check="notnull"/> + </field> + <field name="locales" type="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client properties" domain="peer properties"/> + <field name="mechanism" type="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" type="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" type="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" type="longstr"> + <see name="security mechanisms"/> + </field> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" type="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel max" type="short"/> + <field name="frame max" type="long"/> + <field name="heartbeat" type="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel max" type="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel max"/> + </field> + <field name="frame max" type="long"/> + <field name="heartbeat" type="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual host" domain="path"> + <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> + </field> + <field name="capabilities" type="shortstr"/> + <field name="insist" type="bit"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known hosts" domain="known hosts"/> + </method> + <method name="redirect" synchronous="1" index="50"> + <chassis name="client" implement="MAY"/> + <field name="host" type="shortstr"> + <assert check="notnull"/> + </field> + <field name="known hosts" domain="known hosts"/> + </method> + <method name="close" synchronous="1" index="60"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="class id" domain="class id"/> + <field name="method id" domain="class id"/> + </method> + <method name="close-ok" synchronous="1" index="61"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out of band" type="shortstr"> + <assert check="null"/> + </field> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" type="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" type="bit"/> + </method> + <method name="alert" index="30"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="details" type="table"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="class id" domain="class id"/> + <field name="method id" domain="method id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="access" handler="connection" index="30"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="request" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="request-ok"/> + <field name="realm" domain="path"/> + <field name="exclusive" type="bit"/> + <field name="passive" type="bit"/> + <field name="active" type="bit"/> + <field name="write" type="bit"/> + <field name="read" type="bit"/> + </method> + <method name="request-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="type" type="shortstr"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="passive" type="bit"/> + <field name="durable" type="bit"/> + <field name="auto delete" type="bit"/> + <field name="internal" type="bit"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"> + <assert check="notnull"/> + </field> + <field name="if unused" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </field> + <field name="passive" type="bit"/> + <field name="durable" type="bit"/> + <field name="exclusive" type="bit"/> + <field name="auto delete" type="bit"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue name"> + <assert check="notnull"/> + </field> + <field name="message count" type="long"/> + <field name="consumer count" type="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="nowait" type="bit"/> + <field name="arguments" type="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="nowait" type="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message count" type="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="if unused" type="bit"/> + <field name="if empty" type="bit"> + <test/> + </field> + <field name="nowait" type="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message count" type="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="delivery mode" type="octet"/> + <field name="priority" type="octet"/> + <field name="correlation id" type="shortstr"/> + <field name="reply to" type="shortstr"/> + <field name="expiration" type="shortstr"/> + <field name="message id" type="shortstr"/> + <field name="timestamp" type="timestamp"/> + <field name="type" type="shortstr"/> + <field name="user id" type="shortstr"/> + <field name="app id" type="shortstr"/> + <field name="cluster id" type="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="no ack" domain="no ack"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="no ack" domain="no ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="message count" type="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster id" type="shortstr"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="multiple" type="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="requeue" type="bit"/> + </method> + <method name="recover" index="100"> + <chassis name="server" implement="MUST"/> + <field name="requeue" type="bit"/> + </method> + </class> + <class name="file" handler="channel" index="70"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="priority" type="octet"/> + <field name="reply to" type="shortstr"/> + <field name="message id" type="shortstr"/> + <field name="filename" type="shortstr"/> + <field name="timestamp" type="timestamp"/> + <field name="cluster id" type="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="no ack" domain="no ack"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="open" synchronous="1" index="40"> + <response name="open-ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="identifier" type="shortstr"/> + <field name="content size" type="longlong"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <response name="stage"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="staged size" type="longlong"/> + </method> + <method name="stage" content="1" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="publish" index="60"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + <field name="identifier" type="shortstr"/> + </method> + <method name="return" content="1" index="70"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" index="80"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="identifier" type="shortstr"/> + </method> + <method name="ack" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="multiple" type="bit"/> + </method> + <method name="reject" index="100"> + <chassis name="server" implement="MUST"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="requeue" type="bit"/> + </method> + </class> + <class name="stream" handler="channel" index="80"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content type" type="shortstr"/> + <field name="content encoding" type="shortstr"/> + <field name="headers" type="table"/> + <field name="priority" type="octet"/> + <field name="timestamp" type="timestamp"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch size" type="long"/> + <field name="prefetch count" type="short"/> + <field name="consume rate" type="long"/> + <field name="global" type="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access ticket"/> + <field name="queue" domain="queue name"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="no local" domain="no local"/> + <field name="exclusive" type="bit"/> + <field name="nowait" type="bit"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="nowait" type="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access ticket"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + <field name="mandatory" type="bit"/> + <field name="immediate" type="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply code" domain="reply code"/> + <field name="reply text" domain="reply text"/> + <field name="exchange" domain="exchange name"/> + <field name="routing key" type="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer tag" domain="consumer tag"/> + <field name="delivery tag" domain="delivery tag"/> + <field name="exchange" domain="exchange name"/> + <field name="queue" domain="queue name"> + <assert check="notnull"/> + </field> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="dtx" handler="channel" index="100"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="start" synchronous="1" index="20"> + <chassis name="server" implement="MAY"/> + <response name="start-ok"/> + <field name="dtx identifier" type="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tunnel" handler="tunnel" index="110"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="headers" type="table"/> + <field name="proxy name" type="shortstr"/> + <field name="data name" type="shortstr"/> + <field name="durable" type="octet"/> + <field name="broadcast" type="octet"/> + <method name="request" content="1" index="10"> + <chassis name="server" implement="MUST"/> + <field name="meta data" type="table"/> + </method> + </class> + <class name="test" handler="channel" index="120"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="SHOULD"/> + <method name="integer" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="integer-ok"/> + <field name="integer 1" type="octet"/> + <field name="integer 2" type="short"/> + <field name="integer 3" type="long"/> + <field name="integer 4" type="longlong"/> + <field name="operation" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="integer-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="result" type="longlong"/> + </method> + <method name="string" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="string-ok"/> + <field name="string 1" type="shortstr"/> + <field name="string 2" type="longstr"/> + <field name="operation" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="string-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="result" type="longstr"/> + </method> + <method name="table" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="table-ok"/> + <field name="table" type="table"/> + <field name="integer op" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + <field name="string op" type="octet"> + <assert check="enum"> + <value name="add"/> + <value name="min"/> + <value name="max"/> + </assert> + </field> + </method> + <method name="table-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="integer result" type="longlong"/> + <field name="string result" type="longstr"/> + </method> + <method name="content" synchronous="1" content="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="content-ok"/> + </method> + <method name="content-ok" synchronous="1" content="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <field name="content checksum" type="long"/> + </method> + </class> +</amqp> diff --git a/qpid/specs/amqp0-9-qpid.stripped.xml b/qpid/specs/amqp0-9-qpid.stripped.xml new file mode 100644 index 0000000000..e0075870de --- /dev/null +++ b/qpid/specs/amqp0-9-qpid.stripped.xml @@ -0,0 +1,876 @@ +<?xml version="1.0"?> + +<!-- +(c) Copyright JPMorgan Chase Bank & Co., Cisco Systems, Inc., Envoy +Technologies Inc., iMatix Corporation, IONA\ufffd Technologies, Red +Hat, Inc., TWIST Process Innovations, and 29West Inc. 2006. + +Copyright (c) 2009 AMQP Working Group. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> + +<amqp major="0" minor="9" port="5672"> + <constant name="frame-method" value="1"/> + <constant name="frame-header" value="2"/> + <constant name="frame-body" value="3"/> + <constant name="frame-oob-method" value="4"/> + <constant name="frame-oob-header" value="5"/> + <constant name="frame-oob-body" value="6"/> + <constant name="frame-trace" value="7"/> + <constant name="frame-heartbeat" value="8"/> + <constant name="frame-min-size" value="4096"/> + <constant name="frame-end" value="206"/> + <constant name="reply-success" value="200"/> + <constant name="not-delivered" value="310" class="soft-error"/> + <constant name="content-too-large" value="311" class="soft-error"/> + <constant name="no-route" value="312" class="soft-error"/> + <constant name="no-consumers" value="313" class="soft-error"/> + <constant name="connection-forced" value="320" class="hard-error"/> + <constant name="invalid-path" value="402" class="hard-error"/> + <constant name="access-refused" value="403" class="soft-error"/> + <constant name="not-found" value="404" class="soft-error"/> + <constant name="resource-locked" value="405" class="soft-error"/> + <constant name="precondition-failed" value="406" class="soft-error"/> + <constant name="frame-error" value="501" class="hard-error"/> + <constant name="syntax-error" value="502" class="hard-error"/> + <constant name="command-invalid" value="503" class="hard-error"/> + <constant name="channel-error" value="504" class="hard-error"/> + <constant name="resource-error" value="506" class="hard-error"/> + <constant name="not-allowed" value="530" class="hard-error"/> + <constant name="not-implemented" value="540" class="hard-error"/> + <constant name="internal-error" value="541" class="hard-error"/> + <domain name="access-ticket" type="short"> + <assert check="ne" value="0"/> + </domain> + <domain name="class-id" type="short"/> + <domain name="consumer-tag" type="shortstr"/> + <domain name="delivery-tag" type="longlong"/> + <domain name="exchange-name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="known-hosts" type="shortstr"/> + <domain name="method-id" type="short"/> + <domain name="no-ack" type="bit"/> + <domain name="no-local" type="bit"/> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="syntax" rule="path"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer-properties" type="table"/> + <domain name="queue-name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="reply-code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply-text" type="shortstr"> + <assert check="notnull"/> + </domain> + <domain name="channel-id" type="longstr"/> + <domain name="duration" type="longlong"/> + <domain name="offset" type="longlong"/> + <domain name="reference" type="longstr"/> + <domain name="destination" type="shortstr"/> + <domain name="reject-code" type="short"/> + <domain name="reject-text" type="shortstr"/> + <domain name="security-token" type="longstr"/> + <domain name="bit" type="bit"/> + <domain name="octet" type="octet"/> + <domain name="short" type="short"/> + <domain name="long" type="long"/> + <domain name="longlong" type="longlong"/> + <domain name="shortstr" type="shortstr"/> + <domain name="longstr" type="longstr"/> + <domain name="timestamp" type="timestamp"/> + <domain name="table" type="table"/> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version-major" domain="octet"/> + <field name="version-minor" domain="octet"/> + <field name="server-properties" domain="peer-properties"/> + <field name="mechanisms" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locales" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client-properties" domain="peer-properties"/> + <field name="mechanism" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" domain="longstr"/> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" domain="short"/> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel-max" domain="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel-max"/> + </field> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" domain="path"> + <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> + </field> + <field name="capabilities" domain="shortstr"/> + <field name="insist" domain="bit"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known-hosts" domain="known-hosts"/> + </method> + <method name="redirect" synchronous="1" index="42"> + <chassis name="client" implement="MUST"/> + <field name="host" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="known-hosts" domain="known-hosts"/> + </method> + <method name="close" synchronous="1" index="50"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out-of-band" domain="shortstr"> + <assert check="null"/> + </field> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="channel-id" domain="channel-id"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" domain="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" domain="bit"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + <method name="resume" index="50"> + <response name="ok"/> + <chassis name="server" implement="MAY"/> + <field name="channel-id" domain="channel-id"/> + </method> + <method name="ping" index="60"> + <response name="ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="pong" index="70"> + <response name="ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="ok" index="80"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="access" handler="connection" index="30"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="request" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="request-ok"/> + <field name="realm" domain="shortstr"/> + <field name="exclusive" domain="bit"/> + <field name="passive" domain="bit"/> + <field name="active" domain="bit"/> + <field name="write" domain="bit"/> + <field name="read" domain="bit"/> + </method> + <method name="request-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="type" domain="shortstr"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="internal" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"> + <assert check="notnull"/> + </field> + <field name="if-unused" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <!-- Qpid specific addition --> + <method name="bound" synchronous="1" index="22"> + <chassis name="server" implement="SHOULD"/> + <response name="bound-ok"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" type="shortstr"/> + <field name="queue" domain="queue name"/> + </method> + <method name="bound-ok" synchronous="1" index="23"> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <chassis name="client" implement="SHOULD"/> + </method> + <!-- End Qpid specific addition --> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </field> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="exclusive" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="nowait" domain="bit"/> + <!-- Qpid diff - this field is known as filter in the original 0-9, + however since the name does not go on the wire, there is no + interop implication --> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + <field name="message-count" domain="long"/> + <field name="consumer-count" domain="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="unbind" synchronous="1" index="50"> + <chassis name="server" implement="MUST"/> + <response name="unbind-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="arguments" domain="table"/> + </method> + <method name="unbind-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="nowait" domain="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="if-unused" domain="bit"/> + <field name="if-empty" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="delivery-mode" domain="octet"/> + <field name="priority" domain="octet"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="expiration" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="type" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="cluster-id" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-count" domain="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster-id" domain="shortstr"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + <method name="recover" index="100"> + <chassis name="server" implement="MUST"/> + <field name="requeue" domain="bit"/> + </method> + <!-- Qpid specific addition --> + <method name="recover-sync" index="102"> + <chassis name="server" implement="MUST"/> + <field name="requeue" type="bit"/> + <response name="recover-sync-ok"/> + </method> + <method name="recover-sync-ok" synchronous="1" index="101"> + <chassis name="client" implement="MUST"/> + </method> + <!-- End Qpid specific addition --> + </class> + <class name="file" handler="channel" index="70"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="priority" domain="octet"/> + <field name="reply-to" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="filename" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="cluster-id" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <response name="cancel-ok"/> + <chassis name="server" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="open" synchronous="1" index="40"> + <response name="open-ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="identifier" domain="shortstr"/> + <field name="content-size" domain="longlong"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <response name="stage"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="staged-size" domain="longlong"/> + </method> + <method name="stage" content="1" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="publish" index="60"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="return" content="1" index="70"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" index="80"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="ack" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="100"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + </class> + <class name="stream" handler="channel" index="80"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="priority" domain="octet"/> + <field name="timestamp" domain="timestamp"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="consume-rate" domain="long"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="exchange" domain="exchange-name"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="dtx" handler="channel" index="100"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="start" synchronous="1" index="20"> + <chassis name="server" implement="MAY"/> + <response name="start-ok"/> + <field name="dtx-identifier" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tunnel" handler="tunnel" index="110"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="headers" domain="table"/> + <field name="proxy-name" domain="shortstr"/> + <field name="data-name" domain="shortstr"/> + <field name="durable" domain="octet"/> + <field name="broadcast" domain="octet"/> + <method name="request" content="1" index="10"> + <chassis name="server" implement="MUST"/> + <field name="meta-data" domain="table"/> + </method> + </class> + <class name="message" handler="channel" index="120"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="transfer" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <response name="reject"/> + <field name="ticket" domain="access-ticket"/> + <field name="destination" domain="destination"/> + <field name="redelivered" domain="redelivered"/> + <field name="immediate" domain="bit"/> + <field name="ttl" domain="duration"/> + <field name="priority" domain="octet"/> + <field name="timestamp" domain="timestamp"/> + <field name="delivery-mode" domain="octet"/> + <field name="expiration" domain="timestamp"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="transaction-id" domain="shortstr"/> + <field name="security-token" domain="security-token"/> + <field name="application-headers" domain="table"/> + <field name="body" domain="content"/> + </method> + <method name="consume" index="20"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="destination" domain="destination"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="cancel" index="30"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="destination" domain="destination"/> + </method> + <method name="get" index="40"> + <response name="ok"/> + <response name="empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="destination" domain="destination"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="recover" index="50"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="requeue" domain="bit"/> + </method> + <method name="open" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + </method> + <method name="close" index="70"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + </method> + <method name="append" index="80"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + <field name="bytes" domain="longstr"/> + </method> + <method name="checkpoint" index="90"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="resume" index="100"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="offset"/> + <field name="reference" domain="reference"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="qos" index="110"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="ok" index="500"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="empty" index="510"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="reject" index="520"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="code" domain="reject-code"/> + <field name="text" domain="reject-text"/> + </method> + <method name="offset" index="530"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="value" domain="offset"/> + </method> + </class> +</amqp> diff --git a/qpid/specs/amqp0-9.stripped.xml b/qpid/specs/amqp0-9.stripped.xml new file mode 100644 index 0000000000..5233332b68 --- /dev/null +++ b/qpid/specs/amqp0-9.stripped.xml @@ -0,0 +1,844 @@ +<?xml version="1.0"?> +<!-- +Copyright (c) 2009 AMQP Working Group. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: +1. Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in the +documentation and/or other materials provided with the distribution. +3. The name of the author may not be used to endorse or promote products +derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR +IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES +OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. +IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT +NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +--> +<amqp major="0" minor="9" port="5672"> + <constant name="frame-method" value="1"/> + <constant name="frame-header" value="2"/> + <constant name="frame-body" value="3"/> + <constant name="frame-oob-method" value="4"/> + <constant name="frame-oob-header" value="5"/> + <constant name="frame-oob-body" value="6"/> + <constant name="frame-trace" value="7"/> + <constant name="frame-heartbeat" value="8"/> + <constant name="frame-min-size" value="4096"/> + <constant name="frame-end" value="206"/> + <constant name="reply-success" value="200"/> + <constant name="not-delivered" value="310" class="soft-error"/> + <constant name="content-too-large" value="311" class="soft-error"/> + <constant name="no-route" value="312" class="soft-error"/> + <constant name="no-consumers" value="313" class="soft-error"/> + <constant name="connection-forced" value="320" class="hard-error"/> + <constant name="invalid-path" value="402" class="hard-error"/> + <constant name="access-refused" value="403" class="soft-error"/> + <constant name="not-found" value="404" class="soft-error"/> + <constant name="resource-locked" value="405" class="soft-error"/> + <constant name="precondition-failed" value="406" class="soft-error"/> + <constant name="frame-error" value="501" class="hard-error"/> + <constant name="syntax-error" value="502" class="hard-error"/> + <constant name="command-invalid" value="503" class="hard-error"/> + <constant name="channel-error" value="504" class="hard-error"/> + <constant name="resource-error" value="506" class="hard-error"/> + <constant name="not-allowed" value="530" class="hard-error"/> + <constant name="not-implemented" value="540" class="hard-error"/> + <constant name="internal-error" value="541" class="hard-error"/> + <domain name="access-ticket" type="short"> + <assert check="ne" value="0"/> + </domain> + <domain name="class-id" type="short"/> + <domain name="consumer-tag" type="shortstr"/> + <domain name="delivery-tag" type="longlong"/> + <domain name="exchange-name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="known-hosts" type="shortstr"/> + <domain name="method-id" type="short"/> + <domain name="no-ack" type="bit"/> + <domain name="no-local" type="bit"/> + <domain name="path" type="shortstr"> + <assert check="notnull"/> + <assert check="syntax" rule="path"/> + <assert check="length" value="127"/> + </domain> + <domain name="peer-properties" type="table"/> + <domain name="queue-name" type="shortstr"> + <assert check="length" value="127"/> + </domain> + <domain name="redelivered" type="bit"/> + <domain name="reply-code" type="short"> + <assert check="notnull"/> + </domain> + <domain name="reply-text" type="shortstr"> + <assert check="notnull"/> + </domain> + <domain name="channel-id" type="longstr"/> + <domain name="duration" type="longlong"/> + <domain name="offset" type="longlong"/> + <domain name="reference" type="longstr"/> + <domain name="destination" type="shortstr"/> + <domain name="reject-code" type="short"/> + <domain name="reject-text" type="shortstr"/> + <domain name="security-token" type="longstr"/> + <domain name="bit" type="bit"/> + <domain name="octet" type="octet"/> + <domain name="short" type="short"/> + <domain name="long" type="long"/> + <domain name="longlong" type="longlong"/> + <domain name="shortstr" type="shortstr"/> + <domain name="longstr" type="longstr"/> + <domain name="timestamp" type="timestamp"/> + <domain name="table" type="table"/> + <class name="connection" handler="connection" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="start" synchronous="1" index="10"> + <chassis name="client" implement="MUST"/> + <response name="start-ok"/> + <field name="version-major" domain="octet"/> + <field name="version-minor" domain="octet"/> + <field name="server-properties" domain="peer-properties"/> + <field name="mechanisms" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locales" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="11"> + <chassis name="server" implement="MUST"/> + <field name="client-properties" domain="peer-properties"/> + <field name="mechanism" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + <field name="locale" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="secure" synchronous="1" index="20"> + <chassis name="client" implement="MUST"/> + <response name="secure-ok"/> + <field name="challenge" domain="longstr"/> + </method> + <method name="secure-ok" synchronous="1" index="21"> + <chassis name="server" implement="MUST"/> + <field name="response" domain="longstr"> + <assert check="notnull"/> + </field> + </method> + <method name="tune" synchronous="1" index="30"> + <chassis name="client" implement="MUST"/> + <response name="tune-ok"/> + <field name="channel-max" domain="short"/> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="tune-ok" synchronous="1" index="31"> + <chassis name="server" implement="MUST"/> + <field name="channel-max" domain="short"> + <assert check="notnull"/> + <assert check="le" method="tune" field="channel-max"/> + </field> + <field name="frame-max" domain="long"/> + <field name="heartbeat" domain="short"/> + </method> + <method name="open" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <response name="redirect"/> + <field name="virtual-host" domain="path"> + <assert check="regexp" value="^[a-zA-Z0-9/-_]+$"/> + </field> + <field name="capabilities" domain="shortstr"/> + <field name="insist" domain="bit"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="known-hosts" domain="known-hosts"/> + </method> + <method name="redirect" synchronous="1" index="42"> + <chassis name="client" implement="MUST"/> + <field name="host" domain="shortstr"> + <assert check="notnull"/> + </field> + <field name="known-hosts" domain="known-hosts"/> + </method> + <method name="close" synchronous="1" index="50"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + </class> + <class name="channel" handler="channel" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="open" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="open-ok"/> + <field name="out-of-band" domain="shortstr"> + <assert check="null"/> + </field> + </method> + <method name="open-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="channel-id" domain="channel-id"/> + </method> + <method name="flow" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="flow-ok"/> + <field name="active" domain="bit"/> + </method> + <method name="flow-ok" index="21"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="active" domain="bit"/> + </method> + <method name="close" synchronous="1" index="40"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + <response name="close-ok"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="class-id" domain="class-id"/> + <field name="method-id" domain="method-id"/> + </method> + <method name="close-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <chassis name="server" implement="MUST"/> + </method> + <method name="resume" index="50"> + <response name="ok"/> + <chassis name="server" implement="MAY"/> + <field name="channel-id" domain="channel-id"/> + </method> + <method name="ping" index="60"> + <response name="ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="pong" index="70"> + <response name="ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="ok" index="80"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="access" handler="connection" index="30"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="request" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="request-ok"/> + <field name="realm" domain="shortstr"/> + <field name="exclusive" domain="bit"/> + <field name="passive" domain="bit"/> + <field name="active" domain="bit"/> + <field name="write" domain="bit"/> + <field name="read" domain="bit"/> + </method> + <method name="request-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + </method> + </class> + <class name="exchange" handler="channel" index="40"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="type" domain="shortstr"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/> + </field> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="internal" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="delete" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"> + <assert check="notnull"/> + </field> + <field name="if-unused" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="queue" handler="channel" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="declare" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="declare-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"> + <assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/> + </field> + <field name="passive" domain="bit"/> + <field name="durable" domain="bit"/> + <field name="exclusive" domain="bit"/> + <field name="auto-delete" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="declare-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + <field name="message-count" domain="long"/> + <field name="consumer-count" domain="long"/> + </method> + <method name="bind" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="bind-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="nowait" domain="bit"/> + <field name="arguments" domain="table"/> + </method> + <method name="bind-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="unbind" synchronous="1" index="50"> + <chassis name="server" implement="MUST"/> + <response name="unbind-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="arguments" domain="table"/> + </method> + <method name="unbind-ok" synchronous="1" index="51"> + <chassis name="client" implement="MUST"/> + </method> + <method name="purge" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="purge-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="nowait" domain="bit"/> + </method> + <method name="purge-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + <method name="delete" synchronous="1" index="40"> + <chassis name="server" implement="MUST"/> + <response name="delete-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="if-unused" domain="bit"/> + <field name="if-empty" domain="bit"/> + <field name="nowait" domain="bit"/> + </method> + <method name="delete-ok" synchronous="1" index="41"> + <chassis name="client" implement="MUST"/> + <field name="message-count" domain="long"/> + </method> + </class> + <class name="basic" handler="channel" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="delivery-mode" domain="octet"/> + <field name="priority" domain="octet"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="expiration" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="type" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="cluster-id" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="get" synchronous="1" index="70"> + <response name="get-ok"/> + <response name="get-empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="get-ok" synchronous="1" content="1" index="71"> + <chassis name="client" implement="MAY"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-count" domain="long"/> + </method> + <method name="get-empty" synchronous="1" index="72"> + <chassis name="client" implement="MAY"/> + <field name="cluster-id" domain="shortstr"/> + </method> + <method name="ack" index="80"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + <method name="recover" index="100"> + <chassis name="server" implement="MUST"/> + <field name="requeue" domain="bit"/> + </method> + </class> + <class name="file" handler="channel" index="70"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="priority" domain="octet"/> + <field name="reply-to" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="filename" domain="shortstr"/> + <field name="timestamp" domain="timestamp"/> + <field name="cluster-id" domain="shortstr"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <response name="cancel-ok"/> + <chassis name="server" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="open" synchronous="1" index="40"> + <response name="open-ok"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="identifier" domain="shortstr"/> + <field name="content-size" domain="longlong"/> + </method> + <method name="open-ok" synchronous="1" index="41"> + <response name="stage"/> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="staged-size" domain="longlong"/> + </method> + <method name="stage" content="1" index="50"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="publish" index="60"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="return" content="1" index="70"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" index="80"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="redelivered" domain="redelivered"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="ack" index="90"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="multiple" domain="bit"/> + </method> + <method name="reject" index="100"> + <chassis name="server" implement="MUST"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="requeue" domain="bit"/> + </method> + </class> + <class name="stream" handler="channel" index="80"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="headers" domain="table"/> + <field name="priority" domain="octet"/> + <field name="timestamp" domain="timestamp"/> + <method name="qos" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="qos-ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="consume-rate" domain="long"/> + <field name="global" domain="bit"/> + </method> + <method name="qos-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="consume" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="consume-ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="no-local" domain="no-local"/> + <field name="exclusive" domain="bit"/> + <field name="nowait" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="consume-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="cancel" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="cancel-ok"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="nowait" domain="bit"/> + </method> + <method name="cancel-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + </method> + <method name="publish" content="1" index="40"> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="mandatory" domain="bit"/> + <field name="immediate" domain="bit"/> + </method> + <method name="return" content="1" index="50"> + <chassis name="client" implement="MUST"/> + <field name="reply-code" domain="reply-code"/> + <field name="reply-text" domain="reply-text"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + </method> + <method name="deliver" content="1" index="60"> + <chassis name="client" implement="MUST"/> + <field name="consumer-tag" domain="consumer-tag"/> + <field name="delivery-tag" domain="delivery-tag"/> + <field name="exchange" domain="exchange-name"/> + <field name="queue" domain="queue-name"> + <assert check="notnull"/> + </field> + </method> + </class> + <class name="tx" handler="channel" index="90"> + <chassis name="server" implement="SHOULD"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="commit" synchronous="1" index="20"> + <chassis name="server" implement="MUST"/> + <response name="commit-ok"/> + </method> + <method name="commit-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + <method name="rollback" synchronous="1" index="30"> + <chassis name="server" implement="MUST"/> + <response name="rollback-ok"/> + </method> + <method name="rollback-ok" synchronous="1" index="31"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="dtx" handler="channel" index="100"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <method name="select" synchronous="1" index="10"> + <chassis name="server" implement="MUST"/> + <response name="select-ok"/> + </method> + <method name="select-ok" synchronous="1" index="11"> + <chassis name="client" implement="MUST"/> + </method> + <method name="start" synchronous="1" index="20"> + <chassis name="server" implement="MAY"/> + <response name="start-ok"/> + <field name="dtx-identifier" domain="shortstr"> + <assert check="notnull"/> + </field> + </method> + <method name="start-ok" synchronous="1" index="21"> + <chassis name="client" implement="MUST"/> + </method> + </class> + <class name="tunnel" handler="tunnel" index="110"> + <chassis name="server" implement="MAY"/> + <chassis name="client" implement="MAY"/> + <field name="headers" domain="table"/> + <field name="proxy-name" domain="shortstr"/> + <field name="data-name" domain="shortstr"/> + <field name="durable" domain="octet"/> + <field name="broadcast" domain="octet"/> + <method name="request" content="1" index="10"> + <chassis name="server" implement="MUST"/> + <field name="meta-data" domain="table"/> + </method> + </class> + <class name="message" index="120" handler="channel"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <method name="transfer" index="10"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <response name="reject"/> + <field name="ticket" domain="access-ticket"/> + <field name="destination" domain="destination"/> + <field name="redelivered" domain="redelivered"/> + <field name="immediate" domain="bit"/> + <field name="ttl" domain="duration"/> + <field name="priority" domain="octet"/> + <field name="timestamp" domain="timestamp"/> + <field name="delivery-mode" domain="octet"/> + <field name="expiration" domain="timestamp"/> + <field name="exchange" domain="exchange-name"/> + <field name="routing-key" domain="shortstr"/> + <field name="message-id" domain="shortstr"/> + <field name="correlation-id" domain="shortstr"/> + <field name="reply-to" domain="shortstr"/> + <field name="content-type" domain="shortstr"/> + <field name="content-encoding" domain="shortstr"/> + <field name="user-id" domain="shortstr"/> + <field name="app-id" domain="shortstr"/> + <field name="transaction-id" domain="shortstr"/> + <field name="security-token" domain="security-token"/> + <field name="application-headers" domain="table"/> + <field name="body" domain="content"/> + </method> + <method name="consume" index="20"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="destination" domain="destination"/> + <field name="no-local" domain="no-local"/> + <field name="no-ack" domain="no-ack"/> + <field name="exclusive" domain="bit"/> + <field name="filter" domain="table"/> + </method> + <method name="cancel" index="30"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="destination" domain="destination"/> + </method> + <method name="get" index="40"> + <response name="ok"/> + <response name="empty"/> + <chassis name="server" implement="MUST"/> + <field name="ticket" domain="access-ticket"/> + <field name="queue" domain="queue-name"/> + <field name="destination" domain="destination"/> + <field name="no-ack" domain="no-ack"/> + </method> + <method name="recover" index="50"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="requeue" domain="bit"/> + </method> + <method name="open" index="60"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + </method> + <method name="close" index="70"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + </method> + <method name="append" index="80"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + <field name="bytes" domain="longstr"/> + </method> + <method name="checkpoint" index="90"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="ok"/> + <field name="reference" domain="reference"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="resume" index="100"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <response name="offset"/> + <field name="reference" domain="reference"/> + <field name="identifier" domain="shortstr"/> + </method> + <method name="qos" index="110"> + <chassis name="server" implement="MUST"/> + <response name="ok"/> + <field name="prefetch-size" domain="long"/> + <field name="prefetch-count" domain="short"/> + <field name="global" domain="bit"/> + </method> + <method name="ok" index="500"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="empty" index="510"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + </method> + <method name="reject" index="520"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="code" domain="reject-code"/> + <field name="text" domain="reject-text"/> + </method> + <method name="offset" index="530"> + <chassis name="server" implement="MUST"/> + <chassis name="client" implement="MUST"/> + <field name="value" domain="offset"/> + </method> + </class> +</amqp> |