To send a message that is received at most once to its destination, a normal message stanza is used, as defined by the XMPP protocol itself. The delivery of the message is not guaranteed. This QoS level should only be used of the loss of messages is not critical to the application.

Example: A sensor sending a stream of current values. If a value is lost might not matter much since the next message provides a new current value, overriding any lost value.

To send a message that is received at least once to its destination, an iq stanza of type set is sent containing an acknowledged element from the "urn:xmpp:qos" namespace. The acknowledged element in turn contains the message to be delivered. The iq stanza must have an id attribute that is used to identify if the stanza has been received or not. When an acknowledged message is received, an empty response is returned to acknowledge the receipt. Parsing the message is done after sending the response. If no response is received by the sending side within a given time frame, an number of retries should be made, using an interval or drop-off algorithm. These time frames and number of attempts are implementation specific.

It is not guaranteed that the message is delivered only once. Asynchronous conditions may arise where the message is delivered more than once. If an acknowledgement is not received, at least the sender may become aware that the message was not delivered. The At least once QoS level requires twice as many messages to be transported in the network as compared to the At most once QoS level.

Example: Any idempotent control action such as setting the light to a certain level. It is important that the control action is received, but not how many of them are received. Any identical control action that follows makes no difference in output or performance.

Note: The to and from attributes in the embedded message stanza are left empty.

To send a message that is received exactly once to its destination, an iq stanza of type set is sent containing an assured element from the "urn:xmpp:qos" namespace. The assured element in turn contains the message to be delivered. The iq stanza must have an id attribute that is used to identify if the stanza has been received or not, just as in the acknowledged case. But to keep track of the message begin sent, a msgId attribute has to be provided as well. When an assured message is received, a received response is returned to acknowledge the receipt. This received response echoes the msgId attribute as well. But the message is not parsed and delivered at this point, only temporarily stored on the receiving end. If multiple messages are received using the same msgId from the same sender, they are simply ignored, as one is already held in memory. Still, the received response is returned as normal.

When the sender receives the received response, it sends a new iq set stanza, this time with a deliver payload, to tell the receiving end to parse and deliver the message, if in memory, and remove it from memory. The receiver acknowledges the message by returning an empty iq result stanza. If receiving multiple requests using the same msgId, it will acknowledge each one. But only one message will be parsed and delivered, as it will have been removed from the temporary storage on the receiving end. For both the assured and deliver messages, a retry mechanism similar to the one used for acknowledged service is to be used.

The Exactly once QoS level requires twice as many messages to be transported in the network as compared to the At least once QoS level, and four times the number of messages as compared to the At most once QoS level.

Example: Any control action or counting operation that is not idempotent, such as sending a control action when a button is pressed, or whenever an event has occurred. If counting events, or accumulating consumption, it is vital that messages are not processed twice, since it will change the end result.

Note: The to and from attributes in the embedded message stanza are left empty.

When sending messages using unacknowledged service, i.e. using the normal message stanza, it can be subject to offline message storage if the recipient if offline. This might result in delivery of the message at a later time.

Message routing using unacknowledged service might be handled somewhat differently as compared to acknowledged and assured service, since the first uses the message stanza and the latter two the iq stanza, which require a fill JID in order to reach its destination. For consistency, full JIDs should be used also for unacknowledged messaging service, if possible.

If implementing support for this XEP, make sure implementation is generic and put on a lower level than other XEP-specific processing of incoming stanzas. Messages received using this server should be fed into the normal message processing and handling after the QoS level has been ascertained. This makes it possible to use QoS levels for any type of message being sent and received.

One decision each implementation of assured QoS has to make, is where to persist incoming messages between reception of message and the delivery to underlying message processing logic. Should they be persisted in internal memory, persistent Flash/EEProm, as local files or in a database? Such implementation specific concerns are left to the implementor, as this XEP only concerns itself with the communication layer between parties. But the choice of solution might affect to what level a message is ascertained to be delivered: Will delivery be guaranteed, even beyond a system reset at the receiving end? Or a system reset at the sending side? If delivery of the message has to be ascertained even if a system reset at the sending side is allowed, persistance of the request must also be made on the sending side. (To some extent, this latter concern even affects acknowledged service.)

Outstanding message IDs used in assured delivery, must be unique for the sender (counting the Full JID as the sender). If running short on Message IDs, such can be reclaimed after the receipt of a successful delivery of a previous message. Message IDs can be sequence numbers, or hash values of the contents of the message.

The to and from attributes of embedded message elements should be ignored and left out by the sender, except in the case of unacknowledged service, where the message element is the message stanza itself. In the case of acknowledged and assured quality of service levels, the message element MUST have its to and from attributes overwritten by the corresponding attributes of the iq stanza being used. This, to avoid the injection of messages with unauthenticated and unauthorized identities.

As incoming message using the assured quality of service level is temporarily stored on the receiving end, the receiver might become vulnerable to memory attacks if not implementing some basic counter measures:

1. Do not accept messages using assured service from untrusted sources, for instance from MUC rooms or senders not in the roster. If deemed untrusted, an iq error of type not-allowed should be returned instead of the received element expected in normal flow.

2. Set a limit on the number and size of assured messages that can be simultaneously received from a single source. If a source sends more than this, the resource-constraint error should be returned instead of accepting the message.

3. Set a total limit on the number and size of assured messages that can be simultaneously received from all sources. If anybody sends a message that will exceed this amount, the resource-constraint error should be returned instead of accepting the message.

Whenever invalid use of the assured messaging service is detected, wether it be from untrusted sources or spam, an event should be logged using &xep0337; so that the source of the error can be found and appropriate counter measures taken.