[XCON] Review of draft-ietf-xcon-ccmp-03

[Richard Barnes <rbarnes at bbn.com>]

Hi all,

In my effort to get up to speed on XCON, I'm in the process of reviewing 
the active working group drafts (in addition to the other relevant 
background).  My review of draft-ietf-xcon-ccmp-03 is below.

--Richard


-----
Draft:  draft-ietf-xcon-common-data-model-13
Reviewer: Richard Barnes
Review Date: 18 Aug 09

General comments:
1. The protocol seems pretty well thought out.  Most of the below 
comments are focused on clarity, but there are also a couple of 
technical issues to be addressed.

2. It seems like this document and the data model should both use the 
same specification language, either XSD or RelaxNG, to facilitate 
parsing/validation.

3. The document uses a mixture of single (') and double (") quotes 
around things like element names.  Might be nice to standardize on one 
or the other.


Specific comments:
Abstract
The abstract says that CCMP is stateless, but that seems a little weird 
given that the whole point of the protocol is to modify the state of the 
conference server.  I understand the intent (the protocol itself is 
stateless), but you might think about rewording.

Section 4/5
These two sections could probably stand to be merged.  I think it would 
be helpful to have the content of Section 5 (especially Figure 1) before 
most of Section 4, except maybe the first paragraph.

Section 5
Make sure that the label for Figure 1 stays with the figure.

Section 6
This section seems to be a little confused about what its purpose is. 
The stated purpose is to give an overview of the conference and user 
objects, but it has several tangential comments about how these objects 
are handled in certain cases.  Think about tightening the scope (see below).

Section 6.1, Paragraph 1
It might be helpful to provide a reference to Section 7.1 (Cloning Tree) 
of RFC 5239 here.

Section 6.1, Paragraph 2, "A client MAY specify a parent element..."
The phrase "parent element" is a little confusing here, since we're 
talking about XML objects, and the "parent" relationship is not in terms 
of XML elements, but rather objects in the cloning tree.  Suggest 
changing this sentence to "A client MAY specify a parent object (a 
conference or blueprint) from which to inherit values."

Section 6.1, Paragraph 2, "When creating conferences..."
This sentence seems like it belongs in Section 7.2.3.4 instead of here.

Section 6.2, Paragraph 1, "Users are inherited as well..."
For clarity, suggest adding "When a conference is cloned from a parent 
object..."

Section 6.2, Paragraph 3
This paragraph seems like it belongs elsewhere, e.g., in Section 7.2.3.4 
or 7.2.3.6.

Section 7.2
It took me a little while to figure out why all the messages in the 
example are doubled up: "<ccmpRequest><ccmpRequest>..."  It would be 
helpful here to explain the general design methodology being followed 
that leads to that.  As I understand it, the idea is that you can carry 
multiple request and response messages within a single request or 
response.  This idea would be helpful to note, as well as some idea of 
how request and response messages are correlated.  Also, since you 
define elements for the detailed messages types, it would be clearer to 
use those types in the examples (in Section 8), rather than casting with 
xsi:type.

Section 7.2.1, confUserId, "This attribute is required ..."
Should there be RFC 2119 requirement here? "This attribute is REQUIRED..."

Section 7.2.1, password
I'm confused about how this parameter interacts with the 
<conference-password> element in the data model: In the data model, 
conference passwords are only scoped within a given <conf-uri>, whereas 
a password for a CCMP request would presumably need to be scoped at the 
level of the conference.  Or is the CCMP password an independent value 
not reflected in the conference object?

Section 7.2.1, Figure 2
It was helpful to have this structure here.  It would be even better if 
a brief example could be provided as well.  Likewise for other sections 
below.

Section 7.2.2.1
It's a little confusing to have the error messages introduced at this 
point in the document, since the actions themselves haven't been 
defined.  Perhaps Table 2 (probably with the introductory text to 
Section 7.2.3) could be moved up to Section 7.2.1 to give a clearer idea 
of what the operations do.

Section 7.2.3, Paragraph 3 (counting the bulleted list as 1 para)
You need a different symbol than "N/A*" here, since * is also used with 
a different meaning in the table.

Section 7.2.3.3, Paragraph 3
The first sentence seems odd -- it's not clear in general that it 
another blueprint would be useful to the conference client, so why would 
it be RECOMMENDED to try another?  Suggest changing to the following: 
"If a response code fo "objectNotFound" is received in a 
'blueprintResponse' message, a conference control client may attempt to 
retrieve another conference blueprint if more than one had been received 
in the "blueprintsResponse" message."

Section 7.2.3.4, Paragraph 6 (counting 2 bullets as 1 para)
The following phrase is confusing:
"
The 'confInfo' represents an object of type "conference-type" containing 
all the changes to be applied...
"
"Conference-type" object, i.e., conference objects, represent conference 
state, not changes.  I see in the example (Section 8) that the intent is 
to allow clients to send only a fragment of the conference object, 
rather than the whole thing.  There should be more discussion here about 
how the client constructs the right fragment to express his changes, and 
how the server interprets the fragment it gets.

Section 7.2.3.5-10
Since users and sidebars are both sub-elements of the conferene object, 
what's the rationale for handling them via separate CCMP requests?  Is 
the idea that it simplifies permissions management for the server (in 
the case where some users are only allowed to access users/sidebars), 
since the server doesn't have to look at what's in the changes to check 
permissions?

Section 7.2.3.5-10
Also, it seems like these messages should follow the pattern of the 
blueprint[s] and conf[s] messages above: The plural messages should be 
retreive-only, while the singular messages should allow other operations.

Section 7.2.3.5-6
How do these CCMP operations interact with the signaling protocols? 
Presumably when a user joins via a CSP, he is added to the conference 
object; is this equivalent to a userRequest/create operation?

Section 7.2.3.5, Paragraph 2
s/userInfo/usersInfo/

Section 7.2.3.5, Bullet 1 (retreive)
Change SHOULD NOT to MUST NOT, since it is ignored anyway.

Section 7.2.3.5, Bullet 2 (update)
Same concern here as with 7.2.3.4 above -- how do you represent changes 
with a users-type object?

Section 7.2.3.6, Paragraph 1, "Note that a user..."
This sentence seems like a non-sequitur: If a client is not XCON-aware, 
then it's not going to generate these messages.  Recommend saying 
instead that some CSP operations might have the same effect as these 
operations, i.e., that when a user joins/leaves/etc, the conference 
server might perform an action that would otherwise be performed via a 
userRequest.

Section 7.2.3.6, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes 
with a user-type object?

Section 7.2.3.8, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes 
with a conference-type object?

Section 7.2.3.10, 'update' paragraph
Same concern here as with 7.2.3.4 above -- how do you represent changes 
with a conference-type object?

Section 9
Is this the process for dereferencing an XCON-URI?  If so, you should 
say so.

Section 11, Paragraph 3
The second sentence here ("Because the conferencing client...") doesn't 
make sense.  The reason you're not requiring HTTP authentication and 
cookies is that CCMP has its own authentication.  Suggest replacing with
"
A conferencing client that conforms to this specification is not 
required to support HTTP authentication [RFC2617] or cookies [RFC2965]. 
 These mechanisms are unnecessary because CCMP requests carry their own 
authentication information (in the 'confUserId' and 'password' fields; 
see Section 7.2.1).
"

Section 11, Paragraphs 4 and 7
Change first sentence to "CCMP requests MUST be carried in the body of 
an HTTP POST request.  If a CCMP server receives an HTTP request using a 
method other than POST, it must respond with an error message, e.g., 404 
(not found)."  In light of this change, paragraph 7 could be deleted. 
On the other hand, it seems like it wouldn't be unreasonable for the 
server to respond to a HEAD request.  In which case: "CCMP requests MUST 
be carried in the body of an HTTP POST request.  A CCMP server MAY 
respond to HEAD requests.  If a CCMP server receives an HTTP request 
using a method other than POST or HEAD, it must respond with an error 
message, e.g., 404 (not found)."

Section 12
The security considerations here are relatively comprehensive, but a 
little scatter-shot.  I will provide a more thorough review of this 
section later.

Section 14.4.1-2
I'm guessing you mean to register "Conference Server" tags rather than 
"Location Server" tags, and for CCMP rather than HELD.