Subject: [XCON] CPCP Review

From: "Chris Boulton" <[email-masked]>
Date: Fri, 14 May 2004 14:52:02 +0100

Hisham, Petri,

                        Had a good read of this and have included some
feedback.  To be honest the majority are NITS, so nothing really to
stress about.  Hope they are helpful.

Regards,

Chris.

Section 1.

Reads:

A centralized serve, called focus, can expel.....

And should read:

A centralized server, called focus, can expel....

Reads:

However, in many cases it is useful to have a standardised conference
policy elements such as access control lists and a standardised protocol
means to manipulate them.

And should read:

However, in many cases it is useful to have standardised conference
policy elements such as access control lists and a standardised protocol
means to manipulate them.

Reads:

One application area which has already adopted XCAP is the manipulation
of event lists [9].

Should read:

One application area which has already adopted XCAP is the manipulation
of presence lists [9].

Section 3.

Reads:

Access control list (ACL) defines users who can join to a conference.
Users may have allowed, blocked, pending or expelled status in the list.
Each conference has its own ACL.

Should read:

Access control list (ACL) defines users who can join to a unique
conference instance. Users may have allowed, blocked, pending or
expelled status in the list. Each conference has its own ACL.

Reads:

Conference participant is a user who has on-going session (e.g. SIP
dialog) with the conference focus.

Should read:

Conference participant is a user who has an on-going session (e.g.SIP
dialog) with the conference focus.

Reads:

Privilege control list (PCL) defines privileges for a user.  Each user
in a conference may have a different list of privileges and each
conference has its own PCL.

Section 4.

Reads:

Elements or attributes from unknown namespaces MUST be ignored. The
conference policy is build up using multiple namespaces:

Should read:

Elements or attributes from unknown namespaces MUST be ignored. The
conference policy is built up using multiple namespaces:

Reads:

This element includes informational describing the conference, e.g. for
search purposes.

Should read:

This element includes information describing the conference, e.g. for
search purposes.

Reads:

"urn:ietf:params:xml:ns:conference-fp": This optional namespace is for
the floor control policy. It defines the <Conference-floor-policy>
element.

Question: This is the only subsection that does not give a brief
descriptive summary.

Section 4.2.1

Reads:

<Max-participant-count> is an optional.

Should read:

<Max-participant-count> is an optional element.

Section 4.2.4

Reads:

This can be used in the where the allowed URIs are wild-carded and the
user wants to explicitly block one potential participant, whose URI
falls within the wildcarded URIs, from joining.

Should read:

This element can be used where the allowed URIs are wild-carded and the
user wants to explicitly block one potential participant, whose URI
falls within the wildcarded URIs, from joining.

Reads:

"Most-specific expression wins" policy is used if overlapping rules are
found. Basically, this means that user specific rule is searched first
and if it is not found, then most specific wildcard rule is utilized.

Question: What happens to conflicting values e.g. wildcard user matches
in allowed list BUT wild card domain matches in the blocked list?

Section 4.2.5

Reads:

The <PCL> element is mandatory and has its own XML namespace. It defines
which users has what privileges.

Should read:

The <PCL> element is mandatory and has its own XML namespace. It defines
users and their associated privileges.

Section 4.2.7

Heading Reads: 

<SC> (Security Control) element

Should read:

<Conference-SC> (Security Control) element

Reads:

The conference security settings start with the mandatory >SC> element.

Should read:

The conference security settings start with the mandatory
<Conference-SC> element.

Section 4.2.8

The <Max-floor-users> element in the <Floor> element is optional and, if
present, dictates the maximum number of users who can have the floor at
one time. The optional <Moderator-URI> indicates the URI of the
moderator. It MUST be set if the attribute moderator-controlled is set
to "true".

Question: Should we be specifying a default for this when not present?
E.g. 1.

------------------------------------------------
Chris Boulton
Ubiquity Software

Tel : +44 (0) 1633765600
Fax : +44 (0) 1633765601 
------------------------------------------------

This message has been scanned for viruses by MailControl - www.mailcontrol.com