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

From: [email-masked]
Date: Sun, 30 Nov 2003 21:05:46 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 30.November.2003 20:53
> To: [email-masked]
> Subject: [XCON] CPCP - making something simple that works
> 
> 
> 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.

I believe timing is important and is one major advantage of CPCP over ad-hoc conferences.

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.

There is also the issue of expelling users. What is the opinion on that? Is it important?

Regards,
Hisham

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 30 Nov 2003 14:27:40 -0500

> I believe timing is important and is one major advantage of CPCP over

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

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