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

JD Conley jd.conley at coversant.net
Thu Mar 3 19:20:55 UTC 2005

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

[JD Conley] 
There are enough existing implementations out there that I agree the
MUC+ spec should be a diff rather than a re-write.  

However, some of the items in MUC+ would be very useful outside of
Ad-Hoc Commands and in the core MUC namespaces.  Am I understanding you,
the Council, correctly that you would like to limit the enhancements to
Ad-Hoc Commands?

For example, it is very useful to get and set multiple items in the
#owner namespace with one request.  Our implementation does this today
in its management console.  If a namespace was added to the disco
features of the component to signal that the MUC+ features were
supported I don't see the harm in using existing MUC namespaces where
appropriate and where there would be no impact to existing

Forgive me if I misunderstood the intent of the Council.

JD Conley

More information about the Standards mailing list