[Standards-JIG] RFC: NGMUC -- Problems of and suggestion on JEP-0045 (Multi User Conference)

[Peter Saint-Andre]

First comment: you don't offer any suggestions for fixing these
perceived problems. How do you think they should be solved?

More comments below...

tmarkmann at googlemail.com wrote:
> > Hello protocol developers and other interested recipients.
> > 
> > FROM: Jabber Wiki <http://wiki.jabber.org/index.php/NGMUC>
> > 
> > The protocol which is used for many-to-many conversations nowadays:
> > JEP-0045 <http://www.jabber.org/jeps/jep-0045.html>
> > 
> > =Issues=
> > Here is a list of some things which would be nice to have.
> > 
> > ==Resource Support==
> > JEP-0045 doesn't support multiple resources for one participant. You
> > have to log into the conferece again as another participant by using
> > another nickname. Multiple participants who are one and the same
> > individual can lead into confusion and missunderstanding. Of course
> > there is not much confusing in room with just 13 participants but
> > the
> > jabber protocol is no hobby project and up to 100 users can join a
> > conference.

In fact you *can* join the same room many times, but each of your
resources has a different roomnick.

Some questions:

1. How common is this behavior? Do people really join the same room
multiple times? Most IM users don't even use multiple resources, after
all.

2. Can this be solved at the client side by showing the user's bare JID
(in non-anonymous rooms) or preferred nickname (JEP-0172)?

3. If you can have one roomnick (room at service/nick) for multiple
resources, how do you propose to handle the message routing? Does the
service send the message to all resources or only the most available?

> > ==Role/Affiliation Management==
> > Roles and Affiliations are inconsistent.  JEP-0045 treats them as if
> > an
> > affiliation implies a role, but in fact affiliations have effects
> > beyond
> > the roles assigned.
> > 
> > * A moderator role with an admin affiliation can ban people, while
> > other
> > moderators can't.
> > 
> > * A moderator role with an owner affiliation can configure the room,
> > while other moderators can't.
> > 
> > * In some rooms, a participant role with a member affiliation can
> > modify
> > the topic, while other participants can't.
> > 
> > * In some rooms, a member can send a message, while non-members
> > cannot.

Some people see these as features, not bugs. Or at least to me you have
only described the current functionality and have not justified why you
think they are bugs. Is the current functionality causing problems, race
conditions, security concerns, usability problems, etc.?

> > The other half of the problem is that affiliations persist, while
> > roles
> > do not.  This tends to make the role system close to useless, since
> > no
> > change will stick around after the assignee leaves.　

The JEP explicitly says that services may cache roles if they want to
and SHOULD do so for moderated rooms.

> > Impossibilities
> > under the current system:
> > 
> > * Allow someone to kick, but not ban, and change the topic, and make
> > this status remain even if they leave and return.
> > 
> > * Prevent someone from speaking in a room, and make sure they can't
> > get
> > around it by simply leaving and rejoining.
> > 
> > * Allow someone to speak in a room, and make sure it stays that way
> > when
> > they leave and rejoin.

See above on persisting roles in moderated rooms.

> > Finally, the roles and affiliations distinction makes for a complex
> > 2-dimensional grid of possibilities, with 20 combinations where only
> > 13
> > actually make any sense (you can't have an admin or owner who is not
> > a
> > moderator, or an outcast who has any role except "none"), 

This seems like a bookkeeping objection to me, not anything substantive.
So what if the matrix is incomplete?

> > and even less
> > are useful (admins and owners can't be kicked, 

Some people see this as a feature. We carefully designed the room
ownership and administration privileges to avoid race conditions that
exist in IRC.

> > outcasts can't hold any
> > role but "none", 

So what?

> > and the moderator/participant/visitor roles don't
> > persist for members or "none")

See above on persisting roles in moderated rooms.

> > ==Support for More Participants==
> > This is the easiest point. You just ged rid of the thought that the
> > jabber protocol and its enhancements called JEPs were just written
> > for
> > hobby usage. It's altogether a serious project which is used by
> > hundred
> > tousands of people. Where is the advantage of a conference with
> > limited
> > participants? In IRC networks there are rooms with 700 people
> > inside.
> > Who said that isn't possible with jabber technologies? I think, it
> > is.

Nothing in the JEP limits the number of occupants in a room (nor the
number of rooms hosted by a service), just as nothing in RFC 3920/3921
limits the number of concurrent users at an XMPP server. However, a
given implementation may effectively limit the number of occupants,
rooms, or users. The answer to that is: improve the implementation.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml