This specification is provided under the
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as
described in [
The authoritative form of this specification consists of a set of XML source documents. These documents are transformed into PDF and HTML representations for readability. The machine readable version of the AMQP DTD describes the XML used for the authoritative source documents. This DTD includes the definition of the syntax used any excerpts of XML presented in the PDF and HTML representations.
Godfrey, Robert; Ingham, David; Schloming, Rafael,
Advanced Message Queuing Protocol (AMQP) Version 1.0.
October 2012, OASIS Standard.
<
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP14, RFC2119, DOI 10.17487/RFC2119, March 1997,
<
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC2119 Key Words", BCP14, RFC8174, DOI 10.17487/RFC8174, May 2017,
<
AMQP Capabilities Registry: Connection Capabilities
AMQP Capabilities Registry: Connection Properties
When creating and sending a message AMQP defines two fields which are to be used to determine how the message should be routed:
The
A routing node acts as a proxy for links to other nodes. Messages sent over links into
a routing node will be forwarded to the node referenced in
When creating a sending link,
Since a routing node acts only as a proxy between the source and intended target nodes, it itself does not directly support the properties and capabilities but rather the intended target nodes do. Unless every target node that the routing node can route to supports the same set of properties and capabilities, it is impossible for it to accurately reply with the correct set of supported behaviors.
If a routing node receives an
It is possible that a message sent to a routing node has an address in
If the
If the
A
--------------------------------------------------------------------------------------------------
# Name # Description #
--------------------------------------------------------------------------------------------------
| ANONYMOUS-RELAY | If present in
This specification implicitly defines two roles which an AMQP container may take: a provider of the anonymous terminus, and a user of the anonymous terminus. An AMQP container may choose to implement none, one or both of these roles.
A container acting as a provider of the anonymous terminus MUST indicate this by supplying the
relevant capability in
A container acting as a user of the anonymous terminus MUST indicate this by supplying the
relevant capability in
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
--------------------- -------------------------------------------------------------------------------------------------------------
# Revision # Date # Editor # Changes Made #
-----------------------------------------------------------------------------------------------------------------------------------
| WD01 | 23-Mar-2017 | Rob Godfrey | Initial Revision |
-----------------------------------------------------------------------------------------------------------------------------------
| WD02 | 13-Apr-2017 | Rob Godfrey |