The messaging layer builds on top of the concepts described in and . The transport layer defines a number of extension points suitable for use in a variety of different messaging applications. The messaging layer specifies a standardized use of these to provide interoperable messaging capabilities. This standard covers:

  • message format

    • properties for the bare message

    • formats for structured and unstructured sections in the bare message

    • headers and footers for the annotated message

  • delivery states for messages traveling between nodes

  • states for messages stored at a distribution node

  • sources and targets

    • default disposition of transfers

    • supported outcomes

    • filtering of messages from a node

    • distribution-mode for access to messages stored at a distribution node

    • on-demand node creation

The term message is used with various connotations in the messaging world. The sender might like to think of the message as an immutable payload handed off to the messaging infrastructure for delivery. The receiver often thinks of the message as not only that immutable payload from the sender, but also various annotations supplied by the messaging infrastructure along the way. To avoid confusion we formally define the term bare message to mean the message as supplied by the sender and the term annotated message to mean the message as seen at the receiver.

An annotated message consists of the bare message plus sections for annotation at the head and tail of the bare message. There are two classes of annotations: annotations that travel with the message indefinitely, and annotations that are consumed by the next node.

The bare message consists of three sections: standard properties, application-properties, and application-data (the body).

Bare Message | .---------------------+--------------------. | | +--------+-------------+-------------+------------+--------------+--------------+--------+ | header | delivery- | message- | properties | application- | application- | footer | | | annotations | annotations | | properties | data | | +--------+-------------+-------------+------------+--------------+--------------+--------+ | | '-------------------------------------------+--------------------------------------------' | Annotated Message

The bare message is immutable within the AMQP network. That is, none of the sections can be changed by any node acting as an AMQP intermediary. If a section of the bare message is omitted, one MUST NOT be inserted by an intermediary. The exact encoding of sections of the bare message MUST NOT be modified. This preserves message hashes, HMACs and signatures based on the binary encoding of the bare message.

The exact structure of a message, together with its encoding, is defined by the message format. This document defines the structure and semantics of message format . Altogether a message consists of the following sections:

  • Zero or one header sections.

  • Zero or one delivery-annotation sections.

  • Zero or one message-annotation sections.

  • Zero or one properties sections.

  • Zero or one application-properties sections.

  • The body consists of one of the following three choices: one or more sections, one or more sections, or a single section.

  • Zero or one footer sections.

The header section carries standard delivery details about the transfer of a message through the AMQP network. If the header section is omitted the receiver MUST assume the appropriate default values (or the meaning implied by no value being set) for the fields within the unless other target or node specific defaults have otherwise been set.

Durable messages MUST NOT be lost even if an intermediary is unexpectedly terminated and restarted. A target which is not capable of fulfilling this guarantee MUST NOT accept messages where the durable header is set to true: if the source allows the outcome then the message SHOULD be rejected with the error, otherwise the link MUST be detached by the receiver with the same error.

This field contains the relative message priority. Higher numbers indicate higher priority messages. Messages with higher priorities MAY be delivered before those with lower priorities.

An AMQP intermediary implementing distinct priority levels MUST do so in the following manner:

  • If n distinct priorities are implemented and n is less than 10 -- priorities 0 to (5 - ceiling(n/2)) MUST be treated equivalently and MUST be the lowest effective priority. The priorities (4 + floor(n/2)) and above MUST be treated equivalently and MUST be the highest effective priority. The priorities (5 - ceiling(n/2)) to (4 + floor(n/2)) inclusive MUST be treated as distinct priorities.

  • If n distinct priorities are implemented and n is 10 or greater -- priorities 0 to (n - 1) MUST be distinct, and priorities n and above MUST be equivalent to priority (n - 1).

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.

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.

Duration in milliseconds for which the message is to be considered "live". If this is set then a message expiration time will be computed based on the time of arrival at an intermediary. Messages that live longer than their expiration time will be discarded (or dead lettered). When a message is transmitted by an intermediary that was received with a ttl, the transmitted message's header SHOULD contain a ttl that is computed as the difference between the current time and the formerly computed message expiration time, i.e., the reduced ttl, so that messages will eventually die if they end up in a delivery loop.

If this value is true, then this message has not been acquired by any other link (see ). If this value is false, then this message MAY have previously been acquired by another link or links.

The number of unsuccessful previous attempts to deliver this message. If this value is non-zero it can be taken as an indication that the delivery might be a duplicate. On first delivery, the value is zero. It is incremented upon an outcome being settled at the sender, according to rules defined for each outcome.

The delivery-annotations section is used for delivery-specific non-standard properties at the head of the message. Delivery annotations convey information from the sending peer to the receiving peer. If the recipient does not understand the annotation it cannot be acted upon and its effects (such as any implied propagation) cannot be acted upon. Annotations might be specific to one implementation, or common to multiple implementations. The capabilities negotiated on link and on the and SHOULD be used to establish which annotations a peer supports. A registry of defined annotations and their meanings is maintained [AMQPDELANN]. The symbolic key "rejected" is reserved for the use of communicating error information regarding rejected messages. Any values associated with the "rejected" key MUST be of type .

If the delivery-annotations section is omitted, it is equivalent to a delivery-annotations section containing an empty map of annotations.

The message-annotations section is used for properties of the message which are aimed at the infrastructure and SHOULD be propagated across every delivery step. Message annotations convey information about the message. Intermediaries MUST propagate the annotations unless the annotations are explicitly augmented or modified (e.g., by the use of the outcome).

The capabilities negotiated on link and on the and can be used to establish which annotations a peer understands; however, in a network of AMQP intermediaries it might not be possible to know if every intermediary will understand the annotation. Note that for some annotations it might not be necessary for the intermediary to understand their purpose, i.e., they could be used purely as an attribute which can be filtered on.

A registry of defined annotations and their meanings is maintained [AMQPMESSANN].

If the message-annotations section is omitted, it is equivalent to a message-annotations section containing an empty map of annotations.

The properties section is used for a defined set of standard properties of the message. The properties section is part of the bare message; therefore, if retransmitted by an intermediary, it MUST remain unaltered.

Message-id, if set, uniquely identifies a message within the message system. The message producer is usually responsible for setting the message-id in such a way that it is assured to be globally unique. A broker MAY discard a message as a duplicate if the value of the message-id matches that of a previously received message sent to the same node.

The identity of the user responsible for producing the message. The client sets this value, and it MAY be authenticated by intermediaries.

The to field identifies the node that is the intended destination of the message. On any given transfer this might not be the node at the receiving end of the link.

A common field for summary information about the message content and purpose.

The address of the node to send replies to.

This is a client-specific id that can be used to mark or identify messages between clients.

The RFC-2046 [RFC2046] MIME type for the message's application-data section (body). As per RFC-2046 [RFC2046] this can contain a charset parameter defining the character encoding used: e.g., 'text/plain; charset="utf-8"'.

For clarity, as per section 7.2.1 of RFC-2616 [RFC2616], where the content type is unknown the content-type SHOULD NOT be set. This allows the recipient the opportunity to determine the actual type. Where the section is known to be truly opaque binary data, the content-type SHOULD be set to application/octet-stream.

When using an application-data section with a section code other than data, content-type SHOULD NOT be set.

The content-encoding property is used as a modifier to the content-type. When present, its value indicates what additional content encodings have been applied to the application-data, and thus what decoding mechanisms need to be applied in order to obtain the media-type referenced by the content-type header field.

Content-encoding is primarily used to allow a document to be compressed without losing the identity of its underlying content type.

Content-encodings are to be interpreted as per section 3.5 of RFC 2616 [RFC2616]. Valid content-encodings are registered at IANA [IANAHTTPPARAMS].

The content-encoding MUST NOT be set when the application-data section is other than data. The binary representation of all other application-data section types is defined completely in terms of the AMQP type system.

Implementations MUST NOT use the identity encoding. Instead, implementations SHOULD NOT set this property. Implementations SHOULD NOT use the compress encoding, except as to remain compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.

Implementations SHOULD NOT specify multiple content-encoding values except as to be compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.

An absolute time when this message is considered to be expired.

An absolute time when this message was created.

Identifies the group the message belongs to.

The relative position of this message within its group.

This is a client-specific id that is used so that client can send replies to this message to a specific group.

The application-properties section is a part of the bare message used for structured application data. Intermediaries can use the data within this structure for the purposes of filtering or routing.

The keys of this map are restricted to be of type (which excludes the possibility of a null key) and the values are restricted to be of simple types only, that is, excluding , , and types.

A data section contains opaque binary data.

A sequence section contains an arbitrary number of structured data elements.

An amqp-value section contains a single AMQP value.

The footer section is used for details about the message or delivery which can only be calculated or evaluated once the whole bare message has been constructed or seen (for example message hashes, HMACs, signatures and encryption details).

A registry of defined footers and their meanings is maintained [AMQPFOOTER].

The annotations type is a map where the keys are restricted to be of type or of type . All ulong keys, and all symbolic keys except those beginning with "x-" are reserved. Keys beginning with "x-opt-" MUST be ignored if not understood. On receiving an annotation key which is not understood, and which does not begin with "x-opt", the receiving AMQP container MUST detach the link with a error.

This value goes into the message-format field of the transfer frame when transferring messages of the format defined herein.

The messaging layer defines a set of states for a distribution node, defined as a node that stores messages for distribution. Not all nodes are distribution nodes; however, these definitions permit some standardized interaction with those nodes that do. The transitions between these states are controlled by the transfer of messages to/from a distribution node and the resulting terminal delivery state. Note that the state of a message at one distribution node does not affect the state of the same message at a separate node.

By default a message will begin in the AVAILABLE state. Prior to initiating an acquiring transfer, the message will transition to the ACQUIRED state. Once in the ACQUIRED state, a message is ineligible for acquiring transfers to any other links.

A message will remain ACQUIRED at the distribution node until the transfer is settled. The delivery state at the receiver determines how the message transitions when the transfer is settled. If the delivery state at the receiver is not yet known, (e.g., the link endpoint is destroyed before recovery occurs) the default-outcome of the source is used (see ).

State transitions can also occur spontaneously at the distribution node. For example if a message with a ttl expires, the effect of expiry might be (depending on specific type and configuration of the distribution node) to move spontaneously from the AVAILABLE state into the ARCHIVED state. In this case any transfers of the message are transitioned to a terminal outcome at the distribution node regardless of receiver state.

+------------+ +->| AVAILABLE | | +------------+ | | | | terminal outcome: | | RELEASED/MODIFIED | | TRANSFER (acquiring) | | | | | \|/ | +------------+ +--| ACQUIRED | +------------+ | | | terminal outcome: | ACCEPTED/REJECTED | | \|/ +------------+ | ARCHIVED | +------------+

The messaging layer defines a concrete set of delivery states which can be used (via the frame) to indicate the state of the message at the receiver. Delivery states can be either terminal or non-terminal. Once a delivery reaches a terminal delivery state, the state for that delivery will no longer change. A terminal delivery state is referred to as an outcome.

The following outcomes are formally defined by the messaging layer to indicate the result of processing at the receiver:

  • : indicates successful processing at the receiver.

  • : indicates an invalid and unprocessable message.

  • : indicates that the message was not (and will not be) processed.

  • : indicates that the message was modified, but not processed.

The following non-terminal delivery-state is formally defined by the messaging layer for use during link recovery to allow the sender to resume the transfer of a large message without retransmitting all the message data:

  • : indicates partial message data seen by the receiver as well as the starting point for a resumed transfer.

At the target the state indicates the furthest point in the payload of the message which the target will not need to have resent if the link is resumed. At the source the state represents the earliest point in the payload which the sender is able to resume transferring at in the case of link resumption. When resuming a delivery, if this state is set on the first performative it indicates the offset in the payload at which the first resumed delivery is starting. The sender MUST NOT send the state on or performatives except on the first performative on a resumed delivery.

When sent by the sender this indicates the first section of the message (with section-number 0 being the first section) for which data can be resent. Data from sections prior to the given section cannot be retransmitted for this delivery.

When sent by the receiver this indicates the first section of the message for which all data might not yet have been received.

When sent by the sender this indicates the first byte of the encoded section data of the section given by section-number for which data can be resent (with section-offset 0 being the first byte). Bytes from the same section prior to the given offset section cannot be retransmitted for this delivery.

When sent by the receiver this indicates the first byte of the given section which has not yet been received. Note that if a receiver has received all of section number X (which contains N bytes of data), but none of section number X + 1, then it can indicate this by sending either Received(section-number=X, section-offset=N) or Received(section-number=X+1, section-offset=0). The state Received(section-number=0, section-offset=0) indicates that no message data at all has been transferred.

At the source the accepted state means that the message has been retired from the node, and transfer of payload data will not be able to be resumed if the link becomes suspended. A delivery can become accepted at the source even before all transfer frames have been sent, this does not imply that the remaining transfers for the delivery will not be sent - only the aborted flag on the performative can be used to indicate a premature termination of the transfer.

At the target, the accepted outcome is used to indicate that an incoming message has been successfully processed, and that the receiver of the message is expecting the sender to transition the delivery to the accepted state at the source.

The accepted outcome does not increment the delivery-count in the header of the accepted message.

At the target, the rejected outcome is used to indicate that an incoming message is invalid and therefore unprocessable. The rejected outcome when applied to a message will cause the delivery-count to be incremented in the header of the rejected message.

At the source, the rejected outcome means that the target has informed the source that the message was rejected, and the source has taken the necessary action. The delivery SHOULD NOT ever spontaneously attain the rejected state at the source.

This field contains diagnostic information about the cause of the message rejection.

At the source the released outcome means that the message is no longer acquired by the receiver, and has been made available for (re-)delivery to the same or other targets receiving from the node. The message is unchanged at the node (i.e., the delivery-count of the header of the released message MUST NOT be incremented). As released is a terminal outcome, transfer of payload data will not be able to be resumed if the link becomes suspended. A delivery can become released at the source even before all transfer frames have been sent. This does not imply that the remaining transfers for the delivery will not be sent. The source MAY spontaneously attain the released outcome for a message (for example the source might implement some sort of time-bound acquisition lock, after which the acquisition of a message at a node is revoked to allow for delivery to an alternative consumer).

At the target, the released outcome is used to indicate that a given transfer was not and will not be acted upon.

At the source the modified outcome means that the message is no longer acquired by the receiver, and has been made available for (re-)delivery to the same or other targets receiving from the node. The message has been changed at the node in the ways indicated by the fields of the outcome. As modified is a terminal outcome, transfer of payload data will not be able to be resumed if the link becomes suspended. A delivery can become modified at the source even before all transfer frames have been sent. This does not imply that the remaining transfers for the delivery will not be sent. The source MAY spontaneously attain the modified outcome for a message (for example the source might implement some sort of time-bound acquisition lock, after which the acquisition of a message at a node is revoked to allow for delivery to an alternative consumer with the message modified in some way to denote the previous failed, e.g., with delivery-failed set to true).

At the target, the modified outcome is used to indicate that a given transfer was not and will not be acted upon, and that the message SHOULD be modified in the specified ways at the node.

If the delivery-failed flag is set, any messages modified MUST have their delivery-count incremented.

If the undeliverable-here is set, then any messages released MUST NOT be redelivered to the modifying link endpoint.

Map containing attributes to combine with the existing message-annotations held in the message's header section. Where the existing message-annotations of the message contain an entry with the same key as an entry in this field, the value in this field associated with that key replaces the one in the existing headers; where the existing message-annotations has no such value, the value in this map is added.

provides the general scheme for how two endpoints can re-establish state after link resumption was provided. The concrete delivery states defined above allow for a more comprehensive set of examples of link resumption.

Peer Partner ======================================================================= ATTACH(name=N, handle=1, --+ +-- ATTACH(name=N, handle=2, role=sender, \ / role=receiver, source=X, \ / source=X, target=Y, x target=Y, unsettled= / \ unsettled= { 1 -> null, / \ { 2 -> Received(3,0), 2 -> null, <-+ +-> 3 -> Accepted, 3 -> null, 4 -> null, 4 -> null, 6 -> Received(2,0), 5 -> Received(0,200), 7 -> Received(0,100), 6 -> Received(1,150), 8 -> Accepted, 7 -> Received(0,500), 9 -> null, 8 -> Received(3,5), 11 -> Received(1,2000), 9 -> Received(2,0), 12 -> Accepted, 10 -> Accepted, 13 -> Released, 11 -> Accepted, 14 -> null } 12 -> Accepted, 13 -> Accepted, 14 -> Accepted } ----------------------------------------------------------------------- Key: Received(x,y) means Received(section-number=x, section-offset=y)

In this example, for delivery-tags 1 to 4 inclusive the sender indicates that it can resume sending from the start of the message.

For delivery-tag 1, the receiver has no record of the delivery. To preserve "exactly once" or "at least once" delivery guarantees, the sender MUST resend the message; however, the delivery is not being resumed (since the receiver does not remember the delivery tag) so transfers MUST NOT have the resume flag set to true. If the sender were to mark the transfers as resumes then they would be ignored at the receiver.

For delivery-tag 2, the receiver has retained some of the data making up the message, but not the whole. In order to complete the delivery the sender needs to resume sending from some point before or at the next position which the receiver is expecting.

TRANSFER(delivery-id=1, ----------> ** Append message data not ** delivery-tag=2, ** seen previously to delivery ** (1) state=Received(3,0), ** state. ** resume=true) { ** payload ** } (1) state could be a) null, meaning that the transfer is being resumed from the first byte of section number 0 (and the receiver MUST ignore all data up to the first position it has not previously received). b) Received with section number 0, 1 or 2 and an offset, indicating that the payload data on the first frame of the resumed delivery starts at the given point, and that the receiver MUST ignore all data up to the first position it has not previously received. c) Received(3,0) indicating that the resumption will start at the first point which the receiver has not previously received.

For delivery-tag 3, the receiver indicates that it has processed the delivery to the point where it desires a terminal outcome (in this case ). In this case the sender will either apply that outcome at the source, or in the rare case that it cannot apply that outcome, indicate the terminal outcome that has been applied. To do this the sender MUST send a resuming transfer to associate delivery-tag 3 with a delivery-id. On this transfer the sender SHOULD set the delivery-state at the source. If this is the same outcome as at the receiver then the sender MAY also send the resuming transfer as settled.

TRANSFER(delivery-id=2, ----------> ** Processes confirmation that ** delivery-tag=3, ** was accepted, and settles. ** settled=true, more=false, state=Accepted, resume=true)

For delivery-tag 4, the receiver indicates that it is aware that the delivery had begun, but does not provide any indication that it has retained any data about that delivery except the fact of its existence. To preserve "exactly once" or "at least once" delivery guarantees, the sender MUST resend the whole message. Unlike the case with delivery-tag 1 the resent delivery MUST be sent with the resume flag set to true and the delivery-tag set to 4. (While this use of null in the receivers map is valid, it is discouraged. It is RECOMMENDED that receiver SHOULD NOT retain such an entry in its map, in which case the situation would be as for delivery-tag 1 in this example).

TRANSFER(delivery-id=3, ----------> ** Processes in the same way ** delivery-tag=4, ** as we be done for a non- ** (1) state=null, ** resumed delivery. ** resume=true) { ** payload ** } (1) Alternatively (and equivalently) state could be Received(section-number=0, section-offset=0)

For delivery-tags 5 to 9 inclusive the sender indicates that it can resume at some point beyond start of the message data. This is usually indicative of the fact that the receiver had previously confirmed reception of message data to the given point, removing responsibility from the sender to retain the ability to resend that data after resuming the link. The sender MAY still retain the ability to resend the message as a new delivery (i.e. it MAY not have completely discarded the data from which the original delivery was generated).

For delivery-tag 5, the receiver has no record of the delivery. To preserve "exactly once" or "at least once" delivery guarantees, the sender MUST resend the message; however, the delivery is not being resumed (since the receiver does not remember the delivery tag) so transfers MUST NOT have the resume flag set to true. If the sender does not have enough data to resend the message, then the sender MAY take some action to indicate that it believes there is a possibility that there has been message loss, for example, notify the application.

For delivery-tag 6, the receiver has retained some of the data making up the message, but not the whole. The first position within the message which the receiver has not received is after the first position at which the sender can resume sending. In order to complete the delivery the sender needs to resume sending from some point before or at the next position which the receiver is expecting.

TRANSFER(delivery-id=4, ----------> ** Append message data not ** delivery-tag=6, ** seen previously to delivery ** (1) state=Received(2,0), ** state. ** resume=true) { ** payload ** } (1) state could be any point between Received(1,150) and Received(2,0) inclusive. The receiver MUST ignore all data up to the first position it has not previously received (i.e. section 2 offset 0).

For delivery-tag 7, the receiver has retained some of the data making up the message, but not the whole. The first position within the message which the receiver has not received is before the first position at which the sender can resume sending. It is thus not possible for the sender to resume sending the message to completion. The only option available to the sender is to abort the transfer and to then (if possible) resend as a new delivery or else to report the possible message loss in some way if it cannot.

TRANSFER(delivery-id=5, ----------> ** Discard any state relating ** delivery-tag=7, ** to the message delivery. ** resume=true, aborted=true)

For delivery-tag 8, the receiver indicates that it has processed the delivery to the point where it desires a terminal outcome (in this case ). This is the same case as for delivery-tag 3.

TRANSFER(delivery-id=6, ----------> ** Processes confirmation that ** delivery-tag=8, ** was accepted, and settles. ** settled=true, more=false, state=Accepted, resume=true)

For delivery-tag 9, the receiver indicates that it is aware that the delivery had begun, but does not provide any indication that it has retained any data about that delivery except the fact of its existence. This is the same case as for delivery-tag 7.

TRANSFER(delivery-id=7, ----------> ** Discard any state relating ** delivery-tag=9, ** to the message delivery. ** resume=true, aborted=true)

For delivery-tags 10 to 14 inclusive the sender indicates that it has reached a terminal outcome, namely . Once the sender has arrived at a terminal outcome it MUST NOT change. As such, if a sender is capable of resuming a delivery (even if the only possible outcome of the delivery is a pre-defined terminal outcome such as ) it MUST NOT use this state as the value of the state in its unsettled map until it is sure that the receiver will not require the resending of the message data.

For delivery-tag 10 the receiver has no record of the delivery. However, in contrast to the cases of delivery-tag 1 and delivery-tag 5, since it is known that the sender can only have arrived at this state through knowing that the receiver has received the whole message (or that the sender had spontaneously reached a terminal outcome with no possibility of resumption) there is no need to resend the message.

For delivery-tag 11 it MUST be assumed that the sender spontaneously attained the terminal outcome (and is unable to resume). In this case the sender can simply abort the delivery as it cannot be resumed.

TRANSFER(delivery-id=8, ----------> ** Discard any state relating ** delivery-tag=11, ** to the message delivery. ** resume=true, aborted=true)

For delivery-tag 12 both the sender and receiver have attained the same view of the terminal outcome, but neither has settled. In this case the sender SHOULD simply settle the delivery.

TRANSFER(delivery-id=9, ----------> ** Locally settle the delivery ** delivery-tag=12, settled=true, resume=true)

For delivery-tag 13 the sender and receiver have both attained terminal outcomes, but the outcomes differ. In this case, since the outcome actually takes effect at the sender, it is the sender's view that is definitive. The sender thus MUST restate this as the terminal outcome, and the receiver SHOULD then echo this and settle.

TRANSFER(delivery-id=10 ----------> ** Update any state affected ** delivery-tag=13, ** by the actual outcome, then ** settled=false, ** settle the delivery ** state=Accepted resume=true) <---------- DISPOSITION(first=10, last=10, state=Accepted, settled=true)

For delivery-tag 14 the case is essentially the same as for delivery-tag 11, as the null state at the receiver is essentially identical to having the state Received with section-number=0 and section-offset=0.

TRANSFER(delivery-id=11, ----------> ** Discard any state relating ** delivery-tag=14, ** to the message delivery. ** resume=true, aborted=true)

The messaging layer defines two concrete types ( and ) to be used as the source and target of a link. These types are supplied in the source and target fields of the frame when establishing or resuming link. The is comprised of an address (which the container of the outgoing link endpoint will resolve to a node within that container) coupled with properties which determine:

  • which messages from the sending node will be sent on the link,

  • how sending the message affects the state of that message at the sending node,

  • the behavior of messages which have been transferred on the link, but have not yet reached a terminal state at the receiver, when the source is destroyed.

A source can restrict the messages transferred from a source by specifying a filter. A filter can be thought of as a function which takes a message as input and returns a boolean value: true if the message will be accepted by the source, false otherwise. A filter MUST NOT change its return value for a message unless the state or annotations on the message at the node change (e.g., through an updated delivery state).

The source optionally defines a distribution-mode that informs and/or indicates how distribution nodes are to behave with respect to the link. The distribution-mode of a source determines how messages from a distribution node are distributed among its associated links. There are two defined distribution-modes: move and copy. When specified, the distribution-mode has two related effects on the behavior of a distribution node with respect to the link associated with the source.

The move distribution-mode causes messages transferred from the distribution node to transition to the ACQUIRED state prior to transfer over the link, and subsequently to the ARCHIVED state when the transfer is settled with a successful outcome. The copy distribution-mode leaves the state of the message unchanged at the distribution node.

A source MUST NOT resend a message which has previously been successfully transferred from the source, i.e., reached an ACCEPTED delivery state at the receiver. For a move link with a default configuration this is trivially achieved as such an end result will lead to the message in the ARCHIVED state on the node, and thus ineligible for transfer. For a copy link, state MUST be retained at the source to ensure compliance. In practice, for nodes which maintain a strict order on messages at the node, the state might simply be a record of the most recent message transferred.

A registry of commonly defined non-standard distribution-modes and their meanings is maintained [AMQPDISTMODE].

For containers which do not implement address resolution (and do not admit spontaneous link attachment from their partners) but are instead only used as producers of messages, it is unnecessary to provide spurious detail on the source. For this purpose it is possible to use a "minimal" source in which all the fields are left unset.

The address of the source MUST NOT be set when sent on a frame sent by the receiving link endpoint where the dynamic flag is set to true (that is where the receiver is requesting the sender to create an addressable node).

The address of the source MUST be set when sent on a frame sent by the sending link endpoint where the dynamic flag is set to true (that is where the sender has created an addressable node at the request of the receiver and is now communicating the address of that created node). The generated name of the address SHOULD include the link name and the container-id of the remote container to allow for ease of identification.

Indicates what state of the terminus will be retained durably: the state of durable messages, only existence and configuration of the terminus, or no state at all.

See .

The source starts expiring as indicated by the expiry-policy.

When set to true by the receiving link endpoint, this field constitutes a request for the sending peer to dynamically create a node at the source. In this case the address field MUST NOT be set.

When set to true by the sending link endpoint this field indicates creation of a dynamically created node. In this case the address field will contain the address of the created node. The generated address SHOULD include the link name and other available information on the initiator of the request (such as the remote container-id) in some recognizable form for ease of traceability.

If the dynamic field is not set to true this field MUST be left unset.

When set by the receiving link endpoint, this field contains the desired properties of the node the receiver wishes to be created. When set by the sending link endpoint this field contains the actual properties of the dynamically created node. See for standard node properties. A registry of other commonly used node-properties and their meanings is maintained [AMQPNODEPROP].

This field MUST be set by the sending end of the link if the endpoint supports more than one distribution-mode. This field MAY be set by the receiving end of the link to indicate a preference when a node supports multiple distribution modes.

See . The receiving endpoint sets its desired filter, the sending endpoint sets the filter actually in place (including any filters defaulted at the node). The receiving endpoint MUST check that the filter in place meets its needs and take responsibility for detaching if it does not.

Indicates the outcome to be used for transfers that have not reached a terminal state at the receiver when the transfer is settled, including when the source is destroyed. The value MUST be a valid outcome (e.g., or ).

The values in this field are the symbolic descriptors of the outcomes that can be chosen on this link. This field MAY be empty, indicating that the default-outcome will be assumed for all message transfers (if the default-outcome is not set, and no outcomes are provided, then the outcome MUST be supported by the source).

When present, the values MUST be a symbolic descriptor of a valid outcome, e.g., "amqp:accepted:list".

A registry of commonly defined source capabilities and their meanings is maintained [AMQPSOURCECAP].

For containers which do not implement address resolution (and do not admit spontaneous link attachment from their partners) but are instead only used as consumers of messages, it is unnecessary to provide spurious detail on the source. For this purpose it is possible to use a "minimal" target in which all the fields are left unset.

The address of the target MUST NOT be set when sent on a frame sent by the sending link endpoint where the dynamic flag is set to true (that is where the sender is requesting the receiver to create an addressable node).

The address of the source MUST be set when sent on a frame sent by the receiving link endpoint where the dynamic flag is set to true (that is where the receiver has created an addressable node at the request of the sender and is now communicating the address of that created node). The generated name of the address SHOULD include the link name and the container-id of the remote container to allow for ease of identification.

Indicates what state of the terminus will be retained durably: the state of durable messages, only existence and configuration of the terminus, or no state at all.

See .

The target starts expiring as indicated by the expiry-policy.

When set to true by the sending link endpoint, this field constitutes a request for the receiving peer to dynamically create a node at the target. In this case the address field MUST NOT be set.

When set to true by the receiving link endpoint this field indicates creation of a dynamically created node. In this case the address field will contain the address of the created node. The generated address SHOULD include the link name and other available information on the initiator of the request (such as the remote container-id) in some recognizable form for ease of traceability.

If the dynamic field is not set to true this field MUST be left unset.

When set by the sending link endpoint, this field contains the desired properties of the node the sender wishes to be created. When set by the receiving link endpoint this field contains the actual properties of the dynamically created node. See for standard node properties. A registry of other commonly used node-properties and their meanings is maintained [AMQPNODEPROP].

A registry of commonly defined target capabilities and their meanings is maintained [AMQPTARGETCAP].

Determines which state of the terminus is held durably.

No terminus state is retained durably.

Only the existence and configuration of the terminus is retained durably.

In addition to the existence and configuration of the terminus, the unsettled state for durable messages is retained durably.

Determines when the expiry timer of a terminus starts counting down from the timeout value. If the link is subsequently re-attached before the terminus is expired, then the count down is aborted. If the conditions for the terminus-expiry-policy are subsequently re-met, the expiry timer restarts from its originally configured timeout value.

The expiry timer starts when terminus is detached.

The expiry timer starts when the most recently associated session is ended.

The expiry timer starts when most recently associated connection is closed.

The terminus never expires.

Policies for distributing messages when multiple links are connected to the same node.

once successfully transferred over the link, the message will no longer be available to other links from the same node

once successfully transferred over the link, the message is still available for other links from the same node

A set of named filters. Every key in the map MUST be of type , every value MUST be either or of a described type which provides the archetype filter. A filter acts as a function on a message which returns a boolean result indicating whether the message can pass through that filter or not. A message will pass through a filter-set if and only if it passes through each of the named filters. If the value for a given key is null, this acts as if there were no such key present (i.e., all messages pass through the null filter).

Filter types are a defined extension point. The filter types that a given supports will be indicated by the capabilities of the . A registry of commonly defined filter types and their capabilities is maintained [AMQPFILTERS].

A symbol-keyed map containing properties of a node used when requesting creation or reporting the creation of a dynamic node.

The following common properties are defined:

lifetime-policy

The lifetime of a dynamically generated node.

Definitionally, the lifetime will never be less than the lifetime of the link which caused its creation, however it is possible to extend the lifetime of dynamically created node using a lifetime policy. The value of this entry MUST be of a type which provides the lifetime-policy archetype. The following standard lifetime-policies are defined below: , , or .

supported-dist-modes

The distribution modes that the node supports.

The value of this entry MUST be one or more symbols which are valid distribution-modes. That is, the value MUST be of the same type as would be valid in a field defined with the following attributes:

type="symbol" multiple="true" requires="distribution-mode"

A node dynamically created with this lifetime policy will be deleted at the point that the link which caused its creation ceases to exist.

A node dynamically created with this lifetime policy will be deleted at the point that there remain no links for which the node is either the source or target.

A node dynamically created with this lifetime policy will be deleted at the point that the link which caused its creation no longer exists and there remain no messages at the node.

A node dynamically created with this lifetime policy will be deleted at the point that the there are no links which have this node as their source or target, and there remain no messages at the node.