[Standards-JIG] lack of clarity implementing XEP-0077
stpeter at jabber.org
Wed Nov 15 19:28:44 UTC 2006
Matthias Wimmer wrote:
> Hi list!
> I am currently updating jabberd14's handling of the jabber:iq:register
> namespace, to fully comply with XEP-0077. But some things are unclear to
> me at present.
> - Acording to section 3.1 a registered and authenticated client that
> requests its registration data, or that wants to update registration
> data (e.g. the e-mail address of the user) does this by sending a iq-get
> request using no to attribute. (Which if I am correct is the same as
> sending it to his own JID, right?) This seems logical, as it is the same
> as with the initial registration of the account. But this is not what is
> really done on the current network.
> Current implementation of at least jabberd14 as a server or Exodus as a
> client is, that registration updates are sent to the server address.
> Has this been changed in XEP-0077 intentionally and all implementations
> should change the behaviour, or should this been considered a 'bug' in
> XEP-0077 which will be changed there?
I don't recall why the spec is that way, but I think it is best for it
to follow current usage.
> - Same for unregistering an account (section 3.2). All deployed software
> I know will try to unregister an user account by sending the iq-set
> query to the server address. But the examples in XEP-0077 send the iq
> query using no to address. (While the examples for the errors are sent
> back from the server's address, not from the user's.)
> - Changing the user's password (section 3.3) is sent to the server's
> address as the to attribute using an iq-set request. Is the included to
> attribute the difference between a password change request (which seem
> to only include the <username/> and <password/> fields) and a
> registration update request (which have to include all fields returned
> by an iq-get request, which are typically more than just <username/> and
I don't think a server could, would, or should key off the 'to'
attribute to decide it will handle the IQ -- the handling should be
driven by the content of the <query/> element, I think.
Feel free to send me a patch, or I'll get around to fixing the spec one
of these days... :-)
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards