Centralized Conferencing Manipulation Protocol
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 -)
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
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
--- 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
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 -)
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
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
#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.