[Standards] Use of to/from attributes in XEP-0077: In-Band Registration inconsistent and underspecified

Waqas Hussain waqas20 at gmail.com
Wed Jun 16 20:02:39 UTC 2010

The operations described in the XEP can be divided into two

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

More information about the Standards mailing list