[Standards] XEP-0184 business rules for message receipts

Peter Saint-Andre stpeter at stpeter.im
Sat Mar 13 20:39:05 UTC 2010


On 3/13/10 11:04 AM, Kevin Smith wrote:
> On Sat, Mar 13, 2010 at 4:47 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> On 3/12/10 4:29 PM, Kevin Smith wrote:
>>> Some tweaks, as I think the "Don't use lack of a receipt to mean you
>>> should resend" applies across the board (indeed, your earlier summary
>>> had this explicitly, but the proposed text doesn't).
>> Hmm. If the sender (1) has verified that the recipient (full JID)
>> supports receipts and (2) requests a receipt, then the lack of a receipt
>> within some configurable timeout might indicate that the message was
>> lost along the way, thus legitimately leading the sender to resend.
>> Isn't that part of the point here? Why request receipts if you're never
>> going to behave any differently whether or not you receive a receipt?
> 
> Well, that's the point I've always made, pretty much. 

Except that version 1.0 of XEP-0184 says the following:

***

7. Implementation Notes

Although a sender MAY attempt to resend a message if it knows that the
recipient supports message receipts and it does not receive a reply
within some configurable timeout period, resend logic is out of scope
for this specification.

***

It seems you are proposing to remove that paragraph or anything like it.
I agree that the current text punts on retry logic. I propose that we
specify it more carefully, not pull it out altogether.

> XEP-0184
> provides something akin to email read receipts - email clients don't
> go resending emails if they haven't received a receipt by the next
> day, because the user may just not have fired up their email client
> yet, or they could be one of the people who doesn't send read receipts
> (there're a number of them about). 

Email clients don't have disco and caps for online resources.

> What my email client is able to do
> is to show some notification that "Peter has confirmed he's read this
> message" when I send you a message with a request in it, and that's
> exactly what a XEP-0184 client is able to do, 184 serves this purpose
> very well, but if you happen to go offline, or don't check your
> messages at the weekend, or (goodness!) take a holiday I'm firmly off
> the belief that my client shouldn't be spamming you with the message
> more than once.

Edge case. So we modify the text to read:

***

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 ___and if it does not in the meantime receive an
unavailable presence notification from the full JID to which it sent the
message___.

***

The stuff about "configurable timeout period" is a bit of a dodge, too,
but we might be able to live with that.

> Now, with that said, if end to end delivery receipts for the sake of
> delivery confirmation is a requirement here, I think the XEP can be
> made to work - I think what we'd need to do is (only for full-jid to
> full-jid sessions) negotiate an agreement that both clients will be
> sending a receipt for every message, and if it's not received within X
> long to retransmit it. This doesn't have any of the issues I mentioned
> before of unwanted retransmissions, because it's all consensual, and
> was defined in version 1.0 of the spec.

I don't think that a negotiation protocol (XEP-0155 or XEP-0020 or a new
Jingle "chat session" application type) is needed here, just a set of
good rules for resending.

>>> On Fri, Mar 12, 2010 at 11:02 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>> On 3/12/10 7:55 AM, Peter Saint-Andre wrote:
>>>>> On 3/12/10 6:24 AM, Kevin Smith wrote:
>>>>>> On Fri, Mar 12, 2010 at 1:20 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>>>>> You're right that there are two instances of ignorance: (1) blindly
>>>>>>> sending to the bare JID (2) sending to the full JID without first
>>>>>>> performing disco#info or receiving caps data. I think we wan to say that
>>>>>>> #1 is OK but you're on your own, and #2 is discouraged because you have
>>>>>>> disco/caps at your disposal. There is a third case of (3) the disco/caps
>>>>>>> data shows that the intended recipient's full JID does *not* support
>>>>>>> receipts; in this case I think we want to say that you SHOULD NOT
>>>>>>> request receipts. And, in all of these cases, you MUST NOT take the lack
>>>>>>> of a receipt as a trigger for resending the message.
>>>>>>
>>>>>> That's exactly what I meant, thanks.
>>>>>
>>>>> Super. I'll try to find some time today to clean up the spec.
>>>>
>>>> Here is my proposed text, which is contained in a completely new section:
>>>>
>>>> ***
>>>>
>>>> 5. When to Request Receipts
>>>>
>>>> A sender could request receipts on any non-error message (chat,
>>>> groupchat, headline, or normal) no matter if the recipient's address is
>>>> a bare JID <localpart at domain.tld> or a full JID
>>>> <localpart at domain.tld/resource>. Whether it is appropriate or advisable
>>>> to do so it another question. This section provides recommendations
>>>> about when and when not to request receipts, and what results to expect
>>>> in each scenario.
>>>>
>>>> 5.1 Bare JID
>>>>
>>>> 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.
>>>>
>>>> 5.2 Full JID
>>>>
>>>> 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
>>>
>>> "MAY request a receipt", I think.
>>
>> I was thinking about this some more and I don't know if any conformance
>> language is needed here ("might" or "could" or "can if desired" is
>> probably fine instead of "MAY" or "SHOULD"). It's up to the sender
>> whether it wants receipts and not really a matter for the spec. However,
>> I'd be fine with MAY here. I do think it's worthwhile to differentiate
>> between the bare JID case and the full JID + discovery case.
> 
> I'm happy not to use conformance language for this, although I equally
> don't see much reason not to use MAY (it is "Truly optional").

Sure.

>>> It's entirely legitimate for a
>>> client to support -184, and to never request a receipt, only supply
>>> them.
>> Good point.
>>
>>>> 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
>>>
>>> "MUST NOT resend the message"
>>>
>>>> if it does not receive a receipt.
>>
>> See above. I think "MUST NOT" is not right and was never the intent of
>> this spec.
> 
> See above :) (snap).

See above. ;-)

> I note that the 1.0 text is explicit that <received/> is only sent if
> the receiver wishes to inform the sending entity that the message has
> been received, and this hasn't been removed from 1.1rc3. I think it's
> harmful to say to receivers "Yeah, you don't need to generate the
> receipt if you don't want to", while telling the sender "It's fine to
> keep sending until you get a receipt".
> 
>>>> within some configurable
>>>> timeout period (however, resend logic is out of scope for this
>>>> specification).
>>> Then that bit can be scratched.
>> I disagree.
> 
> I know, I'm hoping to change your mind.

And I'm hoping that you change yours. :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.
>>>>
>>>> 5.3 Groupchat
>>>>
>>>> It is NOT RECOMMENDED to request a receipt when sending a message of
>>>> type "groupchat" in a Multi-User Chat [6] 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.
>>>>
>>>> ***
>>>>
>>>>
>>>
>>> Otherwise good, thanks.
>> We're getting there. :)
> 
> I think so.

Asymptotically approaching perfection, no doubt.

Perhaps you and I need to talk about this using a technology that
enables near-real-time communication. If only someone had invented such
a thing...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100313/65606499/attachment.bin>


More information about the Standards mailing list