Centralized Conferencing Manipulation Protocol
RFC 6503

Note: This ballot was opened for revision 15 and is now closed.

(Robert Sparks) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-05-23 for -)
No email
send info
On the basis of trusting that others who have greater knowledge of this subject matter have reviewed this document I am voting no-objection.

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-05-25)
No email
send info
BTW, I appreciated the many examples, although they might have been 
moved to an appendix to clear the floor for the main meat of text
(is that metaphor too horribly mixed?). I also wasn't convinced by
including all of the schema fragments in-line as well as in Section 11,
but this is probably a stlistic choice that is not important.

---

Nit

5.4. 

   All CCMP response messages MUST include a ""response-code"".  The

You probably don't need the quad-quotes.

(Stephen Farrell) (was Discuss) No Objection

Comment (2011-07-18)
No email
send info
--- original discuss on -13, addressed by -14

(1) Not requiring HTTP or TLS client-authentication mechanism seems to me to be
a mistake. Its more likely that HTTP authentication will be maintained in
future (e.g. extended for oauth, saml, etc) than that CCMP will be.  I would
suggest getting rid of the "not required" in section 9 on that.

(2) The response codes in 5.4 seem to be a subset of those from rfc 2616.  I
think it'd be better to not replicate the descriptive text about those, nor the
codes themselves - how is the combination of HTTP response codes and CCMP
response codes supposed to work? E.g. if I get a HTTP 200 but a CCMP 404 in one
response then what? I could imagine coders getting this wrong, or having
difficulty doing the right thing with libraries.

--- original comments on -13

(1) This could do with being rephrased. "Their identifiers, respectively the
conference XCON-URI and the conferencing client XCON-USERID, and their XML
representations compliant with the XML Schema defined in the XCON data model
are widely used for creating the CCMP requests and responses."

(2) The AUTO_GENERATE_X stuff on p12 seems complex - I don't think I really
followed the description and I wondered if it'd be easy to write code for this.
I'd suggest maybe looking at that text again to see if there's a way to make it
clearer for an implementer who hasn't been involved in the WG. 

(3) In 4.4, if a client's timer expires and it closes the connection, then
what, if anything, is the server supposed to do? E.g. if the request was ok and
the server has done an update but not yet sent the 200 response for some
reason. I think the server doesn't have to do anything (e.g. try to unwind the
update), but that'd be good to say.

(4) What is the limit of the xPathFilter mechanism? Could I use it to select
all the users or conferences with the password foo? Maybe there's some security
considerations text needed for that?

(Russ Housley) No Objection

(Pete Resnick) (was Discuss) No Objection

Comment (2011-05-25)
No email
send info
Intro to section 4:

   CCMP is a client-server, XML-based protocol, which has been
   specifically conceived to provide users with the necessary means for
   the creation, retrieval, modification and deletion of conference
   objects.  CCMP is also state-less, which means implementations can
   safely handle transactions independently from each other.
   Conference-related information is encapsulated into CCMP messages in
   the form of XML documents or XML document fragments compliant with
   the XCON data model representation.

That's a bit fluffy. How about instead:

   CCMP is a client-server, XML-based protocol for user creation,
   retrieval, modification and deletion of conference objects.  CCMP
   is a stateless protocol, such that implementations can safely
   handle transactions independently from each other.  CCMP messages 
   are XML documents or XML document fragments compliant with the
   XCON data model representation. [REF?]
   
See also use of the word "conceived" in the intro to 4 and in 5.3.1. Could tighten up the language there.

4.2 would be much easier to read if you stated the requirement (that responses with documents MUST have a version) first and then gave the explanation. Implementers don't need dramatic build-up. Get to the point. Then most of the explanation can be reduced.

4.4 first paragraph (or two; I can't tell if what spans the page break is 1 paragraph or two)
can be reduced to:

   CCMP is implemented using HTTP, placing the CCMP request messages into
   the body of an HTTP POST operation and placing the CCMP responses into
   the body of the HTTP response messages. For information as to why this
   implementation method was chosen, refer to Appendix A.

Then trim the second to last paragraph of 4.4 to get rid of redundancies.

5.3 Overall - I wouldn't mind seeing all of the XML *not* repeated here. It's already in section 11.

5.3 Intro - Move the discussion of optionsRequest/optionsResponse down to 5.3.12. No need to distinguish it here.

6 - I think this should either be in an appendix or in draft-ietf-xcon-examples.

(Dan Romascanu) No Objection

Comment (2011-05-26 for -)
No email
send info
The OPS-DIR review performed by Juergen Quittek raised a few issues and made a number of suggestions. None of them are critical, but in case the document is open to fix other issues I suggest to consider these ones as well: 

1) Section 2: Terminology
>    First-Party:   A request issued by the client to manipulate their own
>       conferencing data.
> 
>    Third-Party:   A request issued by a client to manipulate the
>       conference data of another client.

"First-Party" and "Third-Party" alone are not requests.
At least the term is not used this way in the draft.
Rather "third-party request" is used in the text for Referring to requests.
I would suggest:

NEW
   First-Party request:   A request issued by the client to
      manipulate their own conferencing data.

   Third-Party request:   A request issued by a client to
      manipulate the conference data of another client.


2) Section 3, third paragraph, 1st line:

OLD
   Conference object and conference users do represent key elements 

NEW
   Conference object and conference user objects do represent key elements

Implementation and operation of the protocol would become drastically simpler if the CCMP server would not be required anymore to create users. Just creating user objects would probably be sufficient already 

3) Section 3.2, 1st paragraph, lines 7-8 

OLD
   or a common administrator.  The Conference Control Server creates
   individual users, assigning them a unique Conference User Identifier 

NEW
   or a common administrator.  The Conference Control Server creates
   individual user objects, assigning them a unique Conference User
   Identifier


4) Section 4.1, 2nd paragraph

OLD
   create:  for the creation of a conference, a conference user, a
      sidebar, or a blueprint.

NEW
   create:  for the creation of a conference object, a conference
      user object, a sidebar, or a blueprint.


5) Section 4.3, item (b), line 2:

OLD
        in the request has (have) been replaced by the newly created 

NEW
        in the request have been replaced by the newly created


6) Section 5.3.4, paragraph after Figure 8, line 7:
What is "the referenced conference document"?
Is it the conference object?


7) Section 5.3.5, 1st paragraph, Last two lines:
Again "conference document", see issue 6)


8) Section 5.2.12, first bullet item, line two:
"ten standard message names"
It would be helpful to add a reference to Table 1.


9) Section 7, first lines:
>    If a conference control client is not pre-configured to use a
>    specific conference control server for the requests, the client MUST
>    first discover the conference control server before it can send any
>    requests.
Is this really a capital "MUST"? Would the client be able to send any request before discovering the server?

(Peter Saint-Andre) (was Discuss) No Objection

Comment (2011-05-25)
No email
send info
1. Section 4 states:

   The conference
   server must ensure that the operations are atomic in that the
   operation invoked by a specific conference client completes prior to
   another client's operation on the same conference object.

Change "must" to "MUST"?

2. Also in Section 4:

   The specification recommends the use of HTTP as
   a transport solution...

Change to the following?

   Implementations SHOULD use HTTP as the transport...

3. In Section 4.2:

   The "version" parameter is not REQUIRED for requests...

There is no "not REQUIRED" in RFC 2119. I suggest:

   The "version" parameter is OPTIONAL for requests...

4. In Section 5, the terms "mandatory" and "optional" are used for the
various parameters. Using RFC 2119 language, are these really "REQUIRED"
and "OPTIONAL"?

5. The table in Section 5.4 has bad line breaks. I suggest changing this:

   +---------------+------------+------------+------------+------------+
   | Response code | Create     | Retrieve   | Update     | Delete     |
   +---------------+------------+------------+------------+------------+

to this:

   +----------+-------------+-------------+-------------+-------------+
   | Response | Create      | Retrieve    | Update      | Delete      |
   | Code     |             |             |             |             |
   +----------+-------------+-------------+-------------+-------------+

or even to this:

   +------+--------------+--------------+--------------+--------------+
   | Code | Create       | Retrieve     | Update       | Delete       |
   +------+--------------+--------------+--------------+--------------+

That will give you more room in each column.

6. Various examples have "form the server" instead of "from the server".

7. In schema snippet from Section 6.9, the example extension does not 
specify an XML namespace, implying that the extension is qualified by 
the base namespace. This would be wrong. The examples are right, here.

8. Section 9 states:

   A conferencing client that conforms to this specification is not
   required to support HTTP authentication [RFC2617] or cookies
   [RFC6265].

There is no "not required" in RFC 2119. Do you mean that it is OPTIONAL 
for a conferencing server to support RFC 2617 and RFC 6265?

9. In Section 10.4, please add an informational reference to RFC 4732.

(Sean Turner) (was Discuss) No Objection

Comment (2011-07-27)
No email
send info
#1) addressed

#2) addressed

#3) addressed

#4) addressed

#5) Sec 10.1 - A reference to RFC 6125 is needed to ensure the server's ID is properly checked.

[MB] Are you suggesting that we change the following sentence to something like the following?
 OLD: 
   Note that in order for the
   presented certificate to be valid at the client, the client must be
   able to validate the certificate. 
 NEW:
   Note that in order for the
   presented certificate to be valid at the client, the client must be
   able to validate the certificate, using a mechansim such as that specified in RFC 6125.
[/MB]

[spt] this or a pointer to 2818.