[Standards] stanza order and MUC
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  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
* 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...
More information about the Standards