On Wednesday 29 September 2010 16:12:59 bschumac wrote: > On 9/29/10 3:56 PM, Artur Hefczyc wrote: > > 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". > > 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 <j...@conf.j.org> and > <standa...@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 > <standa...@conf.j.org> first because it has no impact on the context of > the conversation I'm having with <j...@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...@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?"
Hmm, yes, if I sent two messages in a row, the first to a bare JID and then the next to the same JID but with a resource, then I would expect these messages to remain in order if they are both delivered to the same endpoint. Unfortunately only the destination server knows for sure if they are the same endpoint. This is very similar to the MUC problem. > The specification is clearly ambiguous about this, given that it only > refers to an "entity" but doesn't define what an entity is. Right. Ordering is important enough that I think this issue deserves more than one sentence in the RFC. It seems our choices are: 1) "Entity" is a Full JID. Resource locking (RFC 3921) and MUC (XEP-0045) need repairs, or we just live with their problems and try not to repeat them. 2) "Entity" is a Bare JID. Everything works as Jeremy Himself intended. Can developers of various servers describe their current ordering policies? It would be interesting to see just how the spec has been interpretted so far. -Justin
