On Sep 29, 2010, at 15:07 , bschumac wrote: > On 9/29/10 1:02 PM, Justin Karneges wrote: >> >> In other words, the XEP is saying to send like this: >> >> <presence to="user" from="room/existing_occupant1"/> >> <presence to="user" from="room/existing_occupant2"/> >> <presence to="user" from="room/new_occupant"/> >> >> However, any XMPP server (whether the one the MUC component is connected to, >> or the user's, which may be over s2s) may route these stanzas in any order, >> because the from JIDs are all different. It would be perfectly legal for the >> user's server to relay the stanzas to the user in this order: >> >> <presence to="user" from="room/existing_occupant2"/> >> <presence to="user" from="room/new_occupant"/> >> <presence to="user" from="room/existing_occupant1"/> >> >> I see this issue becoming greater as XMPP servers become more optimized, >> threaded, clustered, etc. Maintaining delivery order comes at a cost, and >> you >> can be sure implementors will avoid that cost where allowed (indeed, this >> thread was prompted after discussions I had with Artur of Tigase and his >> desire to bend delivery rules for speed sake). > > 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>. In > this regard MUC behaves exactly as expected and XEP-0045 wording leaves this > out as this has been the historical expectation from reference > implementations of XMPP. > > Cheers, > Ben > > [1] http://bit.ly/byx9Br > >
I wonder if this is something we should address now in 3920bis, or just let sleeping dogs lie... - m&m
