[Standards-JIG] Re: LAST CALL: JEP-0117 (Intermediate IM Protocol Suite)
sneakin at semanticgap.com
Sat May 14 07:59:34 UTC 2005
-----BEGIN PGP SIGNED MESSAGE-----
Peter Millard wrote:
| On 5/12/05, Peter Saint-Andre <stpeter at jabber.org> wrote:
|>Several issues arose in today's Jabber Council meeting regarding this
|>JEP, specifically: which parts of JEP-0045 shall we require? There are
|>1. Require occupant use cases and creating an instant room (this is
|> what the JEP specifies right now).
|>2. Require occupant use cases and all room creation / configuration
|> use cases (not just instant room, but full room config).
|>3. Require occupant use cases, all room creation / configuration
|> use cases, and the room destruction use case.
|>4. Require all of JEP-0045 (including all owner+admin use cases).
| I think option (3) makes the most sense given the implementations I've
| seen so far. For example, the mu-c application as well as commercial
| implementations have a number of room config options that it makes the
| most sense to allow users to deal with them. The most common argument
| I've heard for NOT doing room config is that it is hard to make a
| decent x-data rendering engine. While I agree, that it is difficult,
| I'd say that the non "basic" IM suite can/may/should include some more
| advanced jabber features, and x-data is definitely something that can
| be used a lot in a good client.
If you're suggesting (3) then why not go ahead and move to (4)? If you
can configure the room then you can configure it to default occupants to
visitors, or the room be members only. How would they be changed? At
least with (1) you get some defaults that can't be changed that'll
presumably default to some kind values like occupants being
participants, the room being non-persistent, etc.
(1) - Makes sense if you don't want to put in all of MUC.
(2) - None at all
(3) - May as well goto level (4)
(4) - It's everything.
I'm against (2) and (3). I'll leave the decision of (1) or (4) to you.
| Clearly, if a user can create a room with a client, it MUST be able to
| destroy the same room. Anything else doesn't make sense (and is an
| abuse of system resources IMO).
Or not be able to create a persistent room.
- - Nolan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards