On Sun, Aug 7, 2011 at 1:31 PM, Kevin Smith <ke...@kismith.co.uk> wrote: >> Anecdotal evidence from different service implementations seems to >> support my expectation that they are sent from the JID the original >> presence was sent to. That'd mean that either the spec is wrong or all >> implementations are. > > 100% of the servers that I tested this against (sample size: 1) are > sending the join error from the room JID as per the spec, so it's > certainly not the case that all implementations aren't compliant. > > The examples seem to be logically correct to me - > jab...@conference.jabber.org/Kev (i.e. me) is not sending you an > error, jab...@conference.jabber.org is.
I disagree. Arguments follow. As an example take the <conflict/> error. If you try to acquire a nick which is already taken, you get a conflict error. You may or may not have an existing nick (initial join vs. nick change). Now, this does weird things to directed presence book-keeping on the user's server. The interaction between directed presence and error presence and bare and full JIDs is a gray area (something I'd like clarified in 6120bis). If there is no interaction, then that needs to be fixed IMHO (possible unavailable presence leak). If there is, then bare JID response for both initial join and nick change is going to cause issues. This also causes issues with ID mapping. I think it's reasonable for a client to listen for the exact (ID,JID) pair it sent to. In fact, a library shall do it for the client, and it shouldn't be forced to special case for just MUC errors :) XMPP errors always come from the JID the stanza was sent to, not from the entity which actually generated the error. An obvious example is remote-server-not-found. Another example is from the MUC XEP itself: <item-not-found/> errors from a room which doesn't actually exist. Are you suggesting that should that be coming from the MUC service? :) In Prosody, we have a specific pattern for sending an error reply. e.g.: reply = st.error_reply(stanza, "cancel", "conflict"). This constructs a new stanza with to and from swapped. Looking at ejabberd's MUC code, they seem to have something just like that. XMPP is so consistent in this that we have pretty much no manual error stanza construction other than that function. -- Waqas Hussain
