On 30/03/10 18:14, Peter Saint-Andre wrote:
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.
I guess it's debatable whether this really /is/ a bug. Following the
same semantics as iq and presence, if the message type isn't
type="error" then nothing at the core level makes it a reply (and hence
id-preserving). XEP-0184 is the only one suggesting it should have the
same id, and this feels odd, I agree with Remko on that.
Matthew
