[Standards] XEP-0184: some minor remarks
stpeter at stpeter.im
Thu Feb 17 05:05:45 UTC 2011
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
> 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 ), only when first receiving the message.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards