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
