[Standards] XEP-0184 business rules for message receipts

Peter Saint-Andre stpeter at stpeter.im
Fri Mar 12 03:32:51 UTC 2010


On 3/11/10 1:52 PM, Kevin Smith wrote:
> TL;DR version:
> 1) I don't like sending to the bare JID, but I'll live with it if
> someone talks me down.
> 2) We must be explicit about not sending to entities that don't support it.

These two are connected, because if x at foo sends to y at bar instead of to
y at bar/1 then there's no way for x to know if y supports receipts. It
appears that in some applications this is considered good enough.
Perhaps they are closed systems using specialized software. Who are we
to say that in such deployments the sender MUST NOT request receipts?

> Full version:
> 
> On Thu, Mar 11, 2010 at 9:11 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
>> On Thu, Mar 11, 2010 at 4:06 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> Thanks, Tuomas. Kevin Smith said he had some feedback about this
>>> proposed text, so we're waiting for him to post to the list before the
>>> Council approves version 1.1 of XEP-0184.
>> Which I will do soon, hopefully today.
> 
> Ok, so...
> I think
> "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." can be more
> explicit and say what this really means, something like " As such it
> is NOT RECOMMENDED that a client uses the lack of a delivered receipt
> as an indication that a message has not been received, or should be
> retransmitted".

Erk, too many nots. :)

How about:

"A sender cannot know whether a recipient supports this protocol if the
sender knows (or addresses messages to) only the recipient's bare JID.
In this case the sender MUST NOT consider the lack of a receipt as an
indication that the message needs to be retransmitted."

> "If receipts are desired, a sender SHOULD include a request for
> message receipts on all messages, no matter whether sending to the
> bare JID <localpart at domain.tld> of the recipient or the full JID
> <localpart at domain.tld/resource>."
> 
> I've got two issues with this bit. The first is that I don't think
> message receipts should be sent without knowing that the recipient
> supports them I can be argued down on this, but I don't think blindly
> spraying them gains us much. The second issue is that the above text
> means you SHOULD send a request even when you know the recipient's
> full JID's client doesn't support them. "While message receipts are
> sent to the bare JID not knowing if the receiver will support this
> extension, they should not be sent to a full JID when it is known that
> the receiver does not support them." will sort the second issue.

Agreed. That's much superior.

> "If a sender wishes to request message receipts, it SHOULD first
> determine whether the intended recipient supports message receipts.
> This can be done directly via Service Discovery or indirectly via
> Entity Capabilities." was removed, but I think should be reinstated
> with something like
> "If a sender wishes to request message receipts, it SHOULD first
> determine whether the intended recipient supports message receipts.
> This can be done directly via Service Discovery or indirectly via
> Entity Capabilities. When sending to a bare JID, it will not be
> possible to determine if the recipient supports message receipts."

Yes. See also above.

> "A sender MAY include a request for message receipts even if it has
> not been able to determine if the intended recipient supports message
> receipts. This can be done directly via Service Discovery or
> indirectly via Entity Capabilities." +  "but MUST NOT include a
> request where it has been able to determine that the intended
> recipient does not support message receipts" or such would solve a lot
> of my above issues.

Indeed. I'll reworking the text along the lines you propose and post again.

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/20100311/7da7c3c1/attachment.bin>


More information about the Standards mailing list