diff options
Diffstat (limited to 'qpid/specs/amqp-transitional.0-10.xml')
| -rw-r--r-- | qpid/specs/amqp-transitional.0-10.xml | 247 |
1 files changed, 0 insertions, 247 deletions
diff --git a/qpid/specs/amqp-transitional.0-10.xml b/qpid/specs/amqp-transitional.0-10.xml index b1fe81373a..7949ed7ed9 100644 --- a/qpid/specs/amqp-transitional.0-10.xml +++ b/qpid/specs/amqp-transitional.0-10.xml @@ -6253,252 +6253,6 @@ <chassis name="client" implement="MUST" /> <!-- - Method: message.transfer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> - <method name="transfer" index="10" label="transfer a message"> - <doc> - This method transfers a message between two peers. When a client uses this method to publish - a message to a broker, the destination identifies a specific exchange. The message will then - be routed to queues as defined by the exchange configuration and distributed to any active - consumers when the transaction, if any, is committed. - - In the asynchronous message delivery model, the client starts a consumer using the Consume - method and passing in a destination, then the broker responds with transfer methods to the - specified destination as and when messages arrive for that consumer. - - If synchronous message delivery is required, the client may issue a get request which on - success causes a single message to be transferred to the specified destination. - - Message acknowledgement is signalled by the return result of this method. - </doc> - - <rule name="process-before-ok"> - <doc> - The recipient MUST NOT return ok before the message has been processed as defined by the - QoS settings. - </doc> - </rule> - - <chassis name="server" implement="MUST" /> - <chassis name="client" implement="MUST" /> - - <field name="ticket" domain="access-ticket" label="access ticket"> - <rule name="validity" on-failure="access-refused"> - <doc> - The client MUST provide a valid access ticket giving "passive" access rights to the - realm for the exchange and "write" access rights to the realm for the queue to which the - message will be published. - </doc> - </rule> - </field> - - <field name="destination" domain="destination" label="message distination"> - <doc> - Specifies the destination to which the message is to be transferred. The destination can - be empty, meaning the default exchange or consumer. If the destination is specified, and - that exchange or consumer does not exist, the peer must raise a channel exception. - </doc> - - <rule name="blank-destination"> - <doc> - The server MUST accept a blank destination to mean the default exchange. - </doc> - </rule> - - <rule name="internal-exchange"> - <doc> - If the destination refers to an internal exchange, the server MUST raise a channel - exception with a reply code 403 (access refused). - </doc> - </rule> - - <rule name="message-refusal"> - <doc> - A destination MAY refuse message content in which case it MUST raise a channel exception - with reply code 540 (not implemented). - </doc> - </rule> - </field> - - <field name="redelivered" domain="redelivered" label="redelivery flag"> - <doc> - This boolean flag indicates that the message has been previously delivered to this or - another client. - </doc> - </field> - - <field name="reject-unroutable" domain="bit" label="reject message if unroutable flag"> - <doc> - If the reject-unroutable flag is set, then at the time of publishing the broker determines - if the message will be routed to any queues. If it will not be routed to any queue then - the broker responds with a message.reject. - </doc> - </field> - - <field name="immediate" domain="bit" label="request immediate delivery"> - </field> - - <field name="ttl" domain="duration" label="time to live"> - <doc> - If this is set to a non zero value then a message expiration time will be computed based - on the current time plus this value. Messages that live longer than their expiration time - will be discarded (or dead lettered). - </doc> - <rule name="ttl-decrement"> - <doc> - If a message is transfered between brokers before delivery to a final consumer the ttl - should be decremented before peer to peer transfer and both timestamp and expiration - should be cleared. - </doc> - </rule> - </field> - - <!-- begin headers --> - <field name="priority" domain="octet" label="message priority, 0 to 9"> - <doc> - Message priority, which can be between 0 and 9. Messages with higher priorities may be - delivered before those with lower priorities. - </doc> - </field> - - <field name="timestamp" domain="timestamp" label="message timestamp"> - <doc> - The timestamp is set by the broker on arrival of the message. - </doc> - </field> - - <field name="delivery-mode" domain="octet" label="message persistence"> - <doc> - The delivery mode may be non-persistent (1) or persistent (2). A persistent message is one - which must be stored on a persistent medium (usually hard drive) at every stage of - delivery so that it will not be lost in event of failure (other than the medium itself). - This is normally accomplished with some additional overhead. A persistent message may be - delivered more than once if there is uncertainty about the state of its delivery after a - failure and recovery. - - Conversely, a non-persistent message may be lost in event of a failure, but the nature of - the communication is such that an occasional message loss is tolerable. This is the lowest - overhead mode. Non-persistent messages are delivered at most once only. - </doc> - </field> - - <field name="expiration" domain="timestamp" label="message expiration time"> - <doc> - The expiration header assigned by the broker. After receiving the message the broker sets - expiration to the sum of the ttl specified in the publish method and the current time. - (ttl=expiration - timestamp) - </doc> - </field> - - <field name="exchange" domain="exchange-name" label="originating exchange"> - <doc> - The exchange name is a client-selected string that identifies the exchange for transfer - methods. Exchange names may consist of any mixture of digits, letters, and underscores. - Exchange names are scoped by the virtual host. - </doc> - </field> - - <field name="routing-key" domain="shortstr" label="message routing key"> - <doc> - The value of the key determines to which queue the exchange will send the message. The way - in which keys are used to make this routing decision depends on the type of exchange to - which the message is sent. For example, a direct exchange will route a message to a queue - if that queue is bound to the exchange with an identical key to that of the message. - </doc> - </field> - - <field name="message-id" domain="shortstr" label="application message identifier"> - <doc> - This is a unique identifier for the message that is guaranteed to be unique across - multiple instances, sessions and in time. This allows duplicate messages to be detected. - This may be a UUID. Note that this is usually set by the server when it first receives a - message. - - If a client wishes to identify a message, it should use the correlation-id instead. - </doc> - </field> - - <field name="correlation-id" domain="shortstr" label="application correlation identifier"> - <doc> - This is a client-specific id that may be used to mark or identify messages between - clients. The server ignores this field. - </doc> - </field> - - <field name="reply-to" domain="shortstr" label="destination to reply to"> - <doc> - The destination of any message that is sent in reply to this message. - </doc> - </field> - - <field name="content-type" domain="shortstr" label="MIME content type"> - <doc> - The RFC-2046 MIME type for the message content (such as "text/plain"). This is set by the - originating client. - </doc> - </field> - - <field name="content-encoding" domain="shortstr" label="MIME content encoding"> - <doc> - The encoding for character-based message content. This is set by the originating client. - Examples include UTF-8 and ISO-8859-16. - </doc> - </field> - - <field name="content-length" domain="longlong" label="length of content in bytes"> - <doc> - The length of the message content in bytes. - </doc> - </field> - - <field name="type" domain="shortstr" label="message type name"> - <doc> - The JMS message type. - </doc> - </field> - - <field name="user-id" domain="shortstr" label="creating user id"> - <doc> - The identity of the user responsible for producing the message. - </doc> - </field> - - <field name="app-id" domain="shortstr" label="creating application id"> - <doc> - The identity of the client application responsible for producing the message. - </doc> - </field> - - <field name="transaction-id" domain="shortstr" label="distributed transaction id"> - <doc> - An identifier that links this message to a distributed transaction. - </doc> - </field> - - <field name="security-token" domain="security-token" label="security token"> - <doc> - A security token used for authentication, replay prevention, and encrypted message bodies. - </doc> - </field> - - <field name="application-headers" domain="table" label="application specific headers table"> - <doc> - This is a collection of user-defined headers or properties which may be set by the - producing client and retrieved by the consuming client. Similar to JMS Properties. - </doc> - </field> - <!-- end headers --> - - <field name="body" domain="content" label="message body"> - <doc> - Message content. This should be considered opaque data. - </doc> - </field> - - </method> - - <!-- - the above is still the 0-9 definition and will shortly be - removed in favour of the following which is the real 0-10 - defintion: <method name="transfer" content="1" index="10" label="transfer a message"> <doc> @@ -6556,7 +6310,6 @@ <field name="confirm-mode" domain="confirm-mode" /> <field name="acquire-mode" domain="acquire-mode" /> </method> - --> <!-- - Method: message.reject - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> |