[Standards-JIG] EMUC proposal
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Fri Oct 20 19:04:49 UTC 2006
I have read the proposal and I generally like it, but I found few little
things I would like to point out.
The media types and so should be completely external (I think you
mentioned that in your last mail).
I guess I had read on this mail-list somewhere that <x/> elements are
considered as unhappy and something more specific should be used.
I would not only add new media, but allow for modifications of usual MUC
behaviour - for example, if you define a fully encrypted MUC session,
no-one should be allowed to send a <body/> element and if he/she did, it
would be eaten by the component.
That would as well mean <media/> element would not be adequate name,
<extension/> would be better in that case.
It would be nice to allow more than one media of the same type. It makes
no sense with audio for example, but it may come handy to have more than
one shared edited document.
As well, it would be nice to assign each media a name and description
and allow clients to get this info without accepting or rejecting the
Sometimes, some kind of media or extension could be required to really
join (again, with the encryption for example).
If a client does not support mucol, it should act as it denied all the
It is nice a user can deny the media if he is in some situation it does
not allow, but it may be needed to connect there later, when the
conditions change (if the student from the example leaves, he can
connect to the audio).
I would suggest removing 'unknown' role and have none all the time,
until the user does not accept or he disconnects from the media
(temporarily or permanently).
I did not find what kind of form it should send to the admin, if a
confirmation is needed. (section 5.2.2, example 15).
I guess the server should add the media and mucol info to invitation (it
is in the example, but not in the text above; section 5.2.7).
This message has optimized support for formating.
Please choose green font and black background so it looks like it should.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards