- The AMQP type system defines a set of commonly used primitive types used for interoperable
- data representation. AMQP values may be annotated with additional semantic information
- beyond that associated with the primitive type. This allows for the association of an AMQP
- value with an external type that is not present as an AMQP primitive. For example, a URL is
+ The AMQP type system defines a set of commonly used primitive types for interoperable data
+ representation. AMQP values can be annotated with additional semantic information beyond
+ that associated with the primitive type. This allows for the association of an AMQP value
+ with an external type that is not present as an AMQP primitive. For example, a URL is
commonly represented as a string, however not all strings are valid URLs, and many
programming languages and/or applications define a specific type to represent URLs. The AMQP
type system would allow for the definition of a code with which to annotate strings when the
@@ -35,16 +35,17 @@
- The following primitive types are defined:
+ The AMQP type system defines a standard set of primitive types for representing both common
+ scalar values and common collections. The scalar types include booleans, integral numbers,
+ floating point numbers, timestamps, UUIDs, characters, strings, binary data, and symbols.
+ The collection types include arrays (monomorphic), lists (polymorphic), and maps.
The primitive types defined by AMQP can directly represent many of the basic types present
- in most popular programming languages, and therefore may be trivially used to exchange basic
+ in most popular programming languages, and therefore can be trivially used to exchange basic
data. In practice, however, even the simplest applications have their own set of custom
types used to model concepts within the application's domain. In messaging
applications these custom types need to be externalized for transmission.
@@ -69,40 +70,41 @@
- Descriptor values other than symbolic (
- The namespace for both symbolic and numeric descriptors is divided into distinct domains.
- Each domain has a defined symbol and/or 4 byte numeric id assigned by the AMQP working
- group. For numeric ids the assigned domain-id will be equal to the IANA Private Enterprise
- Number (PEN) of the requesting organisation [
+ AMQP defines the notion of a restricted type. This is a new type derived from an
+ existing type where the permitted values of the new type are a subset of the values of the
+ existing type. Restricted types are commonly used programming constructs, the most frequent
+ being "enumerations" which in AMQP terminology are restrictions of the integral types.
+ However, the AMQP notion of restricted types can also represent more open ended restrictions
+ such as a URL which can be thought of as a restriction of the string type.
- Descriptors are then assigned within each domain according to the following rules:
+ A restricted type definition might limit the permitted values to either a pre-defined fixed
+ set, or an open-ended set. In the former case, each permitted value is called a
+ choice and all possible choices are listed in the formal type definition. In the
+ latter case, the nature of the restriction is specified as text in the formal type
+ definition.
<domain>:<name>
- (domain-id << 32) | descriptor-id
-
+ The existing type from which a restricted type is derived is referred to as the
+ source type for the restriction. A restricted type might or might not be annotated
+ with a descriptor on the wire depending on the formal definition for the type.
+
-
+
- The bits within a format code may be interpreted according to the following layout: + The bits within a format code can be interpreted according to the following layout:
- The width of a specific fixed width encoding may be computed from the subcategory of the + The width of a specific fixed width encoding can be computed from the subcategory of the format code for the fixed width value:
@@ -334,6 +336,415 @@+ All variable width encodings consist of a size in octets followed by size octets of + encoded data. The width of the size for a specific variable width encoding can be computed + from the subcategory of the format code: +
+ ++ All compound encodings consist of a size and a count followed by count encoded items. + The width of the size and count for a specific compound encoding can be computed from the + category of the format code: +
+ ++ All array encodings consist of a size followed by a count followed by an element constructor + followed by count elements of encoded data formated as REQUIRED by the element + constructor: +
+ +
+ Types are formally specified using an XML notation described below. Please note that this
+ XML notation is used only to define the type and is never used to represent encoded data.
+ All encoded AMQP data is binary as described in
+ The type element formally defines a semantic type used to exchange data on the wire. Every + type definition has the following general form. The child elements present depend upon the + class of the type definition (primitive, composite, or restricted): +
+ ++ The attributes of a type definition specify the following: +
+ +The name of the type.
A short description of the type.
A string identifying what class of type is being defined: "primitive", + "composite", or "restricted".
A comma separated list of archetypes (see field element).
+ There are three different classes of types identified by the "class" attribute: primitive, + composite, and restricted. +
++ A "primitive" type definition will contain one or more encoding elements that describe how + the data is formatted on the wire. Primitive types do not contain the descriptor, field, or + choice elements. +
+ ++ The encoding element defines how a primitive type is encoded. The specification defines 4 + general categories of encodings: fixed, variable, compound, and array. A specific encoding + provides further details of how data is formatted within its general category. +
+ +The name of the encoding.
A short description of the encoding.
The numeric value that prefixes the encoded data on the wire.
The category of the encoding: "fixed", "variable", "compound", or + "array".
The width of the encoding or the size/count prefixes depending on the + category.
+ A "composite" type definition specifies a new kind of record type, i.e., a type composed of + a fixed number of fields whose values are each of a specific type. A composite type does not + have a new encoding, but is sent on the wire as a list annotated by a specific descriptor + value that identifies it as a representation of the defined composite type. A composite type + definition will contain a descriptor and zero or more field elements. Composite types do not + contain encoding or choice elements. The source attribute of a composite type will always be + "list", other values are reserved for future use. +
+ ++ The descriptor element specifies what annotation is used to identify encoded values as + representations of a described type. +
+ +A symbolic name for the representation.
The numeric value.
+ The field element identifies a field within a composite type. Every field has the following + attributes: +
+ +A name that uniquely identifies the field within the type.
The type of the field. This attribute defines the range of values that + are permitted to appear in this field. It might name a specific type, in which case the + values are restricted to that type, or it might be the special character "*", in which case + a value of any type is permitted. In the latter case the range of values might be further + restricted by the requires attribute.
A comma separated list of archetypes. Field values are restricted + to types providing at least one of the specified archetypes.
A default value for the field if no value is encoded.
A short description of the field.
"true" iff a non null value for the field is always + encoded.
"true" iff the field can have multiple values of its specified + type.
+ A "restricted" type definition specifies a new kind of type whose values are restricted to a + subset of the values that might be represented with another type. The source attribute + identifies the base type from which a restricted type is derived. A restricted type can have + a descriptor element in which case it is identified by a descriptor on the wire. The values + permitted by a restricted type can be specified either via documentation, or directly + limited to a fixed number of values by the choice elements contained within the definition. +
+ ++ The choice element identifies a legal value for a restricted type. The choice element has + the following attributes: +
+ +A name for the value.
The permitted value.
+ AMQP composite types are represented as a described list. Each element in the list is + positionally correlated with the fields listed in the composite type definition. The + permitted element values are determined by the type specification and multiplicity of the + corresponding field definitions. When the trailing elements of the list representation are + null, they MAY be omitted. The descriptor of the list indicates the specific composite type + being represented. +
+ +An example composite type.
++ The mandatory attribute of a field description controls whether a null element value + is permitted in the representation. +
+ ++ The multiple attribute of a field description controls whether multiple element + values are permitted in the representation. A single element of the type specified in the + field description is always permitted. Multiple values are represented by the use of an + array where the type of the elements in the array is the type defined in the field + definition. Note that a null value and a zero-length array (with a correct type for its + elements) both describe an absence of a value and MUST be treated as semantically identical. +
+ ++ A field which is defined as both multiple and mandatory MUST contain at least one value + (i.e. for such a field both null and an array with no entries are invalid). +
+ ++ The described list shown below is an example composite value of the book type defined + above. A trailing null element corresponding to the absence of an ISBN value is depicted in + the example, but can optionally be omitted according to the encoding rules. +
+ +
+ Descriptor values other than symbolic (
+ The namespace for both symbolic and numeric descriptors is divided into distinct domains.
+ Each domain has a defined symbol and/or 4 byte numeric id assigned by the AMQP working
+ group. For numeric ids the assigned domain-id will be equal to the IANA Private Enterprise
+ Number (PEN) of the requesting organisation [
+ Descriptors are then assigned within each domain according to the following rules: +
+ +<domain>:<name>
++ (domain-id << 32) | descriptor-id +
+- All variable width encodings consist of a size in octets followed by size octets of - encoded data. The width of the size for a specific variable width encoding may be computed - from the subcategory of the format code: -
- -- All compound encodings consist of a size and a count followed by count encoded items. - The width of the size and count for a specific compound encoding may be computed from the - category of the format code: -
- -- Map encodings must contain an even number of items (i.e. an equal number of keys and + Map encodings MUST contain an even number of items (i.e. an equal number of keys and values). A map in which there exist two identical key values is invalid. Unless known to - be otherwise, maps must be considered to be ordered, that is, the order of the key-value + be otherwise, maps MUST be considered to be ordered, that is, the order of the key-value pairs is semantically important and two maps which are different only in the order in which their key-value pairs are encoded are not equal.
@@ -617,140 +978,12 @@ label="up to 2^32 - 1 octets of encoded map data"/>- All array encodings consist of a size followed by a count followed by an element constructor - followed by count elements of encoded data formated as required by the element - constructor: -
- -- AMQP defines a number of composite types used for encoding structured data such as - frame bodies. A composite type describes a composite value where each constituent value is - identified by a well-known named field. Each composite type definition includes an - ordered sequence of fields, each with a specified name, type, and multiplicity. Composite - type definitions also include one or more descriptors (symbolic and/or numeric) for - identifying their defined representations. -
- -- Composite types are formally defined in the XML documents included with the specification. - The following notation is used to define them: -
- -An example composite type.
-- The mandatory attribute of a field description controls whether a null element value - is permitted in the representation. -
-- The multiple attribute of a field description controls whether multiple element - values are permitted in the representation. A single element of the type specified in the - field description is always permitted. Multiple values are represented by the use of an - array where the type of the elements in the array is the type defined in the field - definition. Note that a null value and a zero-length array (with a correct type for its - elements) both describe an absence of a value and MUST be treated as semantically - identical. -
-- A field which is defined as both multiple and mandatory MUST contain at least one value - (i.e. for such a field both null and an array with no entries are invalid). -
-- AMQP composite values are encoded as a described list. Each element in the list is - positionally correlated with the fields listed in the composite type definition. The - permitted element values are determined by the type specification and multiplicity of the - corresponding field definitions. When the trailing elements of the list representation are - null, they MAY be omitted. The descriptor of the list indicates the specific composite type - being represented. -
- -- The described list shown below is an example composite value of the book type defined - above. A trailing null element corresponding to the absence of an ISBN value is depicted in - the example, but may optionally be omitted according to the encoding rules. -
- -
+
R. Elz, R. Bush,
+ Serial Number Arithmetic.
+ IETF RFC 1982, August 1996.
+
N. Freed, N. Borenstein,
@@ -111,15 +120,6 @@
-
R. Elz, R. Bush,
- Serial Number Arithmetic.
- IETF RFC 1982, August 1996.
-
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels.
@@ -172,6 +172,14 @@
name="http://www.ietf.org/rfc/rfc4422.txt"/>
+
+ K. Zeilenga, Ed., The PLAIN Simple Authentication and Security Layer (SASL)
+ Mechanism. IETF RFC 4616, August 2006.
+
+
+
+ C. Newman, A. Menon-Sen, A. Melnikov, N. Williams, Salted Challenge Response
+ Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. IETF RFC 5802, July 2010.
+
+
- A conformant implementation MUST perform protocol negotiation, and then parse, process, and
- produce frames in accordance with the format and semantics defined in parts 1 through 5 of
- this specification.
+ AMQP defines a wire level protocol for business messaging. The definition allows for all
+ common business messaging behaviors. AMQP does not define a wire-level distinction between
+ "clients" and "brokers", the protocol is symmetric. It is expected and encouraged that
+ implementations of AMQP will have different capabilities. Expectations of the capabilities
+ of a "client library" are different from expectations of a "broker" which are themselves
+ different from the capabilities of a "router". As relevant profiles emerge (where
+ appropriate and applicable) these will be formalised.
+ A conformant implementation MUST perform protocol negotiation (see
+ Conformant implementations MUST NOT require the use of any extensions defined outside this
+ document in order to interoperate with any other conformant implementation.
+
+
+
+ Part 2 admits behaviors that might not be appropriate for every implementation. For example
+ a "client library" might not allow for its communication partner to spontaneously attempt to
+ initiate a connection and request messages. Where an implementation does not allow for a
+ behavior the implementation MUST respond according to the rules defined within Part 2 of the
+ specification.
+
+
+ Some implementations might not process messages (for example, an implementation acting as a
+ "router" which looks only at the routing information carried by the AMQP Transport layer).
+ Such implementations do not actively implement Part 3, but MUST NOT act in ways which
+ violate the rules of this part of the specification.
+
+ The Messaging layer admits behaviors that might not be appropriate for all implementations
+ (and within an implementation all behaviors might not be available for all configurations).
+ Where a behavior is not admitted, the implementation MUST respond according to the rules
+ defined within this specification.
+
+
+ It is RECOMMENDED that implementations designed to act as messaging intermediaries support
+ the ability to act as a transactional resource. It is RECOMMENDED that implementations or
+ re-usable libraries provide Application Programming Interfaces to enable them to act as
+ transactional controllers.
+
+ Where a behavior is not admitted, the rules defined in part 4 regarding responses to
+ non-admitted behaviors MUST be followed.
+
+
+ Conformant implementations acting in the TCP server role are strongly RECOMMENDED to
+ implement
+ Conformant implementations acting in the TCP client role SHOULD be capable of being
+ configured to connect to an implementation in the TCP server role that is following the
+ recommendations above.
+
Security layers are used to establish an authenticated and/or encrypted transport over which
- regular AMQP traffic can be tunneled. Security layers may be tunneled through one another
- (for instance a security layer used by the peers to do authentication may be tunneled
+ regular AMQP traffic can be tunneled. Security layers can be tunneled through one another
+ (for instance a security layer used by the peers to do authentication might be tunneled
through a security layer established for encryption purposes).
- In certain situations, such as connecting through firewalls, it may not be possible to
- establish a TLS security layer using the above procedure. This might be because a deep
- packet inspecting firewall sees the first few bytes of the connection 'as not being TLS'.
+ In certain situations, such as connecting through firewalls, it might not be possible to
+ establish a TLS security layer using the above procedure (for example, because a deep
+ packet inspecting firewall sees the first few bytes of the connection 'as not being TLS').
As an alternative, implementations MAY run a pure TLS server, i.e., one that does not expect
the initial TLS-invoking handshake. The IANA service name for this is amqps and the port is
-
The maximum size of a SASL frame is defined by
- The peer acting as the SASL server must announce supported authentication mechanisms using
- the
- Advertises the available SASL mechanisms that may be used for authentication.
+ Advertises the available SASL mechanisms that can be used for authentication.
A list of the sasl security mechanisms supported by the sending peer. It is invalid
for this list to be null or empty. If the sending peer does not require its partner
- to authenticate with it, then it should send a list of one element with its value as
+ to authenticate with it, then it SHOULD send a list of one element with its value as
the SASL mechanism ANONYMOUS. The server mechanisms are ordered in decreasing
level of preference.
The DNS name of the host (either fully qualified or relative) to which the sending peer
is connecting. It is not mandatory to provide the hostname. If no hostname is provided
- the receiving peer should select a default based on its own configuration.
+ the receiving peer SHOULD select a default based on its own configuration.
@@ -347,7 +347,7 @@
- This field may already have been specified by the server name indication extension as
+ This field might already have been specified by the server name indication extension as
described in RFC-4366 [
This frame indicates the outcome of the SASL dialog. Upon successful completion of the
- SASL dialog the security layer has been established, and the peers must exchange protocol
+ SASL dialog the security layer has been established, and the peers MUST exchange protocol
headers to either start a nested security layer, or to establish the AMQP connection.
- To begin transactional work, the transaction controller must obtain a transaction identifier
- from the resource. It does this by sending a message to the
If the declaration is successful, the coordinator responds with a disposition outcome of
@@ -134,7 +135,7 @@
type="type" name="transfer"/> pre-settled.
- Should the coordinator be unable to complete the
If the transaction controller wishes to associate an outgoing
On receiving a non-settled delivery associated with a live transaction, the transactional
- resource must inform the controller of the presumptive terminal outcome before it can
- successfully discharge the transaction. That is, the resource must send a
- The transaction controller may wish to associate the outcome of a delivery with a
+ The transaction controller might wish to associate the outcome of a delivery with a
transaction. The delivery itself need not be associated with the same transaction as the
outcome, or indeed with any transaction at all. However, the delivery MUST NOT be associated
with a different non-discharged transaction than the outcome. If this happens then the
@@ -364,13 +365,13 @@
- On a successful
In the case of the
@@ -399,7 +399,7 @@
not affect the level of outstanding credit. To prevent the sending link endpoint from
acquiring outside of any transaction, the controller SHOULD ensure there is no
outstanding credit at the sender before it discharges the transaction. The controller
- may do this by either setting the drain mode of the sending link endpoint to true
+ can do this by either setting the drain mode of the sending link endpoint to true
before discharging the transaction, or by reducing the link-credit to zero, and
waiting to hear back that the sender has seen this state change.
The transport layer defines a notion of settlement which refers to the point at which
the association of a delivery-tag to a delivery attempt is forgotten. Transactions do not in
- themselves change this notion, however the fact that transactional work may be rolled back
+ themselves change this notion, however the fact that transactional work can be rolled back
does have implications for deliveries which the endpoint has marked as settled (and for
which it can therefore no longer exchange state information using the previously allocated
transport level identifiers).
@@ -475,8 +475,8 @@
The delivered message will not be made available at the node until the transaction
has been successfully discharged. If the transaction is rolled back then the delivery
- is not made available. Should the resource be unable to process the delivery it MUST
- NOT allow the successful discharge of the associated transaction. This may be
+ is not made available. If the resource is unable to process the delivery it MUST
+ NOT allow the successful discharge of the associated transaction. This can be
communicated by immediately destroying the controlling link on which the transaction
was declared, or by rejecting any attempt to discharge the transaction where the fail
flag is not set to true.
@@ -493,7 +493,7 @@
If the transaction is rolled back then the delivery is not made available at the
target. If the resource can no longer apply the outcome that it originally indicated
would be the result of a successful discharge then it MUST NOT allow the successful
- discharge of the associated transaction. This may be communicated by immediately
+ discharge of the associated transaction. This can be communicated by immediately
destroying the controlling link on which the transaction was declared, or by rejecting
any attempt to discharge the transaction where the fail flag is not set to true.
Behavior prior to discharge is the same as the previous case.
After a successful discharge, the state of unsettled deliveries at the resource MUST
- reflect the outcome that was applied. If the discharge was unsuccessful then no
- outcome should be associated with the unsettled deliveries. The controller SHOULD
+ reflect the outcome that was applied. If the discharge was unsuccessful then an
+ outcome SHOULD NOT be associated with the unsettled deliveries. The controller SHOULD
settle any outstanding unsettled deliveries in a timely fashion after the transaction
has discharged.
Upon a successful discharge the outcome specified by the controller is applied at
- the source. Should the controller request a rollback or the discharge attempt be
+ the source. If the controller requests a rollback or the discharge attempt be
unsuccessful, then the outcome is not applied. At this point the controller can no
longer influence the state of the delivery as it is settled, and the resource MUST
apply the default outcome.
The resource may or may not settle the delivery before the transaction is
+ The resource might or might not settle the delivery before the transaction is
discharged. If the resource settles the delivery before the discharge then the
behavior after discharge is the same as the case above.
If set, this flag indicates that the work associated with this transaction has failed,
@@ -644,7 +644,7 @@
- A transaction-id may be up to 32 octets of binary data.
+ A transaction-id can be up to 32 octets of binary data.
An AMQP network consists of
@@ -32,18 +33,19 @@
a
As a message travels through an AMQP network, the responsibility for safe storage and
- delivery of the message is transferred between the nodes it encounters. The
- Nodes exist within a
The AMQP transport specification defines a peer-to-peer protocol for transferring messages
between nodes in an AMQP network. This portion of the specification is not concerned with
the internal workings of any sort of node, and only deals with the mechanics of
unambiguously transferring a message from one node to another.
+ In order for communication to occur between nodes in different containers a connection
+ needs be established.
+
- Containers communicate via
An AMQP connection is divided into a negotiated number of independent unidirectional
- An AMQP
+ A single connection MAY have multiple independent sessions active simultaneously, up to
+ the negotiated channel limit. Both connections and sessions are modeled by each peer as
+
- Sessions provide the context for communication between sources and targets. A
+ Links provide a credit-based flow control scheme based on the number of messages
+ transmitted, allowing applications to control which nodes to receive messages from at a
+ given point (e.g., to explicitly fetch a message from a given queue).
+
+ Sessions provide the context for communication between sources and targets.
+ A
+ Links are named, and the state at the termini can live longer than the connection on which
+ they were established.
+
+ The retained state at the termini can be used to reestablish the link on a new connection
+ (and session) with precise control over delivery guarantees (e.g., ensuring "exactly once"
+ delivery).
+
+ The diagram below shows the relationship between the three AMQP communication endpoints,
+ Connection, Session and Link.
+
- A frame is the unit of work carried on the wire. Connections have a negotiated maximum frame
- size allowing byte streams to be easily defragmented into complete frame bodies representing
- the independently parsable units formally defined in The frame header is a fixed size (8 byte) structure that precedes each frame. The
- frame header includes mandatory information required to parse the rest of the frame
+ frame header includes mandatory information necessary to parse the rest of the frame
including size and type information. Bytes 0-3 of the frame header contain the frame size. This is an unsigned 32-bit
integer that MUST contain the total frame size of the frame header, extended header, and
- frame body. The frame is malformed if the size is less than the size of the required
+ frame body. The frame is malformed if the size is less than the size of the
frame header (8 bytes). Byte 5 of the frame header is a type code. The type code indicates the format and
- purpose of the frame. The subsequent bytes in the frame header may be interpreted
+ purpose of the frame. The subsequent bytes in the frame header MAY be interpreted
differently depending on the type of the frame. A type code of 0x00 indicates that the
frame is an AMQP frame. A type code of 0x01 indicates that the frame is a SASL frame,
see
- An AMQP frame with no body may be used to generate artificial traffic as needed to
+ An AMQP frame with no body MAY be used to generate artificial traffic as needed to
satisfy any negotiated idle timeout interval (see
Although not strictly directed at the connection endpoint, the
- For applications that use many short-lived connections, it may be desirable to pipeline the
- connection negotiation process. A peer may do this by starting to send subsequent frames
+ For applications that use many short-lived connections, it MAY be desirable to pipeline the
+ connection negotiation process. A peer MAY do this by starting to send subsequent frames
before receiving the partner's connection header or
Normally one peer will initiate the connection close, and the partner will send its close in
- response. However, because both endpoints may simultaneously choose to close the connection
+ response. However, because both endpoints MAY simultaneously choose to close the connection
for independent reasons, it is possible for a simultaneous close to occur. In this case, the
only potentially observable difference from the perspective of each endpoint is the code
indicating the reason for the close.
@@ -679,34 +790,34 @@
Connections are subject to an idle timeout threshold. The timeout is triggered by a local
peer when no frames are received after a threshold value is exceeded. The idle timeout is
measured in milliseconds, and starts from the time the last frame is received. If the
- threshold is exceeded, then a peer should try to gracefully close the connection using a
+ threshold is exceeded, then a peer SHOULD try to gracefully close the connection using a
Each peer has its own (independent) idle timeout. At connection open each peer communicates
the maximum period between activity (frames) on the connection that it desires from its
partner.The
- If a peer can not, for any reason support a proposed idle timeout, then it should close
+ If a peer can not, for any reason support a proposed idle timeout, then it SHOULD close
the connection using a
The use of idle timeouts is in addition to any network protocol level control.
- Implementations should make use of TCP keep-alive wherever possible in order to be good
+ Implementations SHOULD make use of TCP keep-alive wherever possible in order to be good
citizens.
If a peer needs to satisfy the need to send traffic to prevent idle timeout, and has
- nothing to send, it may send an empty frame, i.e., a frame consisting solely of a frame
+ nothing to send, it MAY send an empty frame, i.e., a frame consisting solely of a frame
header, with no frame body. Implementations MUST be prepared to handle empty frames
arriving on any valid channel, though implementations SHOULD use channel 0 when sending
empty frames, and MUST use channel 0 if a maximum channel number has not yet been negotiated
@@ -784,15 +895,15 @@
In this state a In this state a The DISCARDING state is a variant of the CLOSE_SENT state where the
@@ -802,7 +913,7 @@
In this state it is illegal for either endpoint to write anything more onto the
- connection. The connection may be safely closed and discarded.
- Messages transferred on a link are sequentially identified within the session. A session may + Messages transferred on a link are sequentially identified within the session. A session can be viewed as multiplexing link traffic, much like a connection multiplexes session traffic. However, unlike the sessions on a connection, links on a session are not entirely independent since they share a common delivery sequence scoped to the session. This common @@ -932,7 +1043,7 @@
- To make it easier to monitor AMQP sessions, it is recommended that implementations always + To make it easier to monitor AMQP sessions, it is RECOMMENDED that implementations always assign the lowest available unused channel number.
@@ -993,8 +1104,8 @@
- Due to the potentially asynchronous nature of sessions, it is possible that both peers may
- simultaneously decide to end a session. If this should happen, it will appear to each peer
+ Due to the potentially asynchronous nature of sessions, it is possible that both peers
+ simultaneously decide to end a session. If this happens, it will appear to each peer
as though their partner's spontaneously initiated
In the BEGIN_SENT state, the session endpoint is assigned an outgoing channel number, - but there is no entry in the incoming channel map. In this state the endpoint may send + but there is no entry in the incoming channel map. In this state the endpoint MAY send frames but cannot receive them.
In the BEGIN_RCVD state, the session endpoint has an entry in the incoming channel - map, but has not yet been assigned an outgoing channel number. The endpoint may receive + map, but has not yet been assigned an outgoing channel number. The endpoint MAY receive frames, but cannot send them.
In the MAPPED state, the session endpoint has both an outgoing channel number and an - entry in the incoming channel map. The endpoint may both send and receive + entry in the incoming channel map. The endpoint MAY both send and receive frames.
In the END_SENT state, the session endpoint has an entry in the incoming channel map, - but is no longer assigned an outgoing channel number. The endpoint may receive frames, + but is no longer assigned an outgoing channel number. The endpoint MAY receive frames, but cannot send them.
In the END_RCVD state, the session endpoint is assigned an outgoing channel number, - but there is no entry in the incoming channel map. The endpoint may send frames, but + but there is no entry in the incoming channel map. The endpoint MAY send frames, but cannot receive them.
The next-outgoing-id is the transfer-id to assign to the next transfer frame.
- The next-outgoing-id may be initialized to an arbitrary value and is incremented
+ The next-outgoing-id MAY be initialized to an arbitrary value and is incremented
after each successive
The remote-outgoing-window reflects the maximum number of incoming transfers
- that may arrive without exceeding the remote endpoint's outgoing-window. This value MUST
+ that MAY arrive without exceeding the remote endpoint's outgoing-window. This value MUST
be decremented after every incoming
Upon sending a transfer, the sending endpoint will increment its next-outgoing-id, - decrement its remote-incoming-window, and may (depending on policy) decrement its + decrement its remote-incoming-window, and MAY (depending on policy) decrement its outgoing-window.
Upon receiving a transfer, the receiving endpoint will increment the next-incoming-id to match the implicit transfer-id of the incoming transfer plus one, as well as - decrementing the remote-outgoing-window, and may (depending on policy) decrement its + decrementing the remote-outgoing-window, and MAY (depending on policy) decrement its incoming-window.
- Termini may exist beyond their associated link endpoints, so it is possible for a session to
+ Termini can exist beyond their associated link endpoints, so it is possible for a session to
terminate and the termini to remain. A link is said to be
- Links are named so that they may be recovered when communication is interrupted. Link names
+ Links are named so that they can be recovered when communication is interrupted. Link names
MUST uniquely identify the link amongst all links of the same direction between the two
- participating containers. Link names are only used when attaching a link, so they may be
+ participating containers. Link names are only used when attaching a link, so they can be
arbitrarily long without a significant penalty.
A link's name uniquely identifies the link from the container of the source to the
container of the target node, i.e., if the container of the source node is A, and the
- container of the target node is B, the link may be globally identified by the (ordered)
- tuple (A,B,<name>). Consequently, a link may only be active in one connection
+ container of the target node is B, the link can be globally identified by the (ordered)
+ tuple (A,B,<name>). Consequently, a link can only be active in one connection
at a time. If an attempt is made to attach the link subsequently when it is not suspended,
- then the link can be 'stolen', i.e., the second attach succeeds and the first attach must
+ then the link can be 'stolen', i.e., the second attach succeeds and the first attach MUST
then be closed with a link error of
- When a link is established, an endpoint may not have all the capabilities necessary to
- create the terminus exactly matching the expectations of the peer. Should this happen, the
- endpoint MAY adjust the properties in order to succeed in creating the terminus. In this
- case the endpoint MUST report the actual properties of the terminus as created.
+ When a link is established, it is possible for an endpoint not to have all the capabilities
+ necessary to create the terminus exactly matching the expectations of the peer. If this
+ happens, the endpoint MAY adjust the properties in order to succeed in creating the
+ terminus. In this case the endpoint MUST report the actual properties of the terminus as
+ created.
- When resuming a link, the source and target properties may have changed while the link was
- suspended. When this happens, the termini properties communicated in the source and target
- fields of the
@@ -1464,7 +1576,7 @@
It is possible to resume a link even if one of the termini has lost nearly all its state.
- All that is required is the link name and direction. This is referred to as
+ All that is necessary is the link name and direction. This is referred to as
A session endpoint can choose to unmap its output handle for a link. In this case, the
endpoint MUST send a
- Note that one peer may send a closing detach while its partner is sending a non-closing
+ Note that one peer MAY send a closing detach while its partner is sending a non-closing
detach. In this case, the partner MUST signal that it has closed the link by reattaching and
then sending a closing detach.
The delivery-count is initialized by the sender when a link endpoint is
- created, and is incremented whenever a message is sent. Only the sender may
+ created, and is incremented whenever a message is sent. Only the sender MAY
independently modify this field. The receiver's value is calculated based on the last
known value from the sender and any subsequent messages received on the link. Note that,
despite its name, the delivery-count is not a count but a sequence number initialized at
@@ -1630,8 +1742,8 @@
The link-credit variable defines the current maximum legal amount that the
- delivery-count may be increased. This identifies a delivery-limit that may
- be computed by adding the link-credit to the delivery-count.
Only the receiver can independently choose a value for this field. The sender's value MUST always be maintained in such a way as to match the delivery-limit identified @@ -1665,11 +1777,11 @@ Only the sender can independently modify this field. The receiver's value is calculated based on the last known value from the sender and any subsequent incoming messages received. The sender MAY transfer messages even if the available variable is zero. - Should this happen, the receiver MUST maintain a floor of zero in it's calculation of + If this happens, the receiver MUST maintain a floor of zero in its calculation of the value of available.
The drain flag indicates how the sender should behave when insufficient messages are +
The drain flag indicates how the sender SHOULD behave when insufficient messages are available to consume the current link-credit. If set, the sender will (after sending all available messages) advance the delivery-count as much as possible, consuming all link-credit, and send the flow state to the receiver. Only the receiver can @@ -1711,7 +1823,7 @@
The initial flow state of a link endpoint is determined as follows. The link-credit
and available variables are initialized to zero. The drain flag is initialized
- to false. The sender may choose an arbitrary point to initialize the delivery-count.
+ to false. The sender MAY choose an arbitrary point to initialize the delivery-count.
This value is communicated in the initial
Stopping the transfers on a given link is accomplished by updating the link-credit to be
- zero and sending the updated
Once notified of the received message data, the application processes the message,
- indicating the updated delivery state to the link endpoint as desired. Applications may wish
+ indicating the updated delivery state to the link endpoint as desired. Applications MAY wish
to classify delivery states as
- The application may then perform some final action, e.g., remove the delivery-tag from a set + The application can then perform some final action, e.g., remove the delivery-tag from a set kept for de-duplication, and then notify the receiver that the delivery is settled. The receiver will then remove the delivery-tag from its unsettled map. Note that because the receiver knows that the delivery is already settled at the sender, it makes no effort to @@ -2071,7 +2183,7 @@
As alluded to above, it is possible for the sending application to transition a delivery to a terminal state at the sender spontaneously (i.e., not as a consequence of a disposition - that has been received from the receiver). In this case the sender should send a disposition + that has been received from the receiver). In this case the sender SHOULD send a disposition to the receiver, but not settle until the receiver confirms, via a disposition in the opposite direction, that it has updated the state at its endpoint.
@@ -2089,7 +2201,7 @@ example if the sending application settles the delivery before sending it, this results in an at-most-once guarantee. The sender has indicated up front with his initial transmission that he has forgotten everything about this delivery and will therefore - make no further attempts to send it. Should this delivery make it to the receiver, the + make no further attempts to send it. If this delivery makes it to the receiver, the receiver clearly has no obligation to respond with updates of the receiver's delivery state, as they would be meaningless and ignored by the sender. @@ -2137,10 +2249,10 @@- The sender and receiver policy regarding settling may either be preconfigured for the - entire link, thereby allowing for optimized endpoint choices, or may be determined on an - ad-hoc basis for each delivery. An application may also choose to settle at an endpoint - independently of its delivery state, for example the sending application may choose to + The sender and receiver policy regarding settling can either be preconfigured for the + entire link, thereby allowing for optimized endpoint choices, or can be determined on an + ad-hoc basis for each delivery. An application MAY also choose to settle at an endpoint + independently of its delivery state, for example the sending application MAY choose to settle a delivery due to the message ttl expiring regardless of whether the receiver has reached a terminal state.
@@ -2174,10 +2286,10 @@Note that in the case where an endpoint indicates that the unsettled map is incomplete, the absence of an entry in the unsettled map is not an indication of settlement. In this case - the two endpoints must reduce the levels of unsettled state as much as they can by the + the two endpoints MUST reduce the levels of unsettled state as much as they can by the sender resuming and/or settling transfers that it observes that the receiver considers - unsettled. Upon completion of this reduction of state, the two parties must suspend and - re-attempt to resume the link. Only when both sides have complete unsettled maps may new + unsettled. Upon completion of this reduction of state, the two parties MUST suspend and + re-attempt to resume the link. Only when both sides have complete unsettled maps can new unsettled state be created by the sending of non-resuming transfers.
@@ -2202,9 +2314,9 @@
- Each
- The sender may indicate an aborted attempt to deliver a message by setting the abort flag on
+ The sender MAY indicate an aborted attempt to deliver a message by setting the abort flag on
the last
The name of the host (either fully qualified or relative) to which the sending peer is connecting. It is not mandatory to provide the hostname. If no hostname is provided - the receiving peer should select a default based on its own configuration. This field + the receiving peer SHOULD select a default based on its own configuration. This field can be used by AMQP proxies to determine the correct back-end service to connect the client to.
- This field may already have been specified by the
- The channel-max value is the highest channel number that may be used on the connection.
+ The channel-max value is the highest channel number that can be used on the connection.
This value plus one is the maximum number of sessions that can be simultaneously active
on the connection. A peer MUST not use channel numbers outside the range that its
partner can handle. A peer that receives a channel number outside the supported range
@@ -2344,15 +2456,15 @@
- The idle timeout required by the sender (see
If the value is not set, then the sender does not have an idle time-out. However,
- senders doing this should be aware that implementations MAY choose to use an
+ senders doing this SHOULD be aware that implementations MAY choose to use an
internal default to efficiently manage a peer's resources.
The desired-capability list defines which extension capabilities the sender MAY use if
@@ -2474,10 +2586,10 @@
- The handle-max value is the highest handle value that may be used on the session.
+ The handle-max value is the highest handle value that can be used on the session.
A peer MUST NOT attempt to attach a link using a handle value outside the range that its
partner can handle. A peer that receives a handle outside the supported range MUST close
the connection with the framing-error error-code.
@@ -2496,7 +2608,7 @@
The sender MUST NOT attempt to use any capability other than those it has declared in
@@ -2537,7 +2649,7 @@
This name uniquely identifies the link from the container of the source to the container
of the target node, e.g., if the container of the source node is A, and the container of
- the target node is B, the link may be globally identified by the (ordered) tuple
+ the target node is B, the link MAY be globally identified by the (ordered) tuple
(A,B,<name>).
- To make it easier to monitor AMQP link attach frames, it is recommended that
+ To make it easier to monitor AMQP link attach frames, it is RECOMMENDED that
implementations always assign the lowest available handle to this field.
The sender MUST NOT attempt to use any capability other than those it has declared in
@@ -2856,7 +2968,7 @@
- If set to true then the receiver should send its state at the earliest convenient
+ If set to true then the receiver SHOULD send its state at the earliest convenient
opportunity.
@@ -2871,8 +2983,8 @@
Note that if a peer responds to echo requests with flows which themselves have the echo
- field set to true, an infinite loop may result if its partner adopts the same policy
- (therefore such a policy should be avoided).
+ field set to true, an infinite loop could result if its partner adopts the same policy
+ (therefore such a policy SHOULD be avoided).
- The transfer frame is used to send messages across a link. Messages may be carried by a
+ The transfer frame is used to send messages across a link. Messages MAY be carried by a
single transfer up to the maximum negotiated frame size for the connection. Larger
- messages may be split across several transfer frames.
+ messages MAY be split across several transfer frames.
Uniquely identifies the delivery attempt for a given message on this link. This field
- MUST be specified for the first transfer of a multi-transfer message and may only be
+ MUST be specified for the first transfer of a multi-transfer message and can only be
omitted for continuation transfers. It is an error if the delivery-tag on a continuation
transfer differs from the delivery-tag on the first transfer of a delivery.
- This field MUST be specified for the first transfer of a multi-transfer message and may
+ This field MUST be specified for the first transfer of a multi-transfer message and can
only be omitted for continuation transfers. It is an error if the message-format on a
continuation transfer differs from the message-format on the first transfer of a
delivery.
@@ -2956,7 +3068,7 @@
If the negotiated value for snd-settle-mode at attachment is
@@ -2972,7 +3084,7 @@
Note that if both the more and aborted fields are set to true, the aborted flag takes
- precedence. That is, a receiver should ignore the value of the more field if the
+ precedence. That is, a receiver SHOULD ignore the value of the more field if the
transfer is marked as aborted. A sender SHOULD NOT set the more flag to true if it
also sets the aborted flag to true.
If a resumed delivery spans more than one transfer performative, then the resume flag
MUST be set to true on the first transfer of the resumed delivery. For subsequent
- transfers for the same delivery the resume flag may be set to true, or may be omitted.
+ transfers for the same delivery the resume flag MAY be set to true, or MAY be omitted.
In the case where the exchange of unsettled maps makes clear that all message data has
been successfully transferred to the receiver, and that only the final state (and
- potentially settlement) at the sender needs to be conveyed, then a resumed delivery may
+ potentially settlement) at the sender needs to be conveyed, then a resumed delivery MAY
carry no payload and instead act solely as a vehicle for carrying the terminal state of
the delivery at the sender.
- Aborted messages should be discarded by the recipient (any payload within the frame
+ Aborted messages SHOULD be discarded by the recipient (any payload within the frame
carrying the performative MUST be ignored). An aborted message is implicitly settled.
If true, then the issuer is hinting that there is no need for the peer to urgently
- communicate updated delivery state. This hint may be used to artificially increase the
+ communicate updated delivery state. This hint MAY be used to artificially increase the
amount of batching an implementation uses when communicating delivery states, and
thereby save bandwidth.
The disposition frame is used to inform the remote peer of local changes in the state of
- deliveries. The disposition frame may reference deliveries from many different links
+ deliveries. The disposition frame MAY reference deliveries from many different links
associated with a session, although all links MUST have the directionality indicated by
the specified role.
- The disposition performative may refer to deliveries on links that are no longer attached.
+ The disposition performative MAY refer to deliveries on links that are no longer attached.
As long as the links have not been closed or detached with an error then the deliveries
are still "live" and the updated state MUST be applied.
If true, then the issuer is hinting that there is no need for the peer to urgently
- communicate the impact of the updated delivery states. This hint may be used to
+ communicate the impact of the updated delivery states. This hint MAY be used to
artificially increase the amount of batching an implementation uses when communicating
delivery states, and thereby save bandwidth.
If set, this field indicates that the link is being detached due to an error condition.
- The value of the field should contain details on the cause of the error.
+ The value of the field SHOULD contain details on the cause of the error.
If set, this field indicates that the session is being ended due to an error condition.
- The value of the field should contain details on the cause of the error.
+ The value of the field SHOULD contain details on the cause of the error.
If set, this field indicates that the connection is being closed due to an error
- condition. The value of the field should contain details on the cause of the error.
+ condition. The value of the field SHOULD contain details on the cause of the error.
- The sender may send a mixture of settled and unsettled deliveries to the receiver.
+ The sender MAY send a mixture of settled and unsettled deliveries to the receiver.
An alias established by the
- A delivery-tag may be up to 32 octets of binary data. + A delivery-tag can be up to 32 octets of binary data.
- All AMQP implementations should understand at the least the IETF language tag + All AMQP implementations SHOULD understand at the least the IETF language tag en-US (note that this uses a hyphen separator, not an underscore).
@@ -3414,7 +3526,7 @@- An internal error occurred. Operator intervention may be required to resume normal + An internal error occurred. Operator intervention might be necessary to resume normal operation.
- An operator intervened to close the connection for some reason. The client may retry at - some later date. + An operator intervened to close the connection for some reason. The client could retry + at some later date.
- The container is no longer available on the current connection. The peer should + The container is no longer available on the current connection. The peer SHOULD attempt reconnection to the container using the details provided in the info map.
- the hostname of the container. This is the value that should be supplied in the
+ the hostname of the container. This is the value that SHOULD be supplied in the
hostname field of the
The address provided cannot be resolved to a terminus at the current container. - The info map may contain the following information to allow the client to locate + The info map MAY contain the following information to allow the client to locate the attach to the terminus.
- the hostname of the container hosting the terminus. This is the value that should
+ the hostname of the container hosting the terminus. This is the value that SHOULD
be supplied in the hostname field of the
- Implementations listening on this port should NOT expect a protocol handshake before TLS + Implementations listening on this port SHOULD NOT expect a protocol handshake before TLS is negotiated.
- During the initial connection negotiation, the two peers must agree upon a maximum frame
+ 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
Index: specification/messaging.xml
===================================================================
--- specification/messaging.xml (revision 111)
+++ specification/messaging.xml (revision 123)
@@ -88,7 +88,7 @@
- The term message is used with various connotations in the messaging world. The sender may
+ 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
@@ -201,8 +201,8 @@
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
- Duration in milliseconds for which the message should be considered "live". If this is
+ 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
+ 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.
@@ -286,9 +286,9 @@
The number of unsuccessful previous attempts to deliver this message. If this value is
- non-zero it may be taken as an indication that the delivery may 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.
+ 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 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
+ 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
The capabilities negotiated on link
- Message-id is an optional property which 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.
+ 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 to field identifies the node that is the intended destination of the message. On any
- given transfer this may not be the node at the receiving end of the link.
+ given transfer this might not be the node at the receiving end of the link.
- This is a client-specific id that may be used to mark or identify messages between
+ This is a client-specific id that can be used to mark or identify messages between
clients.
The RFC-2046 [
@@ -447,8 +447,8 @@
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 must be applied in order to
- obtain the media-type referenced by the content-type header field.
+ 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
@@ -466,7 +466,7 @@
Implementations MUST NOT use the identity encoding. Instead, implementations
- should not set this property. Implementations SHOULD NOT
+ 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.
The application-properties section is a part of the bare message used for structured
- application data. Intermediaries may use the data within this structure for the purposes
+ application data. Intermediaries can use the data within this structure for the purposes
of filtering or routing.
- State transitions may also occur spontaneously at the distribution node. For example if a - message with a ttl expires, the effect of expiry may be (depending on specific type and + 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. @@ -695,7 +695,7 @@
The messaging layer defines a concrete set of delivery states which can be used (via the
When sent by the receiver this indicates the first section of the message for which - all data may not yet have been received. + all data might not yet have been received.
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 may indicate + (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. @@ -794,7 +794,7 @@
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 may become accepted at the source even before all transfer frames have been
+ 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
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 required action. The delivery + 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.
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 + will not be acted upon, and that the message SHOULD be modified in the specified ways at the node.
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 must resume sending from some - point before or at the next position which the receiver is expecting. + 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.
For delivery-tags 10 to 14 inclusive the sender indicates that it has reached a terminal
outcome, namely
- For delivery-tag 11 it must be assumed that the sender spontaneously attained the terminal + 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.
@@ -1130,7 +1130,7 @@ 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. + outcome, but neither has settled. In this case the sender SHOULD simply settle the delivery.
- The source defines an optional distribution-mode that informs and/or indicates how + 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 @@ -1233,9 +1233,9 @@ 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 + 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 may simply be a record of the most recent message transferred. + node, the state might simply be a record of the most recent message transferred.
@@ -1323,7 +1323,7 @@
label="properties of the dynamically created node">
- If the dynamic field is not set to true this field must be left unset.
+ 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
@@ -1378,7 +1378,7 @@
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
When present, the values MUST be a symbolic descriptor of a valid outcome, e.g.,
@@ -1480,7 +1480,7 @@
label="properties of the dynamically created node">
- If the dynamic field is not set to true this field must be left unset.
+ 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
@@ -1599,10 +1599,10 @@
- A set of named filters. Every key in the map must be of type
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
+ 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:
- 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
+ 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:
Index: tools/xml2latex.xsl
===================================================================
--- tools/xml2latex.xsl (revision 111)
+++ tools/xml2latex.xsl (revision 123)
@@ -309,19 +309,21 @@
-
Type:
+
+Encoding Code Category Description
+
+
@@ -682,6 +700,11 @@
- <type <type
-
Revision Changes
+
+