You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by gs...@apache.org on 2007/08/28 21:38:23 UTC
svn commit: r570538 [4/4] - in /incubator/qpid/trunk/qpid:
cpp/rubygen/templates/ cpp/src/ cpp/src/qpid/broker/ cpp/src/qpid/client/
cpp/src/qpid/cluster/ cpp/src/qpid/framing/ cpp/src/tests/ python/
python/qpid/ python/tests_0-10/ specs/
Modified: incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml
URL: http://svn.apache.org/viewvc/incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml?rev=570538&r1=570537&r2=570538&view=diff
==============================================================================
--- incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml (original)
+++ incubator/qpid/trunk/qpid/specs/amqp-transitional.0-10.xml Tue Aug 28 12:38:17 2007
@@ -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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->