[XCON] AD review: draft-ietf-xcon-ccmp-10

[Robert Sparks <[e-mail]>]

Summary: There are some minor issues to address before moving to IETF LC.

This is a good document - it was very easy to read. Thanks to all who worked
to get it into the shape it's in.

Administrative:
* Please send a request to type-review for application/ccmp+xml.

* I would like the writeup to name who verified the schema and examples 
  (and what tool they used). How did the reviewer ensure the snippets of 
  schema in the sections that describe various elements exactly matches 
  the full schema listed in section 11?

Technical:

* Is there any text that prevents a ccmp request from being empty?
  (all of the elements in the schema have minOccurs="0"). If not,
  either some should be added, or the text should say something 
  about how a server should react to a request built this way.

* The AUTO_GENERATE mechanism's definition is currently hard to find,
  (it's at the end of 4.1), and easy to miss that it's a normative
  requirement on server behavior. (I couldn't find the place where
  the behavior was defined for my first several reads of this document).
  This behavior should be defined with 2119 terms. What definition
  exists in this section requires the wildcard to have the form of
  AUTO_GENERATE_X, but there are several examples and places in the text
  (here and in the examples document), particularly for xcon-userid:
  constructs where AUTO_GENERATE appears without the _X.

* The draft calls out "first party" and "third party" actions, but doesn't
  define those terms.

* The document should call out why <standard-message-list> and
  <extended-message-list> were separated, and what makes that separation
  useful. What will an implementation do differently if a message name 
  it doesn't understand shows up in a <standard-message-list> vs in an 
  <extended-message-list>?

* Can you add a note explaining that the server chooses the contents 
  of the URI when it creates a conference or user? The examples for 
  creating users, such as 6.7, imply that some bits (Ciccio in this case) 
  are copied from the request's userInfo into the response's userInfo 
  AUTO_GENERATEd URI. While a server might choose to do something like 
  that, it's not required to.

* It should be more clearly stated in 6.9 that the "confSummaryRequest" 
  is hypothetical and is not actually being defined.

* The URL sub-namespace registration html is not well formed
  (There's a spurious <a/>).

* Is there a privacy leak with cloning existing conferences? What text
  prevents any member from cloning the conference to see who is in what
  sidebar? Was the intent to not allow cloning of conferences that are
  in progress?

* The security considerations section should call out that most CCMP commands
  can pend indefinitely - clients need to be ready to wait an arbitrary amount
  of time to get the response (see section 6.3 of xcon-examples and consider
  Alice not responding and the IVR not timing out, Alice using an automaton 
  to keep the IVR from completing its script when it did have timeout protection,
  etc. The document should say what a client should do when it is no longer
  willing to wait (close the underlying connection?), and point out what 
  servers can do if they have lots of pending requests starting to pile up.