[Standards-JIG] Re: Council decision on "Simplified MUC" proposal

Nolan Eakins sneakin at semanticgap.com
Fri Mar 4 19:07:58 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Saint-Andre wrote:
| In its meeting earlier today [1], the Jabber Council discussed whether
| to accept the proposal for a "Simplified MUC" (or "MUC+") specification
| submitted by Nolan Eakins. [2]
|
| The consensus of the Council is that publishing a specification that
| modifies the complete JEP-0045 (as the current proposal does) would
| seriously confuse implementors. However, the Council would be open to
| considering a separate JEP that defines only the new functionality
| mentioned in the MUC+ proposal, if such a more limited JEP re-uses
| existing technologies by defining a profile of the "Ad-Hoc Commands"
| protocol specified in JEP-0050. [3]

First off I don't understand why ad-hoc commands should be used for what
was proposed. The changes made in MUC+ were incremental changes, not
revolutionary changes to MUC. I don't see why we would even want to
consider introducing a completely new groupchat protocol that did use
ad-hoc commands to do things that MUC already does but does not specify
completely due to the current use case organization.

Secondly this was intended to defer -0045 or replace it, not stand
alongside it since -0045 has not aged gracefully and changes/fixes have
not been done expediently. My primary concern with -0045 as it stands
now are the inconsistencies that exist in it, namely the affiliation
change table which specifies that admins AND owners can create/modify
other admins while the use cases specify that only owners can do that. I
chatted with PSA about this, and he agreed that admins shouldn't be
creating/modifying admins. Yet -0045 has not been updated.

The other changes were suggestions that were mentioned on this list, and
other holes in -0045 that I thought needed to be filled and some other
simplifications, ie: elimination of the "muc#owner" namespace in
changing affiliations. A different presentation, one that only diffed
- -0045, would only make implementing MUC more difficult in that two JEPs
would have to be referenced in which one is horribly in need of fixes. I
made the introduction of MUC+ the way it is to ease grokability by
identifying the differences which are not all that extreme.

Like all rejected JEP authors/modifiers I would have liked to see the
council to have voted the other way. There are a few changes that I've
been meaning to make to MUC+, and I suppose that if I don't see any
action on correcting the errors in -0045, incorporating the feedback
from this list, and specifying the behavior for some of the queries the
schemas allow but are not addressed due to the current organization of
- -0045 I will resubmit MUC+.

- - Nolan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCKLIOhuPszQVSPEARAn3fAKCjtSyyTt9mSJKZQfBUTrv1WDPc1QCbB8DU
CrINOBPcOvoJcMr6tfmvUxs=
=c7RJ
-----END PGP SIGNATURE-----




More information about the Standards mailing list