[Standards] XEP-0184 1.1rc7

Peter Saint-Andre stpeter at stpeter.im
Tue Mar 30 17:14:27 UTC 2010

On 3/30/10 8:20 AM, Ralph Meijer wrote:
> On Tue, 2010-03-30 at 15:40 +0200, Remko Tronçon wrote:
>>> As each message is in a stream with a particular direction
>> Well, not really. Clients usually generate IDs based on some simple
>> algorithm, and don't take into account IDs from incoming messages. For
>> example, 2 clients with a simple incrementing counter would give this:
>> C1->C2: (id=1) <body>hi there</body>
>> C2->C1: (id=1) <body>hello</body><request-receipt/>
>> C1->C2: (id=1) <request-received/>
>> C1 sent two normal messages with id=1: the first one generated from
>> the auto-incrementing number algorithm, the second one mirroring the
>> message from the incoming message.
> What you're saying could cause similar issues with normal iq's as well,
> with the exception that error stanzas cannot result in error replies.
> As I said before, I don't think stuff is breaking on this or will in the
> future. Clients typically don't track messages on their IDs. Also,
> client disconnects cause messages to go to other resources, etc, so it
> is very easy to end up in a situation where the unicity of the ids is
> broken in general.

So what's the consensus? Does something need to be fixed further in
XEP-0184? IMHO the replying entity can echo the original 'id' and all is
well. If it doesn't do that, it's got a bug in its handling of message
receipts -- i.e., software that supports sending of receipts MUST also
handle 'id' attributes correctly. If it doesn't, file a bug report.


Peter Saint-Andre

-------------- 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/20100330/912b2662/attachment.bin>

More information about the Standards mailing list