[Standards] XEP-0184 1.1rc7

Matthew Wild mwild1 at gmail.com
Tue Mar 30 16:59:56 UTC 2010


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



More information about the Standards mailing list