Subject: RE: [XCON] CPCP - making something simple that works

From: Avshalom Houri <[email-masked]>
Date: Mon, 1 Dec 2003 14:26:22 +0200

I think that expelling users is more often used in open communities as IRC 
and rarely
(if ever) used in enterprise conferences.
I agree that we should define a minimal set of features for the first 
version of CPCP but the main question will be
how we make sure that it is extendable. If we find a good way to extend, 
the initial set of features will be less important.

Avshalom

[email-masked] 
Sent by: [email-masked]
30/11/2003 11:49 PM

To
<[email-masked]>, <[email-masked]>
cc
<[email-masked]>
Subject
RE: [XCON] CPCP - making something simple that works

Hi,

There is one use scenario for CPCP where the capability to expell seems 
necessary. I would like to build with SIP, MSRP and CPCP a "text chatroom" 
service similar to something like what is available in IRC, Jabber or 
Wireless Village. My understanding is that in those kind of services 
expelling users is something which is actually used. 

On the other hand, if you can do the same thing (for one participant at a 
time) with SIP REFER, expelling may not be needed in the initial set of 
CPCP features. Mass-expel is probably not used that much.

Markus 

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 30 November, 2003 21:28
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: Isomaki Markus (NRC/Helsinki); [email-masked]
> Subject: Re: [XCON] CPCP - making something simple that works
> 
> 
> 
> > I believe timing is important and is one major advantage of 
> CPCP over
> > ad-hoc conferences.
> 
> Note, however, that this can easily be done by an external 
> application 
> that uses a normal calendaring mechanism (such as the iCal extensions 
> for events) and then generates CPCP requests. Having a very simple 
> single start/end-time (no repeats) is sufficient for that and 
> does not 
> add significant complexity.
> 
> > 
> > What about security of the conference? is that a priority? How
> > desides on the level of security and what protocol to use? who sets
> > the password for the conference? I am ok with having a default
> > authentication mechanism like digest for joining a conference.
> 
> I would find it peculiar if joining a conference required 
> anything other 
> than a standard SIP client, for example.
> 
> > 
> > There is also the issue of expelling users. What is the opinion on
> > that? Is it important?
> 
> I have never seen that be used in real conferences, even where the 
> feature was available. If this is a rather rare event, it is 
> easier to 
> create a new conference without the offending user and have everyone 
> minus one move to the new conference. The much more common 
> case is the 
> executive session (or the jury session, e.g., for a thesis defense), 
> which seems most readily modeled as two sessions with distinct 
> participants, set up from the beginning.
> 
> The problem with expelling is that this adds the risk of accidental 
> invocation and probably does not deal with the full range of Robert's 
> Rules stipulations and procedures.
> 
> I think a natural threshold for initial inclusion is common usage in 
> today's conferencing systems.
> 
> Henning
> 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Orit Levin" <[email-masked]>
Date: Mon, 1 Dec 2003 11:31:02 -0800

I second the "extensibility requirement" 100%.

Simple (both ad-hoc and pre-configured) conferencing can be done with
SIP today. (See
http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-0
2.txt).

The reason for launching XCON is to come up with a standard and
convenient way (for users) to do more than that in extensible manner.

Orit.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Avshalom Houri
Sent: Monday, December 01, 2003 4:26 AM
To: [email-masked]
Subject: RE: [XCON] CPCP - making something simple that works

---skip 

Avshalom 

[email-masked] 

30/11/2003 11:49 PM 

To

cc

<[email-masked]> 

Subject

---

From: [email-masked]
Date: Tue, 2 Dec 2003 12:11:05 +0200

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Michael Hammer
> Sent: 01.December.2003 17:58
> To: Henning Schulzrinne
> Cc: Khartabil Hisham (NMP-MSW/Helsinki); Isomaki Markus 
> (NRC/Helsinki);
> [email-masked]
> Henning,
> I can name two cases where explicitly expelling someone is useful:
> 
> 1) An enterprise conference is discussing company sensitive 
> material of 
> economic value and someone manages to join and refused to 
> identify themselves,
> 
> 2) Someone on the conference puts it on hold improperly and 
> plays music on 
> hold to the conference.
> 
> Both of these happen frequently enough that an ability to eject the 
> offending user is desirable and more preferable to wasting 
> time getting 
> everyone to move on to another conference.  It shouldn't be 
> necessary to 
> get hold of a moderator to do the expelling.

Of course you need the moderator to do the expelling, otherwise this unwanted participant can expel other participants.

/Hisham
> 
> Mike
> 
> 
> At 02:27 PM 11/30/2003 -0500, Henning Schulzrinne wrote:
> 
> >that uses a normal calendaring mechanism (such as the iCal 
> extensions for 
> >events) and then generates CPCP requests. Having a very 
> simple single 
> >start/end-time (no repeats) is sufficient for that and does not add 
> >significant complexity.
> >
> >I have never seen that be used in real conferences, even 
> where the feature 
> >was available. If this is a rather rare event, it is easier 
> to create a 
> >new conference without the offending user and have everyone 
> minus one move 
> >to the new conference. The much more common case is the 
> executive session 
> >(or the jury session, e.g., for a thesis defense), which seems most 
> >readily modeled as two sessions with distinct participants, 
> set up from 
> >the beginning.
> >

---

From: Michael Hammer <[email-masked]>
Date: Tue, 02 Dec 2003 10:38:26 -0500

> > economic value and someone manages to join and refused to

On thinking further, I would hope that the authentication and authorization 
capabilities (presumable a white list) would prevent this problem in the 
first place.

> > 2) Someone on the conference puts it on hold improperly and

I agree that having the ability to mute that one offending party is better; 
much kinder than my original suggestion.  But, part of me wants to provide 
some negative feedback to the offender, so they have to work to get back 
in, and thus less likely to offend again. :)

>Of course you need the moderator to do the expelling, otherwise this 
>unwanted participant can expel other participants.

Your moderator being someone participating in the conference and the one I 
was referring to being an operator somewhere that has to be fetched, as is 
sometimes the case today, are two different things.  A user-friendly 
well-designed self-service interface would be very desirable.

Mike

---

From: Adam Roach <[email-masked]>
Date: Thu, 11 Dec 2003 15:21:19 -0600

Henning Schulzrinne [mailto:[email-masked]] writes:

> feature was available.

[as not chair]

I would argue that this is probably due more to the interfaces
of current "real" conferences rather than people not wanting to
make use of the feature. Navigating the list of participants
to select one to eject is clunky at best over a DTMF interface --
and that's assuming one can recall the magic series of keystrokes
to invoke the procedure in the first place.

  **SSSSSSSSSSSSSHHHSHSHSHHSH**

  "I think someone's cordless phone died. Does anyone remember
   how to kick someone off the bridge?"

  "I think it's star-eight-something."

  "No, that's on the Acme bridges. I think you hold down pound
   for a long time and then wait for the menu."

  **BEEEEEEEP**

  "Hmmm. That didn't work."

As has been pointed out, in text environments (think IRC), removing
people from a conference is used quite often. ("/kick offensive_user"
has a good mnemonic value to it). Ease of use leads to use.

[as chair]

From a more immediate perspective, I sincerely hope that the
protocol we develop is useful enough that it can be used
with -- or at least interoperate with -- XMPP systems. Without
an ejection function, there is no chance of either.

/a