Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Mon, 22 Mar 2010 11:45:58 -0000

Hi All,
 I am aware that this draft is nearing completion so I have listed all
my outstanding issues in this email.
 
 1. If one wanted to move a user from one conference to another, how
could this be achieved via CCMP? It could be done with 
a userRequest of Type CREATE on the new conference supplying the userID
of the existing user, with the password of the user's
existing conference. The password of the new target conference would
also be required which could be stuffed into the request's any
field... It would good to get other people's opinion this....
 
2. Need clarification on the CCMP operations to move a user from a
parent conference to one of its sidebars and back again. 
Simple example side related examples should be provided.
 
3. CCMP response codes:-
3.1 How does a server indicate to a client that it does not support the
setting of a XML element(s). i.e the request is a valid XML
request but part of it cannot be set...
3.2 We need an ObjectAlreadyExists response code to indicate to a client
if it attempts to create an object with an entity that already exists.
e.g. an attempt to create a user that already exists in the system.
3.3 We need a response code when the CCMP server cannot execute a
command because of resource issues. E.g. CCMP server cannot create a sub
conference 
because the system has reached its limits on the no. of sub conferences,
or if the addUser request fails because the max number of users has been
reached for the conference or the max number of users has been reached
for the conferencing system... 
Maybe a  resourcesNotAvailable response code?
 
4. General CCMP comment:- I am wondering if the CCMP request XML could
be reduced/simplified. E.g. 
 
 <xs:complexType name="ccmp-blueprint-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintRequest" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>
 
   <!-- blueprintRequestType -->
 
   <xs:element name="blueprintRequest" type="blueprintRequestType" />
 
   <xs:complexType name="blueprintRequestType">
       <xs:sequence>
           <xs:element name="blueprintInfo"
                       type="info:conference-type" minOccurs="0"/>
           <xs:any namespace="##other" processContents="lax"
                   minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
       <xs:anyAttribute namespace="##any" processContents="lax"/>
   </xs:complexType>
   
 could this request be represented also as follows:
 
  <xs:complexType name="ccmp-blueprint-request-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-request-message-type">
  <xs:sequence>
      <xs:element name="blueprintInfo"
    type="info:conference-type" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax"
       minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
         <xs:anyAttribute namespace="##any" processContents="lax"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
The same pattern could be applied to the other requests and the
responses also...
 
5. Also it might be an idea to facilitate the possibility of specifying
new requests. The CCMP xsd could expose another Request/Response pair to
faciliate this e.g.
 
        <xs:complexType name="ccmp-extended-request-message-type">
          <xs:complexContent>
            <xs:extension base="tns:ccmp-request-message-type">
              <xs:sequence>
                <xs:any namespace="##other" processContents="lax"
           minOccurs="0" maxOccurs="unbounded"/>
              </xs:sequence>
              </xs:extension>
          </xs:complexContent>
        </xs:complexType>
 
 <xs:complexType name="ccmp-extended-response-message-type">
          <xs:complexContent>
            <xs:extension base="tns:ccmp-response-message-type">
              <xs:sequence>
                <xs:any namespace="##other" processContents="lax"
           minOccurs="0" maxOccurs="unbounded"/>
              </xs:sequence>
            </xs:extension>
          </xs:complexContent>
        </xs:complexType>
 
Or what should implementors do if they want to expose requests other
than those in the CCMP draft?
 
6. I mentioned a while back that 100% support of all XPATH filters could
be problematic for implementors, specifically 
in relation to peformance. I think it might be worth indicating that
implementors may support only a set of documented XPATH filters....
 
7. I mentioned a while back that it would be very useful to allow
conference cloning requests to also contain a conference doc that
contains
specific modications required to the cloned conference like new
conference name. This would avoid having to send a seperate update and
would 
guarantee that clients get what they want in one server transaction. 
 
8. The examples in the ccmp draft and the examples draft should contain
references to the new <subject> element.
 
Regards 
Sean