[Standards] XEP-0184 business rules for message receipts
kevin at kismith.co.uk
Sat Mar 13 18:04:43 UTC 2010
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. 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). 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.
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.
>> 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").
>> It's entirely legitimate for a
>> client to support -184, and to never request a receipt, only supply
> 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
>> "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).
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
>> Then that bit can be scratched.
> I disagree.
I know, I'm hoping to change your mind.
>>> 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  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.
More information about the Standards