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:<localp...@domainpart> to:<localp...@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 <[email protected]> and
<[email protected]> and sent a message the the former and then the
latter, it wouldn't matter if the server processed the message to
<[email protected]> first because it has no impact on the context of
the conversation I'm having with <[email protected]>. 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...@s/C and b...@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...@s/C sends "Yo" to b...@s (Bare JID)
2. b...@s/C sends "How's it going?" to a...@s
3. a...@s/C sends second "Terrible." to b...@s/C (Full JID -- resource
locked)
However server provides incorrect guarantee that only ensures
in-order between "fullest-possible" JID, the messages end up
delivered out-of-order:
* b...@s/C receives "Terrible."
* b...@s/C receives "Yo."
* a...@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.
Cheers,
Ben
