[Council] VOTE: JEP-0077 (In-Band Registration)

Peter Saint-Andre 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).
> >
> >Thanks.
> >
> >Peter
> >
> >-- 
> >Peter Saint-Andre
> >Jabber Software Foundation
> >http://www.jabber.org/people/stpeter.php
> >
> 
> 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
   unregistered.

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
   the server.

> 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.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php



More information about the Council mailing list