From efcb5917848b17fcb10d82daf5e20cb2e7f0e1f6 Mon Sep 17 00:00:00 2001 From: "Rafael H. Schloming" Date: Wed, 1 May 2013 17:02:02 +0000 Subject: QPID-4798: added stripped versions of 0-8 and 0-9 git-svn-id: https://svn.apache.org/repos/asf/qpid/trunk@1478092 13f79535-47bb-0310-9956-ffa450edef68 --- qpid/specs/amqp.0-8.stripped.xml | 1374 ++++++++++++++++++++++++++++++++++++++ qpid/specs/amqp.0-9.stripped.xml | 1155 ++++++++++++++++++++++++++++++++ 2 files changed, 2529 insertions(+) create mode 100644 qpid/specs/amqp.0-8.stripped.xml create mode 100644 qpid/specs/amqp.0-9.stripped.xml diff --git a/qpid/specs/amqp.0-8.stripped.xml b/qpid/specs/amqp.0-8.stripped.xml new file mode 100644 index 0000000000..2c2c069135 --- /dev/null +++ b/qpid/specs/amqp.0-8.stripped.xml @@ -0,0 +1,1374 @@ + + + + + +AMQ Protocol 0.80 + + + + + + + + + + +Indicates that the method completed successfully. This reply code is + reserved for future use - the current protocol design does not use + positive confirmation and reply codes are sent only in case of an + error. + +The client asked for a specific message that is no longer available. + The message was delivered to another client, or was purged from the + queue for some other reason. + +The client attempted to transfer content larger than the server + could accept at the present time. The client may retry at a later + time. + +An operator intervened to close the connection for some reason. + The client may retry at some later date. + +The client tried to work with an unknown virtual host or cluster. + +The client attempted to work with a server entity to which it has + no due to security settings. + +The client attempted to work with a server entity that does not exist. + +The client attempted to work with a server entity to which it has + no access because another client is working with it. + +The client sent a malformed frame that the server could not decode. + This strongly implies a programming error in the client. + +The client sent a frame that contained illegal values for one or more + fields. This strongly implies a programming error in the client. + +The client sent an invalid sequence of frames, attempting to perform + an operation that was considered invalid by the server. This usually + implies a programming error in the client. + +The client attempted to work with a channel that had not been + correctly opened. This most likely indicates a fault in the client + layer. + +The server could not complete the method because it lacked sufficient + resources. This may be due to the client creating too many of some + type of entity. + +The client tried to work with some entity in a manner that is + prohibited by the server, due to security settings or by some other + criteria. + +The client tried to use functionality that is not implemented in the + server. + +The server could not complete the method because of an internal error. + The server may require intervention by an operator in order to resume + normal operations. + +access ticket granted by server + + + +consumer tag +The consumer tag is valid only within the channel from which the + consumer was created. I.e. a client MUST NOT create a consumer in + one channel and then use it in another. + + +server-assigned delivery tag +The delivery tag is valid only within the channel from which the + message was received. I.e. a client MUST NOT receive a message on + one channel and then acknowledge it on another. + +The server MUST NOT use a zero value for delivery tags. Zero is + reserved for client use, meaning "all messages so far received". + + +exchange name + + +list of known hosts +The server MAY leave this field empty if it knows of no other +hosts than itself. + + + +no acknowledgement needed + +do not deliver own messages + + + + + + + +The properties SHOULD contain these fields: +"product", giving the name of the peer product, "version", giving +the name of the peer version, "platform", giving the name of the +operating system, "copyright", if appropriate, and "information", +giving other general information. + + +queue name + + +message is being redelivered +The server SHOULD try to signal redelivered messages when it can. + When redelivering a message that was not successfully acknowledged, + the server SHOULD deliver it to the original client if possible. + +The client MUST NOT rely on the redelivered field but MUST take it + as a hint that the message may already have been processed. A + fully robust client must be able to track duplicate received messages + on non-transacted, and locally-transacted channels. + + +reply code from server + + +localised reply text + + +work with socket connections + + +start connection negotiation +If the client cannot handle the protocol version suggested by the + server it MUST close the socket connection. + +The server MUST provide a protocol version that is lower than or + equal to that requested by the client in the protocol header. If + the server cannot support the specified protocol it MUST NOT send + this method, but MUST close the socket connection. + + + +protocol major version + +protocol major version + +server properties + +available security mechanisms + + + +available message locales +All servers MUST support at least the en_US locale. + + + + +select security mechanism and locale + +client properties + +selected security mechanism +The client SHOULD authenticate using the highest-level security + profile it can handle from the list provided by the server. + +The mechanism field MUST contain one of the security mechanisms + proposed by the server in the Start method. If it doesn't, the + server MUST close the socket. + + + +security response data + + +selected message locale + + + +security mechanism challenge + + +security challenge data + + + +security mechanism response + +security response data + + + +propose connection tuning parameters + + +proposed maximum channels + +proposed maximum frame size +Until the frame-max has been negotiated, both peers MUST accept + frames of up to 4096 octets large. The minimum non-zero value for + the frame-max field is 4096. + + +desired heartbeat delay + + +negotiate connection tuning parameters + +negotiated maximum channels +The server MAY ignore the channel-max value or MAY use it for + tuning its resource allocation. + + + + +negotiated maximum frame size +Until the frame-max has been negotiated, both peers must accept + frames of up to 4096 octets large. The minimum non-zero value for + the frame-max field is 4096. + + +desired heartbeat delay + + +open connection to virtual host +The client MUST open the context before doing any work on the + connection. + + + + +virtual host name + +If the server supports multiple virtual hosts, it MUST enforce a + full separation of exchanges, queues, and all associated entities + per virtual host. An application, connected to a specific virtual + host, MUST NOT be able to access resources of another virtual host. + +The server SHOULD verify that the client has permission to access + the specified virtual host. + +The server MAY configure arbitrary limits per virtual host, such + as the number of each type of entity that may be used, per + connection and/or in total. + + +required capabilities + +insist on connecting to server +When the client uses the insist option, the server SHOULD accept + the client connection unless it is technically unable to do so. + + + +signal that the connection is ready + + + +asks the client to use a different server +When getting the Connection.Redirect method, the client SHOULD + reconnect to the host specified, and if that host is not present, + to any of the hosts specified in the known-hosts list. + + +server to connect to + + + + +request a connection close +After sending this method any received method except the Close-OK + method MUST be discarded. + +The peer sending this method MAY use a counter or timeout to + detect failure of the other peer to respond correctly with + the Close-OK method. + +When a server receives the Close method from a client it MUST + delete all server-side resources associated with the client's + context. A client CANNOT reconnect to a context after sending + or receiving a Close method. + + + + + + +failing method class + +failing method ID + + +confirm a connection close +A peer that detects a socket closure without having received a + Close-Ok handshake method SHOULD log the error. + + + + + +work with channels + + +open a channel for use +This method MUST NOT be called when the channel is already open. + + + +out-of-band settings + + + +signal that the channel is ready + + +enable/disable flow from peer +When a new channel is opened, it is active. Some applications + assume that channels are inactive until started. To emulate this + behaviour a client MAY open the channel, then pause it. + +When sending content data in multiple frames, a peer SHOULD monitor + the channel for incoming methods and respond to a Channel.Flow as + rapidly as possible. + +A peer MAY use the Channel.Flow method to throttle incoming content + data for internal reasons, for example, when exchangeing data over a + slower connection. + +The peer that requests a Channel.Flow method MAY disconnect and/or + ban a peer that does not respect the request. + + + + +start/stop content frames + + +confirm a flow method + + +current flow setting + + +send a non-fatal warning message + + + +detailed information for warning + + +request a channel close +After sending this method any received method except + Channel.Close-OK MUST be discarded. + +The peer sending this method MAY use a counter or timeout to detect + failure of the other peer to respond correctly with Channel.Close-OK.. + + + + + + +failing method class + +failing method ID + + +confirm a channel close +A peer that detects a socket closure without having received a + Channel.Close-Ok handshake method SHOULD log the error. + + + + + +work with access tickets + + +request an access ticket +The realm name MUST start with either "/data" (for application + resources) or "/admin" (for server administration resources). + If the realm starts with any other path, the server MUST raise + a connection exception with reply code 403 (access refused). + +The server MUST implement the /data realm and MAY implement the + /admin realm. The mapping of resources to realms is not + defined in the protocol - this is a server-side configuration + issue. + + + +name of requested realm +If the specified realm is not known to the server, the server + must raise a channel exception with reply code 402 (invalid + path). + + +request exclusive access + +request passive access + +request active access + +request write access + +request read access + + +grant access to server resources +The client MUST NOT use access tickets except within the same + channel as originally granted. + +The server MUST isolate access tickets per channel and treat an + attempt by a client to mix these as a connection exception. + + + + + +work with exchanges + + + +amq_exchange_19 +The server MUST implement the direct and fanout exchange types, and + predeclare the corresponding exchanges named amq.direct and amq.fanout + in each virtual host. The server MUST also predeclare a direct + exchange to act as the default exchange for content Publish methods + and for default queue bindings. + + +amq_exchange_20 +The server SHOULD implement the topic exchange type, and predeclare + the corresponding exchange named amq.topic in each virtual host. + + +amq_exchange_21 +The server MAY implement the system exchange type, and predeclare the + corresponding exchanges named amq.system in each virtual host. If the + client attempts to bind a queue to the system exchange, the server + MUST raise a connection exception with reply code 507 (not allowed). + + +amq_exchange_22 +The default exchange MUST be defined as internal, and be inaccessible + to the client except by specifying an empty exchange name in a content + Publish method. That is, the server MUST NOT let clients make explicit + bindings to this exchange. + +declare exchange, create if needed + +amq_exchange_23 +The server SHOULD support a minimum of 16 exchanges per virtual host + and ideally, impose no limit except as defined by available resources. + + + + +The client MUST provide a valid access ticket giving "active" access + to the realm in which the exchange exists or will be created, or + "passive" access if the if-exists flag is set. + + + + +amq_exchange_15 +Exchange names starting with "amq." are reserved for predeclared + and standardised exchanges. If the client attempts to create an + exchange starting with "amq.", the server MUST raise a channel + exception with reply code 403 (access refused). + + + +exchange type + +amq_exchange_16 +If the exchange already exists with a different type, the server + MUST raise a connection exception with a reply code 507 (not allowed). + + +amq_exchange_18 +If the server does not support the requested exchange type it MUST + raise a connection exception with a reply code 503 (command invalid). + + + +do not create exchange + +amq_exchange_05 +If set, and the exchange does not already exist, the server MUST + raise a channel exception with reply code 404 (not found). + + +request a durable exchange + +amq_exchange_24 +The server MUST support both durable and transient exchanges. + +The server MUST ignore the durable field if the exchange already + exists. + + +auto-delete when unused + +amq_exchange_02 +The server SHOULD allow for a reasonable delay between the point + when it determines that an exchange is not being used (or no longer + used), and the point when it deletes the exchange. At the least it + must allow a client to create an exchange and then bind a queue to + it, with a small but non-zero delay between these two actions. + + +amq_exchange_25 +The server MUST ignore the auto-delete field if the exchange already + exists. + + +create internal exchange + +do not send a reply method + +arguments for declaration + + +confirms an exchange declaration + + +delete an exchange + + + +The client MUST provide a valid access ticket giving "active" + access rights to the exchange's access realm. + + + + +amq_exchange_11 +The exchange MUST exist. Attempting to delete a non-existing exchange + causes a channel exception. + + + +delete only if unused + +amq_exchange_12 +If set, the server SHOULD delete the exchange but only if it has + no queue bindings. + + +amq_exchange_13 +If set, the server SHOULD raise a channel exception if the exchange is in + use. + + +do not send a reply method + + +confirm deletion of an exchange + + + + + +Message routing key + + + + + + + + + +work with queues + + + +amq_queue_33 +A server MUST allow any content class to be sent to any queue, in any + mix, and queue and delivery these content classes independently. Note + that all methods that fetch content off queues are specific to a given + content class. + +declare queue, create if needed + +amq_queue_34 +The server MUST create a default binding for a newly-created queue + to the default exchange, which is an exchange of type 'direct'. + + +amq_queue_35 +The server SHOULD support a minimum of 256 queues per virtual host + and ideally, impose no limit except as defined by available resources. + + + + + + +amq_queue_10 +The queue name MAY be empty, in which case the server MUST create + a new queue with a unique generated name and return this to the + client in the Declare-Ok method. + + +amq_queue_32 +Queue names starting with "amq." are reserved for predeclared and + standardised server queues. If the queue name starts with "amq." + and the passive option is zero, the server MUST raise a connection + exception with reply code 403 (access refused). + + + +do not create queue + +amq_queue_05 +If set, and the queue does not already exist, the server MUST + respond with a reply code 404 (not found) and raise a channel + exception. + + +request a durable queue + +amq_queue_03 +The server MUST recreate the durable queue after a restart. + + +amq_queue_36 +The server MUST support both durable and transient queues. + + +amq_queue_37 +The server MUST ignore the durable field if the queue already + exists. + + +request an exclusive queue + +amq_queue_38 +The server MUST support both exclusive (private) and non-exclusive + (shared) queues. + + +amq_queue_04 +The server MUST raise a channel exception if 'exclusive' is specified + and the queue already exists and is owned by a different connection. + + +auto-delete queue when unused + +amq_queue_02 +The server SHOULD allow for a reasonable delay between the point + when it determines that a queue is not being used (or no longer + used), and the point when it deletes the queue. At the least it + must allow a client to create a queue and then create a consumer + to read from it, with a small but non-zero delay between these + two actions. The server should equally allow for clients that may + be disconnected prematurely, and wish to re-consume from the same + queue without losing messages. We would recommend a configurable + timeout, with a suitable default value being one minute. + + +amq_queue_31 +The server MUST ignore the auto-delete field if the queue already + exists. + + +do not send a reply method + +arguments for declaration + + +confirms a queue definition + + + + +number of messages in queue + +number of consumers + + +bind queue to an exchange + +amq_queue_25 +A server MUST allow ignore duplicate bindings - that is, two or + more bind methods for a specific queue, with identical arguments + - without treating these as an error. + + +amq_queue_39 +If a bind fails, the server MUST raise a connection exception. + + +amq_queue_12 +The server MUST NOT allow a durable queue to bind to a transient + exchange. If the client attempts this the server MUST raise a + channel exception. + + +amq_queue_13 +Bindings for durable queues are automatically durable and the + server SHOULD restore such bindings after a server restart. + + +amq_queue_17 +If the client attempts to an exchange that was declared as internal, + the server MUST raise a connection exception with reply code 530 + (not allowed). + + +amq_queue_40 +The server SHOULD support at least 4 bindings per queue, and + ideally, impose no limit except as defined by available resources. + + + + + +The name of the exchange to bind to. + +amq_queue_14 +If the exchange does not exist the server MUST raise a channel + exception with reply code 404 (not found). + + +message routing key + +do not send a reply method + +arguments for binding + + +confirm bind successful + + +purge a queue + +amq_queue_15 +A call to purge MUST result in an empty queue. + + +amq_queue_41 +On transacted channels the server MUST not purge messages that have + already been sent to a client but not yet acknowledged. + + +amq_queue_42 +The server MAY implement a purge queue or log that allows system + administrators to recover accidentally-purged messages. The server + SHOULD NOT keep purged messages in the same storage spaces as the + live messages since the volumes of purged messages may get very + large. + + + + +The client MUST provide a valid access ticket giving "read" access + rights to the queue's access realm. Note that purging a queue is + equivalent to reading all messages and discarding them. + + + +do not send a reply method + + +confirms a queue purge + +number of messages purged + + +delete a queue + +amq_queue_43 +The server SHOULD use a dead-letter queue to hold messages that + were pending on a deleted queue, and MAY provide facilities for + a system administrator to move these messages back to an active + queue. + + + + + +delete only if unused + +amq_queue_29 + +amq_queue_30 +The server MUST respect the if-unused flag when deleting a queue. + + +delete only if empty +amq_queue_27 + + +do not send a reply method + + +confirm deletion of a queue + +number of messages purged + + + +work with basic content + + +MIME content type + +MIME content encoding + +Message header field table + +Non-persistent (1) or persistent (2) + +The message priority, 0 to 9 + +The application correlation identifier + +The destination to reply to + +Message expiration specification + +The application message identifier + +The message timestamp + +The message type name + +The creating user id + +The creating application id + +Intra-cluster routing identifier + +specify quality of service + + +prefetch window in octets + +prefetch window in messages + +apply to entire connection + + +confirm the requested qos + + +start a queue consumer + + + + + + + +request exclusive access + +do not send a reply method + + + +confirm a new consumer + + + +end a queue consumer + + + +do not send a reply method + + +confirm a cancelled consumer + + + +publish a message + + + +Message routing key + +indicate mandatory routing + +request immediate delivery + + +return a failed message + + + + +Message routing key + + +notify the client of a consumer message + + + + + +Message routing key + + +direct access to a queue + + + + + + + +provide client with a message + + + + +Message routing key + +number of messages pending + + +indicate no messages available + +Cluster id + + +acknowledge one or more messages + + +acknowledge multiple messages + + +reject an incoming message + + +requeue the message + + +redeliver unacknowledged messages + +requeue the message + + + +confirm a successful recover + + + +work with file content + + +MIME content type + +MIME content encoding + +Message header field table + +The message priority, 0 to 9 + +The destination to reply to + +The application message identifier + +The message filename + +The message timestamp + +Intra-cluster routing identifier + +specify quality of service + + +prefetch window in octets + +prefetch window in messages + +apply to entire connection + + +confirm the requested qos + + +start a queue consumer + + + + + + + +request exclusive access + +do not send a reply method + + +confirm a new consumer + + + +end a queue consumer + + + +do not send a reply method + + +confirm a cancelled consumer + + + +request to start staging + + + +staging identifier + +message content size + + +confirm staging ready + + + +already staged amount + + +stage message content + + + +publish a message + + + +Message routing key + +indicate mandatory routing + +request immediate delivery + +staging identifier + + +return a failed message + + + + +Message routing key + + +notify the client of a consumer message + + + + + +Message routing key + +staging identifier + + +acknowledge one or more messages + + +acknowledge multiple messages + + +reject an incoming message + + +requeue the message + + + +work with streaming content + + +MIME content type + +MIME content encoding + +Message header field table + +The message priority, 0 to 9 + +The message timestamp + +specify quality of service + + +prefetch window in octets + +prefetch window in messages + +transfer rate in octets/second + +apply to entire connection + + +confirm the requested qos + + +start a queue consumer + + + + + + +request exclusive access + +do not send a reply method + + +confirm a new consumer + + + +end a queue consumer + + + +do not send a reply method + + +confirm a cancelled consumer + + + +publish a message + + + +Message routing key + +indicate mandatory routing + +request immediate delivery + + +return a failed message + + + + +Message routing key + + +notify the client of a consumer message + + + + + + + + + +work with standard transactions +An client using standard transactions SHOULD be able to track all + messages received within a reasonable period, and thus detect and + reject duplicates of the same message. It SHOULD NOT pass these to + the application layer. + + + +select standard transaction mode + + + +confirm transaction mode + + +commit the current transaction + + + +confirm a successful commit + + +abandon the current transaction + + + +confirm a successful rollback + + + +work with distributed transactions + + +select standard transaction mode + + + +confirm transaction mode + + +start a new distributed transaction + + +transaction identifier + + + +confirm the start of a new distributed transaction + + + +methods for protocol tunneling. + + +Message header field table + +The identity of the tunnelling proxy + +The name or type of the message being tunnelled + +The message durability indicator + +The message broadcast mode + +sends a tunnelled method + +meta data for the tunnelled block + + + +test functional primitives of the implementation + + +test integer handling + + + +octet test value + +short test value + +long test value + +long-long test value + +operation to test + +return sum of test values + +return lowest of test values + +return highest of test values + + + + +report integer test result + + +result value + + +test string handling + + + +short string test value + +long string test value + +operation to test + +return concatentation of test strings + +return shortest of test strings + +return longest of test strings + + + + +report string test result + + +result value + + +test field table handling + + + +field table of test values + +operation to test on integers + +return sum of numeric field values + +return min of numeric field values + +return max of numeric field values + + + +operation to test on strings + +return concatenation of string field values + +return shortest of string field values + +return longest of string field values + + + + +report table test result + + +integer result value + +string result value + + +test content handling + + + + +report content test result + + +content hash + + + diff --git a/qpid/specs/amqp.0-9.stripped.xml b/qpid/specs/amqp.0-9.stripped.xml new file mode 100644 index 0000000000..623c99616a --- /dev/null +++ b/qpid/specs/amqp.0-9.stripped.xml @@ -0,0 +1,1155 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Message routing key + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +redeliver unacknowledged messages + +requeue the message + + + +confirm a successful recover + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.1