From d973a48c087efabb2a34d0e3c3bd2ff94b287185 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Sat, 13 Mar 2010 05:03:26 +0000 Subject: [PATCH] 1.1rc4: a few text tweaks git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4076 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0184.xml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xep-0184.xml b/xep-0184.xml index 3203f49b..31d0cbef 100644 --- a/xep-0184.xml +++ b/xep-0184.xml @@ -29,7 +29,7 @@ &stpeter; &hildjj; - 1.1rc3 + 1.1rc4 in progress, last updated 2010-03-12 psa

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.

@@ -134,7 +134,9 @@

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.

-

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.

+

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.

+

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).

+

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.

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.