[Council] JEP-0077?

Peter Saint-Andre stpeter at gmail.com
Mon Aug 23 14:47:00 CDT 2004


Version 1.6 has been released:

http://www.jabber.org/jeps/jep-0077.html

Does this address the concerns?

This council has about 10 days left in its term. It would be nice to
finish up voting on this JEP by then.

We have -1 votes from Matt Miller and Thomas Muldowney.

The other Council members have not yet voted.

Peter

On Tue, 17 Aug 2004 11:08:25 -0600, Peter Saint-Andre <stpeter at gmail.com> wrote:
> I've parked them temporarily here:
> 
> http://www.jabber.org/~stpeter/jeps/77.html#precedence
> 
> Peter
> 
> On Tue, 17 Aug 2004 10:29:16 -0600, Matthew A. Miller
> 
> 
> <linuxwolf at outer-planes.net> wrote:
> > All of the explanations look sound to me.
> >
> > Can't wait to read them from http://www.jabber.org/jeps/jep-0077.html (-;
> >
> > -  LW
> >
> >
> >
> > Peter Saint-Andre wrote:
> > > On Tue, 17 Aug 2004 06:30:38 -0600, Matthew A. Miller
> > > <linuxwolf at outer-planes.net> wrote:
> > >
> > >
> > >>*  Section 5 seems to imply that x:data is used instead of the built-in
> > >>iq:register fields.  If this is the intent, it needs to be explicitly
> > >>stated.  If this is not the intent, then I would like that section to
> > >>contain language explicitly stating what takes presence (x:data form or
> > >>iq:register fields).
> > >
> > >
> > > A service could include both (iq:register for legacy clients that do
> > > not support x:data) or x:data only (e.g., if "extended",
> > > non-iq:register fields are required in the x:data form). If a client
> > > understands x:data, then the x:data form takes precedence (i.e., the
> > > receiving application must not mix and match iq:register fields with
> > > x:data fields).
> > >
> > >
> > >>*  Section 6 implies that x:oob is used instead of the iq:register
> > >>fields.  I would like this to be explicitly stated.
> > >
> > >
> > > First, this section is non-normative. However, I think that in most
> > > cases a given deployment would redirect potential registrants to a
> > > website because it already has a provisioning system running via the
> > > web and does not want users to register in-band via Jabber.
> > >
> > > In fact this raises a further question of precedence. There are many
> > > possible combinations:
> > >
> > > 1. iq:register only -- process as defined in the JEP.
> > >
> > > 2. iq:register + x:data -- process only the x:data if you understand
> > > it, otherwise process the iq:register fields (which are probably
> > > included for "legacy" clients).
> > >
> > > 3. iq:register + x:oob -- not recommended; if received, process the
> > > iq:register if you understand it, otherwise redirect to the URL
> > >
> > > 4. x:data + x:oob -- process the x:data if you understand it,
> > > otherwise redirect to the URL
> > >
> > > 5. iq:register + x:data + x:oob -- not recommended; if received,
> > > process only the x:data if you understand it; otherwise process the
> > > iq:register if you understand it; otherwise process the x:oob
> > >
> > > So x:data is always first in the processing order if you understand
> > > it, iq:register is always second, and x:oob is always last.
> > >
> > > If you don't understand any of these, you probably should not have
> > > sent the IQ get in the first place. :-)
> > >
> > > If this makes sense, I will adjust the text accordingly.
> > >
> > > Peter
> > > _______________________________________________
> > > 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
> 


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


More information about the Council mailing list