[Standards-JIG] EMUC proposal
huguespisapia at gmail.com
Thu Oct 19 09:00:52 UTC 2006
I recently posted the attached protoxep to the xep editor for comments
This proto is based on what we did at Horizon WImba to enable audio
communication in a MUC room. One of the though behind that was to be
extendable enought to enable other means of collaboration in a Room
-the reason why it's named "Multi-User Collaboration"-
Initially, it did not use Jingle as it was not yet drafted, but we
should use that to establish connection between a client and a "Room"
(the server would be multiplexing/reflecting the media sent by
As of now, it is very basic, but defines how communication, and who
control them, should take place in a room. As Jean-Louis said, each
type of media (screen/document sharing, audio/video, other...) should
have it's own XEP.
On 10/18/06, Michal 'vorner' Vaner <michal.vaner at kdemail.net> wrote:
> 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
e: hugues at labarben.org
JID: huguespisapia at im.apinc.org
Fight Multiple Sclerosis - http://odyssee-espoir.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 51347 bytes
Desc: not available
More information about the Standards