moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

1.1rc4: a few text tweaks

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4076 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-03-13 05:03:26 +00:00
parent b22183cdba
commit d973a48c08
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
xep-0184.xml
View File

@ -29,7 +29,7 @@
&stpeter;
&hildjj;
<revision>
<version>1.1rc3</version>
<version>1.1rc4</version>
<date>in progress, last updated 2010-03-12</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 whether the intended recipient supports this protocol; clarified the level of reliability that this protocol does and does not provide; provided explicit recommendations about when and when not to request receipts; removed text about XEP-0155 negotiation.</p></remark>
@ -134,7 +134,9 @@
<p>If the sender knows only the recipient's bare JID, it cannot cannot determine (via disco or caps) whether the intended recipient supports message receipts. In this case, the sender MAY request a receipt when sending a message of type "chat", "headline", or "normal" to the recipient's bare JID. However, the sender MUST NOT depend on receiving a receipt and MUST NOT resend the message if it does not receive a receipt.</p>
</section2>
<section2 topic='Full JID' anchor='when-full'>
<p>If the sender knows a full JID for the recipient (e.g., via presence), it SHOULD attempt to determine (via disco or caps) whether the client at that full JID supports message receipts before attempting to request receipts. In this case, if the sender determines that the recipient's client supports message receipts then it SHOULD request a receipt when sending a message of type "chat", "headline", or "normal" to that full JID. The sender MAY depend on receiving a receipt and MAY resend the message if it does not receive a receipt within some configurable timeout period (however, resend logic is out of scope for this specification). If the sender determines that the recipient's client does not support message receipts then it SHOULD NOT request a receipt when sending a message to that full JID and MUST NOT resend the message if it does not receive a receipt.</p>
<p>If the sender knows a full JID for the recipient (e.g., via presence), it SHOULD attempt to determine (via disco or caps) whether the client at that full JID supports message receipts before attempting to request receipts.</p>
<p>If the sender determines that the recipient's client supports message receipts then it MAY request a receipt when sending a message of type "chat", "headline", or "normal" to that full JID. If the sender has requested a receipt, it MAY depend on receiving a receipt and MAY resend the message if it does not receive a receipt within some configurable timeout period (however, resend logic is out of scope for this specification).</p>
<p>If the sender determines that the recipient's client does not support message receipts then it SHOULD NOT request a receipt when sending a message to that full JID and MUST NOT resend the message if it does not receive a receipt.</p>
</section2>
<section2 topic='Groupchat' anchor='when-groupchat'>
<p>It is NOT RECOMMENDED to request a receipt when sending a message of type "groupchat" in a &xep0045; room because the logic for determining when a message is truly "received" by all of the room occupants is complex and because the sender would receive one receipt from each occupant of the room, thus significantly increasing the number of messages sent through the room.</p>