[Council] JEP-0077?

Matthew A. Miller linuxwolf at outer-planes.net
Mon Aug 23 15:10:27 CDT 2004


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