[Council] VOTE: JEP-0077 (In-Band Registration)
stpeter at jabber.org
Wed Jul 21 18:21:46 CDT 2004
On Tue, Jul 20, 2004 at 01:11:20PM -0500, Thomas Muldowney wrote:
> On Jul 14, 2004, at 11:07 PM, Peter Saint-Andre wrote:
> >JEP-0077 (In-Band Registration) has been updated to incorporate all
> >feedback received during the Call for Experience. Therefore it seems
> >appropriate for the Jabber Council to vote on whether to advance this
> >Standards Track JEP from Draft to Final.
> >Abstract: This JEP defines a protocol for in-band registration with
> >Jabber servers and services using the 'jabber:iq:register' namespace.
> >URL: http://www.jabber.org/jeps/jep-0077.html
> >Please vote +1, 0, or -1 (with requested changes).
> >Peter Saint-Andre
> >Jabber Software Foundation
> Few comments before I feel comfortable voting.
> Section 4.1 is not clear about the connection state. In some cases
> this will happen before authentication, in that case you can not use
> <registered/> or <remove/>, I think that needs to be more explicit.
In my working copy, I have modified the relevant paragraph in Section
4.1 as follows:
If the host determines (based on the 'from' address) that the entity
is already registered, the IQ result that it sends in response to the
IQ get MUST contain an empty <registered/> element (indicating that
the entity is already registered), SHOULD contain the registration
information currently on file for the entity (although the
<password/> element MAY be empty), and SHOULD contain an
<instructions/> element (whose XML character data MAY be modified to
reflect the fact that the entity is currently registered). If the
host is a server and the IQ get does not contain a 'from' address
because the entity has not yet created an account on the server,
naturally the host will be unable to determine the identity of the
requesting entity and therefore MUST assume that the entity is
I have also added an error condition to Section 4.2 as follows:
<unexpected-request/> -- The host is a server and the IQ get does not
contain a 'from' address because the entity is not registered with
> Section 5 - I was wondering if we should have some wording about not
> mixing x:data with the predefined fields. I think this would lead to
> horrid ambiguity and too many OPTIONAL pieces in one area. Which do
> you fill out?
I have added the following paragraph to Section 5:
If the entity supports the Data Forms protocol, it SHOULD submit the
data form rather than the predefined 'jabber:iq:register' fields, and
MUST NOT submit both the data form and the predefined fields.
> Section 6 - If my thoughts to Section 5 are agreeable then Section 6
> would probably need to be more tied to Section 5, the original idea
> with x:data was that you would have the in-band info, and then a
> website to go to if that was unusable.
It seems to me that there are two possible scenarios:
1. Pure Redirection -- The instructions point you to some other medium
(e.g., a website) for registration, although the result would probably
also include an OOB element pointing you to a URL where you can register.
However, the OOB is not required -- it's possible that the instructions
could say "Call the BOFH at 800-555-5222."
2. Data Forms or Bust -- The IQ result includes a data form but none of
the predefined fields, plus an OOB element pointing you to a website if
you don't support JEP-0004.
Either one is legitimate IMHO.
Jabber Software Foundation
More information about the Council