[Standards-JIG] EMUC proposal

Michal 'vorner' Vaner michal.vaner at kdemail.net
Wed Oct 18 20:40:59 UTC 2006


On Sat, Oct 14, 2006 at 02:04:15PM +0200, Jean-Louis Seguineau wrote:
> I believe the point here is not to use existing MUC implementations for this
> but, as you propose, to come up with a superset of MUC (I suppose EMUC
> stands for Extended MUC...)

Well, it was Enhanced MUC, but it does not matter.

> This addresses only the way EMUC features and client capabilities can be
> advertised using existing XEPs. In addition, we'll also have to define
> behaviors with regards to certain features we would want in a particular
> EMUC room. While doing this we'll specify extension to the current
> broadcasting model to include other types of stanzas. I am thinking of
> Jingle support for example, but many of the ideas that came up lately on the
> list may well find a place here as well.

Yes, but that would have to be feature too, so if a client does not
know, it would have to behave the same.

> In essence, as the MUC itself, each chat room and each participant of each
> chat room is addressable by a JID, any kind of communication already taking
> place between two clients can possibly take place between two participants,
> or any participant and a room. The important point would be to avoid any
> assumption by making sure an EMUC client always goes through the discovery
> process and always advertise its own capabilities. 

They will not, since they will think it is MUC, if they are not EMUC
aware. But there can make assumptions that any client that a) understands
MUC and b) wants to use some of them, then they will check it and
present it. If they do not, no features would be activated for them and
it would either be usual MUC for them, or some of the features would be
required by the room (let's say there is a room where everything is
encrypted by some extension), then it may not be let in the room.

> If this is not taking
> place, then the implementation must fall back to the current MUC behavior.

Sure. Or to something close enough. Making sending <iq/>'s may be
possible even for them and they would just not use it, there is no need
for a conditional in the server.

> In term of XEPs, I believe we should follow the same approach as for Jingle,
> i.e. a high level XEP defining the additional discovery/advertising
> mechanisms available to an EMUC. Then a series of application XEPs would
> describe how to use EMUC for additional types of communication. We would
> have an EMUC Jingle support XEP, an EMUC file transfer support XEP, an EMUC
> shared editing XEP support, etc... 
That would seem to be a good way to me as well.

However, this would be more important XEP and I guess I do not have
enough experience to write it alone. Could anyone more experienced look
at it?


One semi-random fortune: 

Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
                -- Fred Brooks

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061018/82f25893/attachment.sig>

More information about the Standards mailing list