[Council] Re: VOTE: JEP-0133 (Service Administration)

Peter Saint-Andre stpeter at jabber.org
Mon Dec 6 17:41:26 CST 2004

In article <stpeter-F4AD15.15223101122004 at sea.gmane.org>,
 Peter Saint-Andre <stpeter at jabber.org> 

> In article 
> <081A634B-419A-11D9-B337-000A95984138 at box5.net>,
>  Thomas Muldowney <temas at box5.net> wrote:
> > Only thing that is jumping out at me is related to FORM_TYPE.  All of 
> > the FORM_TYPE entries use the same namespace which is kind of annoying 
> > because it means you have to go back a step to the command node 
> > attribute to get a more true definition of what form is being filled 
> > out.  From looking over the FORM_TYPE JEP and other FORM_TYPE users 
> > (pubsub and muc) I would say this is probably wrong and we need a more 
> > complete FORM_TYPE for each separate form.  Yay/nay?
> I'd say "maybe". ;-)
> My understanding of the FORM_TYPE field is that it is intended to 
> provide a way to scope a variable (for example, it seems to me that the 
> 'jid' field refers to the same thing in all of these interactions). The 
> FORM_TYPE is not intended to uniquely identify a specific form in the 
> way you describe -- presumably the entity initiating the interaction (in 
> this case a client) would keep track of the fact that a certain 'id' 
> attribute value is connected with a request to set the welcome message 
> or whatever, and thus would not need to depend on the FORM_TYPE to make 
> that determination. At least, that is how I understand FORM_TYPEs. But 
> perhaps I'm wrong about their meaning and usage -- it wouldn't be the 
> first time. :-)

An updated version is now available (0.8):


Still not sure exactly how we want to address the expressed desire 
(requirement?) to more triumphantly limit the list of active or 
registered users (e.g., regex matching?).


More information about the Council mailing list