[Standards-JIG] Council decision on "Simplified MUC" proposal
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. 
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
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.
More information about the Standards