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

From: [email-masked]
Date: Sun, 30 Nov 2003 20:53:07 +0200

Hi,

I would like to propose that XCON WG makes some descoping for CPCP functionality in the initial phase. In my opinion the current requirements draft contains a lot of features, that are useful, but not necessary in the first version. I think we need to discuss on prioritization to have any chance to meet the deadlines proposed in the charter.

Obviously the success of this approach depends on whether the WG can agree on what would be the prioritized subset. Below I list the things that are in my opinion the most important ones:
- Conference creation and conference URI assignment
  (It is possible to use SIP INVITE for this in ad hoc case, but something more permanent is definitely needed.)
- Authorization rules for joining the conference (~ACL) and doing some key operations, such as subscribing to conference state event.
- Doing mass-invitations/having a dial-out list. This should include mass-kickout functionality too.
  (SIP exploders are supposed to do this too, so this may not belong to the most-important category if exploder solution turns out good, of course we should be thinking of non-SIP session management environments in XCON too.)
- Describing a small set of conference meta-data (Subject etc.)

At least I would be happy with a protocol that can initially do these operations. Timing/scheduling etc. could be added later. This makes an obvious requirement to the protocol that it must be extensible, and it should be possible to determine the feature set supported by the conference (policy) server.

Comments? Do people want to go along with all possible bells and whistles, or is there support for this descoping activity?

Markus  

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

---

From: [email-masked]
Date: Sun, 30 Nov 2003 23:49:34 +0200

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
>