Therefore, the sender SHOULD NOT impute any meaning to the fact that it has not received an ack message, unless it has established with the recipient that receipt requests will be honored however, methods for doing so are out of scope for this specification and it is NOT RECOMMENDED to take any particular action (such as resending the content message) without such methods. The recipient simply does not wish to return a receipt for the content message.īecause of these significant limitations, this protocol does not provide complete or even partial reliability or guaranteed delivery.
DELIVERY RECEIPTS SOFTWARE
The recipient returns an ack message but the ack message is lost on the way back from the recipient to the sender (e.g., because of connectivity issues or software failures at any hop).The recipient's client receives the content message but experiences a malfunction before generating an ack message.The intended resource supports the Message Delivery Receipts protocol but the recipient's server delivers the content message to another resource that does not support the Message Delivery Receipts protocol.The recipient (or the particular intended resource to which the sender addressed the content message) does not in fact support the Message Delivery Receipts protocol.The sender has not bothered to determine whether the recipient supports the Message Delivery Receipts protocol.The sender addressed the content message to the recipient's bare JID and therefore does not know if the recipient even supports the Message Delivery Receipts protocol.Although the return of an ack message lets the sender know that the content message has been delivered to a client controlled by the intended recipient, there are many reasons why the sender might not receive an ack message immediately or at all, including but not limited to the following: This document defines a protocol that enables a sender to ask the recipient to acknowledge receipt of a content message by returning an ack message. The term "ack message" refers to the stanza by which the recipient acknowledges receipt of the content message at a client (i.e., delivery to a client). The term "content message" refers to the stanza for which the original sender would like to receive a receipt. Enable a recipient to provide message delivery receipts if desired.Enable a sender to request notification that an XMPP message stanza has been received (i.e., delivered to a client, but not necessarily read or understood by a human user, if any).This document addresses the following requirements: Therefore this extension is functionally equivalent to an Advanced Message Processing rule of "receipt", although it uses a dedicated namespace to simplify processing by clients and intermediate routers. delivered to a client, not that the message has been actively read or understood by a human user (if any). However, in the absence of such a distinction, readers need to understand that this protocol can provide only a notification that a message has been received at a client, i.e. Note well that this specification does not distinguish between delivery and display, as was done in the message events protocol, in part because no implementations of XEP-0022 made that distinction. This document defines a mechanism for XMPP message delivery receipts, which are functionally equivalent to the "delivered" or "displayed" event in Message Events (XEP-0022), which this specification in part obsoletes. However, sometimes client-level acknowledgements are needed, for example to provide "receipts". While Advanced Message Processing (XEP-0079) provides message acknowledgements at the server level, it does not extend that model all the way to the client.
0 kommentar(er)
