[Standards-JIG] lack of clarity implementing XEP-0077

Matthias Wimmer m at tthias.eu
Wed Nov 15 01:32:37 UTC 2006


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?

- 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
<password/>)?


A bit confused ...
   Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/



More information about the Standards mailing list