Resurrecting a very old thread... On 6/22/10 2:56 PM, Steven te Brinke wrote: > When I read XEP-0184, I thought about a few situations which are not > explicitly addressed in the XEP, so I did draw my own conclusions. It might > be > desired to add (some of) these to the XEP explicitly. I leave that for > someone > else to decide. I just list them here so anyone can think about them: > 1. It is not strange to receive multiple receipts for a single message, > because a user might have his messages delivered to all clients instead of a > single one (depending on which kinds of delivery the server supports).
In my working copy I've added this sentence: Because it is possible for a given content message to be delivered to multiple XMPP resources controlled by the recipient, the sender of the content message needs to be prepared to receive multiple ack messages. > 2. Regarding the recommendations when not to request receipts, I would say it > is not recommended to request a receipt for any message carrying a receipt. > (This can become problematic if not designed carefully.) Agreed. I've added the following text: To prevent looping, an entity MUST NOT include a receipt request (i.e., the <request/> element) in an ack message (i.e., a message stanza that includes the <received/> element). > 3. Is there any recommendation regarding message archiving? If the receipt > request is in the archive, a receipt might be send every time the user > browses > the archive. If a receipt request is removed before archiving, it is possible > that a receipt is never send (e.g. in an IMAP like system, messages are > archived by the server to be received by a client from the archive). I've added this text: An entity MUST NOT send an ack message when a user views messages that have been archived or stored on the client or the server (e.g., via Message Archiving [9]), only when first receiving the message. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
