[Council] JEP-0077?

Peter Saint-Andre stpeter at jabber.org
Wed Aug 25 11:41:37 CDT 2004


Super. Anyone else care to weigh in?

Peter

On Mon, Aug 23, 2004 at 02:10:27PM -0600, Matthew A. Miller wrote:
> Looks good to me now.
> 
> +1
> 
> 
> -  LW
> 
> Peter Saint-Andre wrote:
> >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



More information about the Council mailing list