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

Peter Saint-Andre stpeter at jabber.org
Tue Jul 27 11:25:17 CDT 2004


I'm going to publish a new version of the JEP so that those who have
voted -1 can review it.

Peter

On Wed, Jul 21, 2004 at 06:21:46PM -0500, Peter Saint-Andre wrote:
> 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
> 
> _______________________________________________
> Council mailing list
> Council at jabber.org
> https://jabberstudio.org/mailman/listinfo/council
> 

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



More information about the Council mailing list