[Standards-JIG] Re: LAST CALL: JEP-0117 (Intermediate IM Protocol Suite)

Peter Saint-Andre stpeter at jabber.org
Mon May 16 18:55:01 UTC 2005


On Sat, May 14, 2005 at 02:59:34AM -0500, Nolan Eakins wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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
> |>several options:
> |>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? 

They would be changed via subsequent room configuration.

> 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.

I don't think that came out as you intended. The relevant considerations
are to be discussed on this list and then the Council will try to make a
decision that's consonant with the list consensus.

> | 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.

Sure, that can be a deployment decision regarding room defaults. But if
most clients don't support room configuration or destruction, then most
deployments will choose not to allow persistent rooms. Not sure that's
good or bad, but a widespread deficiency in client implementations does
not strike me as a good reason for choosing that default.

Peter




More information about the Standards mailing list