[Standards] stanza order and MUC

bschumac bschumac at cisco.com
Wed Sep 29 23:12:59 UTC 2010

  On 9/29/10 3:56 PM, Artur Hefczyc wrote:
> On Sep 29, 2010, at 10:07 PM, bschumac wrote:
>> I believe the RFC is ambiguous in this regard and the XEP depends on an understood reading of the RFC that perhaps isn't spelled out well enough. Section 10.1 of RFC3921bis [1] simply states:
>> An XMPP server MUST ensure in-order processing of XML stanzas between any two entities. This includes stanzas sent by a client to its server for direct processing by the server (e.g., in-order processing of a roster get and initial presence as described in [XMPP‑IM]).
>> In my opinion the expected behavior in this regard has always been between two Bare JIDs -- from:<localpart at domainpart>  to:<localpart at domainpart>.
> I am afraid, in most cases there is no such thing like "between two bare JIDs".
> If two users talk to each other and each of these users have two connections (resources)
> then what in this context mean "between two Bare JIDs".
> Please note also the RFC says "between any two entities". Even though it does not specific whether
> this is between the entity sending the packet and receiving the packet or between the entity
> in 'from' address and 'to' address which is not always the same thing.
> I assume the RFC means between entities specified in 'from' and 'to' address.

Allow me to clarify that. My point is that the 'resourcepart' is 
inconsequential when providing this "guarantee". This, I believe, is the 
goal for "in-order delivery" even if it's not clear from the 
specification. This follows the guide of the reference implementation 
(jabberd1.4) which, in this case, the specification was clearly based 
on. The server should endeavor to deliver messages in the order it 
received them from all clients to the whatever peer in the communication 
is -- conferencing server just happens to be another peer.

For the purposes of this topic, if I was in <jdev at conf.j.org> and 
<standards at conf.j.org> and sent a message the the former and then the 
latter, it wouldn't matter if the server processed the message to 
<standards at conf.j.org> first because it has no impact on the context of 
the conversation I'm having with <jdev at conf.j.org>. In particular it is 
important to honor this behavior when considering the traditional 
"resource locking" behavior of clients -- it would be incorrect if this 
exchange was to happen between two clients:

    Users A at S/C and B at S/C are both online and both users begin a
    conversation with each other at the same time. The server receives
    messages in this order:

       1. A at S/C sends "Yo" to B at S (Bare JID)
       2. B at S/C sends "How's it going?" to A at S
       3. A at S/C sends second "Terrible." to B at S/C (Full JID -- resource

    However server provides incorrect guarantee that only ensures
    in-order between "fullest-possible" JID, the messages end up
    delivered out-of-order:

        * B at S/C receives "Terrible."
        * B at S/C receives "Yo."
        * A at S/C receives "How's it going?"

The specification is clearly ambiguous about this, given that it only 
refers to an "entity" but doesn't define what an entity is. My assertion 
is that the intention is that an "entity" in this context can be 
represented by a JID and the only significant parts of that JID are 
"localpart" and "domainpart".

I hope this makes more sense.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100929/4df36f95/attachment.html>

More information about the Standards mailing list