[jdev] MUC implementors poll

Tue Feb 7 18:46:57 CST 2006

Norman Rasmussen wrote:
> Only having ever implemented room config for the irc client (and even
> the using a form that was missing the FORM_TYPE), I can't say much,
> but I think I'd prefer to stick with Option #1, i.e. keep the namesas
> #roomconfig, and #register.  (This just makes more sense).
> 
> To be honest any application shouldn't be 'hard-coding' anything
> special to do with the FORM_TYPE, and it should rather be parsing the
> fields and diplaying them directly assuming a GUI is present.  I can't
> (off the top of my head) think of a good reason why you'd want to hard
> code anything for muc configuration in a GUI app.
> 
>>From JEP-0068: Thus this JEP enables existing clients to process forms
> as they have to this point, but enables JEP authors to specify a
> mechanism for non-GUI processors of those forms to determine the
> semantic meanings of those forms.
> 
> So any existing clients SHOULD not be affected by the change (or not)
> of the form namespaces.  I also can't think of any muc clients without
> a GUI.

I realize this would depart from existing practice, but in my opinion 
muc clients should depend on the roomconfig, etc... variables to display 
UIs, and not rely on the muc component to provide labels for the current 
locale.  It is not practical to expect deployers of MUC components to 
know in advance which client locales are going to be used.

The model of having the component/server/peer provide labels is fine for 
site-specific non-standard forms, but MUC is vastly implemented by many 
globally available clients, many of which are available in localizations 
that MUC component providers may or may not support.

Regardless of language, client developers may simply also want to have 
control over what the user reads in the UI.

Jacques

> 
> On a slightly different note: More clients/server implementations are
> currently broken because they still change admin and owner list using
> the #owner namespace and not the #admin namespace.  (Mainly due to
> jabberd1.4's muc component I think).
> 
> On 2/7/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>In version 1.17 of JEP-0045 (2004-10-04), the FORM_TYPEs for room
>>configuration and for user registration requests were modified. This
>>change was introduced late in the standards process and may not have
>>been advisable (that's the same day the XMPP RFCs were published,
>>perhaps I was distracted). I'd like to take a poll of those who have
>>implemented JEP-0045 (either in a server or in a client). The question
>>is, which of the following would you prefer:
>>
>>1. Retain the change made in 1.17, which specifies the following:
>>
>>   room config: http://jabber.org/protocol/muc#roomconfig
>>   registration requests: http://jabber.org/protocol/muc#register
>>
>>2. Revert to the old FORM_TYPEs:
>>
>>   room config: http://jabber.org/protocol/muc#owner
>>   registration requests: http://jabber.org/protocol/muc#user
>>
>>Feel free to reply on or off list and I will tabulate the results.
>>
>>Peter
>>
>>- -------- Original Message --------
>>Subject: Re: [Standards-JIG] JEP-0045 namespace changes
>>Date: Tue, 07 Feb 2006 11:57:15 -0700
>>From: Peter Saint-Andre <stpeter at jabber.org>
>>Reply-To: Jabber protocol discussion list <standards-jig at jabber.org>
>>To: Jabber protocol discussion list <standards-jig at jabber.org>
>>References: <8D96EDA0AC04D31197B400A0C96C14800EA301D5 at corp.webb.net>
>>
>>Constantin Nickonov wrote:
>>
>>>Does anyone recall why the room configuration namespace change (ref.
>>>http://www.jabber.org/jeps/jep-0045.html#revs, Version 1.17) was made to
>>>JEP-0045 long after it was an accepted draft. As a result, existing
>>>implementations are in the unenviable position of choosing to keep the
>>>original implementation and fall out of compliance with the JEP (and
>>>thus, other implementations) or making the server-side change and
>>>leaving existing clients out in the cold.
>>>
>>>My recommendation would be to revert to the original namespaces, but I'm
>>>sure that this would probably cause similar problems for newer
>>>implementations. Any ideas or suggestions?
>>
>>I agree that this change was probably unforutunate but I don't remember
>>why we made it -- perhaps there was a concern about confusion regarding
>>muc#user and muc#owner but I don't recall.
>>
>>At this point it seems best to retain the change (MUC service
>>implementations could look for both the old and the new FORM_TYPEs, be
>>liberal in what you accept and all that) but I'm not wedded to that.
>>Perhaps it make sense to poll implementors to see what their preference
>>is (e.g., I doubt that mu-conference has been brought up to date).
>>
>>Peter
>>
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.1 (Darwin)
>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>>iD8DBQFD6PHFNF1RSzyt3NURAiCjAJ9DILqRvWlYT/3vOpVm81pQ4Czw+QCcCelh
>>l/OdZaD2vG0m3qYyNwsNj4k=
>>=F8Cp
>>-----END PGP SIGNATURE-----
>>
>>
>>
> 
> 
> 
> --
> - Norman Rasmussen
>  - Email: norman at rasmussen.co.za
>  - Home page: http://norman.rasmussen.co.za/