mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-25 09:08:52 -05:00
1.1rc2
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3997 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
parent
b397379195
commit
248813ec27
17
xep-0184.xml
17
xep-0184.xml
@ -29,10 +29,10 @@
|
||||
&stpeter;
|
||||
&hildjj;
|
||||
<revision>
|
||||
<version>1.1rc1</version>
|
||||
<date>in progress, last updated 2010-02-24</date>
|
||||
<version>1.1rc2</version>
|
||||
<date>in progress, last updated 2010-02-26</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Relaxed the business rules to allow inclusion of receipt requests even to the bare JID and even if the sender does not yet know if the intended recipient supports this protocol.</p></remark>
|
||||
<remark><p>Relaxed the business rules to allow inclusion of receipt requests even to the bare JID and even if the sender does not yet know whether the intended recipient supports this protocol; clarified the level of reliability that this protocol does and does not provide.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.0</version>
|
||||
@ -87,7 +87,16 @@
|
||||
<li>Enable a sender to request notification that an XMPP message stanza has been received.</li>
|
||||
<li>Enable a recipient to provide message receipts if desired.</li>
|
||||
</ol>
|
||||
<p>Note: This document explicitly does not define a protocol for "guaranteed delivery", since that term (like "security") means different things to different people. Instead, we define a more focused protocol that addresses the need for message receipts, thus solving one problem that falls under the heading of "guaranteed delivery".</p>
|
||||
</section1>
|
||||
<section1 topic='Reliability' anchor='reliability'>
|
||||
<p>This document defines a protocol that enables a sender to ask the recipient to return a receipt for a message. Although the return of a message receipt lets the sender know that the message has been delivered, there are many reasons why the sender might not receive a receipt immediately or at all, including but not limited to the following:</p>
|
||||
<ul>
|
||||
<li>The recipient (or the particular intended resource to which the sender addressed the message) does not in fact support message receipts.</li>
|
||||
<li>The intended resource supports message receipts but the recipient's server delivers the message to another resource that does not support message receipts.</li>
|
||||
<li>The recipient's client receives the message but experiences a malfunction before generating a receipt.</li>
|
||||
<li>The recipient returns a receipt but the receipt is lost on the way back from the recipient to the sender (e.g., because of connectivity issues or software failures at any hop).</li>
|
||||
</ul>
|
||||
<p>Therefore this document does not define a protocol for complete reliability or guaranteed delivery, and those who implement and deploy this protocol need to be aware of its limitations.</p>
|
||||
</section1>
|
||||
<section1 topic='Protocol Format' anchor='format'>
|
||||
<p>In order to make it possible for senders to request and for recipients to generate message receipts, we define a dedicated protocol extension qualified by the 'urn:xmpp:receipts' namespace.</p>
|
||||
|
Loading…
Reference in New Issue
Block a user