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

Ralph Meijer jabber.org at ralphm.ik.nu
Sat Mar 5 09:40:06 UTC 2005

On Fri, Mar 04, 2005 at 02:07:58PM -0500, Nolan Eakins wrote:
> 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.

Basically, I think you tried to do too much at a time here. You want to
reword JEP-0045 so that it is easier to understand for implementors, fix
inconsistencies in the text *and* protocol, add new functionality and finally
deprecate some stuff. I'll address ad-hoc commands further down.

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

Well, if JEP-0045 is unclear in many respects, it needs fixing. Sending
in a complete new text doesn't help there, in my opinion. Specifically
because they have to work through two documents now and find out the

Wouldn't it be better to make a full list of the clarifications to both text
and protocol (both from you and what has been posted to the list) and work with
JEP-0045's author to get them in? Not speaking for, I suppose he would be quite
willing to take on this effort, now the jabber.org intrusion stuff is settling

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

If the additions would work with existing implementations (both client and
server) as well, I don't see why they couldn't be incorporated into (a
reworded) JEP-0045. I couldn't find what muc#plus *exactly* covers in one
place. So that's why we requested the addional stuff as a separate JEP.
If the additions are really slight modifications to the existing protocol,
ad-hoc commands might not be necessary. I can't tell at this point.

> 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+.

I believe resubmitting MUC+ in its current form, or possibly with even more
changes with respect to JEP-0045, would be waste of time, both of you and of
the Council. Again, if JEP-0045 is broken in certain respects, we (the Council)
should probably be held accountable. Please work with the author of JEP-0045 to
address this.

Do note that I appreciate any efforts to make the Jabber protocols even better.
I suspect Peter to crack the whip again in the Council to get things moving



More information about the Standards mailing list