[Standards] XEP-0184: some minor remarks

Peter Saint-Andre 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 [9]), only when first receiving the message.


Peter Saint-Andre

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

More information about the Standards mailing list