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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
