The operations described in the XEP can be divided into two
categories.
1. From an unauthenticated user (request registration form, register)
Theses involve sending IQs to the host. What isn't specified is
what the host is when the stanza is missing a 'to' attribute (as
most of the examples are).
The obvious host would be the one specified in the stream tag's
'to' attribute. If both 'to' attributes are missing, a stanza error
should be sent. This needs to be specified in the XEP.
2. From an authenticated user (cancel account, change password)
For account cancellation, this involves sending IQs with a missing
'to' attribute:
"If the entity cancels its registration with its "home" server
(i.e., the server at which it has maintained its XMPP account),
then the entity SHOULD NOT include a 'from' or 'to' address in
the remove request the server SHOULD then return a
<not-authorized/> stream error and terminate all active sessions
for the entity."
(also, grammar fail in the quoted text)
A missing 'to' attribute implies the stanzas are being sent to the
user's account (user's bare JID). The IQ responses in the XEP
examples however are coming from the host, not the account
(from='shakespeare.lit'). This needs to be fixed.
For password change, the XEP examples do include a 'to' attribute
for the local host (to='shakespeare.lit'), while the server's
response is missing a 'from' attribute in some examples, and not in
others. This adds to the inconsistency.
The examples throughout the XEP need to be made consistent. The
client behavior for account cancellation (SHOULD NOT inclde 'from'
or 'to' attributes) should apply to password change as well. And it
should be clarified that the server should in fact handle
jabber:iq:register stanzas to both the user's bare JID, and to the
host itself.
--
Waqas Hussain
