[Standards-JIG] EMUC proposal
jean-louis.seguineau at laposte.net
Sat Oct 14 12:04:15 UTC 2006
I agree entirely with the idea of using MUC as a framework for many-to-many
communication beyond text chat rooms. Your proposal is certainly the way to
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...) The XMPP philosophy is to have the complexity
implemented in the servers not the clients, and trying to leverage existing
MUC would bring most of the complexity into the clients, and probably oblige
to some MUC hacks as you point out.
In terms of features, keeping the current MUC implementations as they are is
obviously ensuring backward compatibility. For EMUC features, which may
probably vary according to usages, we would need:
** one way for a client to discover the feature set of an EMUC
implementation itself, and the feature set of any of its room.
** one way for a client to advertise its own capabilities to the EMUC or
EMUC room in order to automatically be associated with a certain profile.
And one way for an EMUC room to advertise its own capabilities.
The first point is obviously covered by XEP-0030: service discovery, and as
the MUC joining/departing process is based on presence, the second point is
covered by XEP-0115: Entity Capabilities.
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.
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. If this is not taking
place, then the implementation must fall back to the current MUC behavior.
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...
My high level two cents.
Date: Sat, 14 Oct 2006 08:45:36 +0200
From: "Michal 'vorner' Vaner" <michal.vaner at kdemail.net>
Subject: [Standards-JIG] EMUC proposal
To: Standards JIG <standards-jig at jabber.org>
Message-ID: <20061014064536.GC6058 at tarantula.kolej.mff.cuni.cz>
Content-Type: text/plain; charset="us-ascii"
There are many attempts to use MUC as a core for many other protocols,
like sharing/editing documents, attaching files to MUC and so on.
However it happens something is missing often. I have two ideas how to
accomplish it (in a backwards compatible way with actual MUC):
*) Allow at last directed <iq/>s (like to
someconf at conference.server/user). That would allow direct file transfers
between participants, calls (when there are capable jingle clients) and
so on. Then there could be invite able bots to do some more difficult
jobs - like multi file transfer, a bot could receive the file and send
it all, could be done in a hidden way somehow.
*) Make something like EMUC. More generalized component where you could
say on entry what profile do you want to use (the default unspecified
would be todays MUC) and you could choose something like "invisible
visitors" features and "allow <iq/>s" and others. And you could define
one by one or use some predefined profile as a base for the
configuration and modify it.
Do you think any of these would be of any use? Because the actual
situation seems to be a little bit hacky.
When eating an elephant take one bite at a time.
-- Gen. C. Abrams
Michal 'vorner' Vaner
More information about the Standards