[PATCH] compliance with section 9.2.3 of RFC 3920 (IQ Semantics)

[Martin Atkins]

Pedro Melo wrote:
> Hi,
> 
> See http://rfc.net/rfc3920.html#s9. for reference, search for 9.2.3.
> 
> Basically, to match an IQ with a semantic meaning, we must look at the 
> namespace and not at the tag the first child is using. The relevant text 
> of the RFC:
>   "The data content of the request and response is defined by the namespace
>    declaration of a direct child element of the IQ element"
> 
> That means for example, that as long as I use xmlns='vcard-temp' in the 
> first child, the tag name can be vCard, query, or even 
> sometagnobodyneedstoknow.
> 
> The attached patch fixes the signature method of the IQ class, and 
> changes all the occurences of a set/get-{ns}tag I could find.
> 

Hmm.

While I agree with you that the XMPP RFC section you referenced gives 
the impression that the element's local name is to be disregarded, I'm 
not convinced that this was the intention.

Certainly most of the XEPs I've read have specified a local name along 
with a namespace. For example, in the introduction to the vcard-temp 
spec (XEP-0054):

"This is done by by sending an <iq/> of type "set" (storage) or "get" 
(retrieval) to one's Jabber server containing a <vCard/> child scoped by 
the 'vcard-temp' namespace"

I don't really see the value in ignoring the local name entirely. Are 
there existing implementations that rely on this? Are you sure that 
there *aren't* existing iq-based extension protocols that rely on 
distinctions between iq element names in the same namespace?