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. 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > Reply-To: Jabber protocol discussion list <[EMAIL PROTECTED]> > To: Jabber protocol discussion list <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> > > 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: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/
