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

From: [email-masked]
Date: Mon, 26 Apr 2010 11:58:34 +0200

Hi Sean,

please find in-line ([SIMON]) my answers to your comments and suggestions.

> 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....

[SIMON]
Let us first suppose we have a "registered" conferencing client,  
characterized by:

    * xcon-userid: xcon:[email-masked]
    * username: pippozzo
    * password: 131313

The system presumably keeps track of at least a signaling URI for such  
user, since he already participates in a conference. This means that  
join requests can avoid to bring a "userInfo" parameter (unless we  
want to update the list of URIs associated with the user's  
xcon-userid). We can have the following cases:

    **** case 1: entering a non password protected conference

    inside the userRequest/create we only need the following parameters:

    * confUserID = xcon-userid:[email-masked]
    * confObjID of the conference we wish to join
    * operation = create

   **** case 2: entering a password protected conference( as in par.  
7.5 of draft-ietf-xcon-examples-03 online)

    inside the userRequest/create we need the following parameters:

    * confUserID = xcon-userid:[email-masked]
    * confObjID of the conference we wish to join
    * operation = create
    * conference-password = password associated with the conference  
with id equal to confObjID

   *** case 3: user authentication required by the system before  
entering a password protected conference

    inside the userRequest/create:

    * subject:  username = pippozzo, password = 131313
    * confUserID = xcon-userid:[email-masked]
    * confObjID of the conference we wish to join
    * operation = create
    * conference-password = password of the conference we wish to join

>
> 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.

[SIMON] I don't see any particular issue here. We have the following  
scenarios:

    **** a) a user wants to exit the main conference and join a  
sidebar; then, he wants to go back to the main conference (while  
leaving the sidebar).

    We need 4 messages:

    * 1) userRequest/delete from the main conference
    * 2) userRequest/create on the sidebar
    * 3) userRequest/delete from the sidebar
    * 4) userRequest/create on the main conference

    **** b) a user wants to enter a sidebar while keeping on  
participating in the main conference (i.e. he will also appear in the  
roster of the main conference). Then, he wants to leave the previously  
joined sidebar.

    We need 2 messages:

    * 1) userRequest/create on the sidebar
    * 2) userRequest/delete from the sidebar (when he wants to leave it).

>
> 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?

[SIMON] As to response codes, we completely restructured the way they  
are defined. We moved to IETF-style 3-digit codes, which have been  
defined like this in the schema:

	<!-- New definition in schema version 07 -->
	<xs:simpleType name="response-codeType">
		<xsd:restriction base="xsd:positiveInteger">
			<xsd:pattern value="[0-9][0-9][0-9]" />
		</xsd:restriction>
	</xs:simpleType>

The current list of codes is as follows:

    200 Success:  Successful completion of the requested operation.
    400 Bad Request:  Syntactically malformed request.
    401 Unauthorized:  User not allowed to perform the required
       operation.
    403 Forbidden:  Operation not allowed (e.g., cancellation of a
       blueprint).
    404 Object Not Found:  Target conference object missing at the server
       (it refers to the "confObjID" parameter in the generic request
       message)
    409 Conflict:  A generic error associated with all those situations
       in which a requested client operation cannot be successfully
       completed by the server.  An example of such situation is when the
       modification of an object cannot be applied due to conflicts
       arising at the server's side, e.g. because the client version of
       the object is an obsolete one and the requested modifications
       collide with the up-to-date state of the object stored at the
       server.  Such code would also be used if a client attempts to
       create an object (conference or user) with an entity that already
       exists.
    420 User Not Found:  Target user missing at the server (it is related
       to the XCON-USERID in the "entity" attribute of the "userInfo"
       parameter when it is included in userRequests)
    421 Invalid confUserID:  User missing at the server (this code is
       returned in the case of requests in which the "confUserID" of the
       sender is invalid).
    422 Invalid Conference Password:  Target conference object's password
       contained in the request is wrong.
    423 Conference Password Required:  "conference-password" missing in a
       request to access a password-protected conference object.
    424 Authentication Required:  User's authentication information
       missing in a request to perform the requested operation. "subject"
       parameter needed in the request.
    425 Forbidden Delete Parent:  Cancel operation failed since the
       target object is a parent of child objects which depend on it, or
       because it effects, based on the "parent-enforceable" mechanism,
       the corresponding element in a child object.
    426 Forbidden Change Protected:  Update refused by the server because
       the target element cannot be modified due to its implicit
       dependence on the value of a parent object ("parent-enforceable"
       mechanism).
    500 Server Internal Error:  The server cannot complete the required
       service due to a system internal error.
    501 Not Implemented:  Operation envisaged in the protocol, but not
       implemented in the contacted server.
    510 Request Timeout:  The time required to serve the request has
       exceeded the envisaged service threshold.
    511 Resources Not Available:  This code is used when the CCMP server
       cannot execute a command because of resource issues, e.g. it
       cannot create a sub conference because the system has reached its
       limits on the number of sub conferences, or if a request for
       adding a new user 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.

As you will notice, code 511 has been introduced based on your  
suggestion in 3.3 above. 3.2 belongs in the 409 ("Conflict") category.  
As to 3.1, I think it might fall in the  501 ("Not Implemented)"  
category, if the case is that of a "valid" request which cannot be  
satisfied by the server because it either does not modify certain  
'standard' parameters of the conf document or does not recognize  
'special' elements which are there beacuse of the "any" in the schema.
In case the problem is instead due to the lack of resources at the  
server side, then the newly introduced 511 (Resources Not Available)  
can do the job.

What do you think about this?

>
> 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...

[SIMON] I personally find the current structure more readable. Though,  
I'm open to change the current schema if people see it fit.

>
> 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?

[SIMON] Totally agreed. We added your proposal to the CCMP schema.

>
> 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....

[SIMON] I think we already discussed this point. I'm cutting and  
pasting Richard Barnes' answer from an e-mail of January 25th 2010:

********************************************************************
    "It's not clear to me how using a subset of XPath queries creates
any benefit here.  There
are several XPath libraries out there that cover the complete spec, so
it's not hard for
CCMP implementations can get full XPath by using one of them.  And the
alternatives seem
undesirable, e.g., matching against fixed XPath literals or hacking up
some incomplete
implementation of XPath.

I would recommend leaving the document as-is.

Richard Barnes"
**********************************************************************

>
> 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.

[SIMON] In the draft we currently write:

****************************************************************************
  The creation case deserves care. To create a new conference through  
a "confRequest" message, two approaches can be considered:

    1. Creation through explicit cloning: the "confObjID" parameter  
MUST contain the XCON-URI of the blueprint or of the conference to be  
cloned, while the "confInfo" parameter MUST NOT be included in the  
confRequest;
    2. Creation through implicit cloning (also known as "direct  
creation"): the "confObjID" parameter MUST NOT be included in the  
request and the CCMP client can describe the desired conference to be  
created using the "confInfo" parameter. If no "confInfo" parameter is  
provided in the request, the new conference will be created as a clone  
of the system default blueprint.
******************************************************************************

I think you are suggesting to remove the sentence with "MUST NOT" from  
the first paragraph (associated with case 1. in the draft). It was our  
intention to somehow "drive" the clone-based creation of a conference  
through lean and mean operations: you first obtain a clone of the  
parent conference and then you modify it through subsequent update  
operations. Here again, we are open to change this in the document if  
others deem it worth.

>
> 8. The examples in the ccmp draft and the examples draft should contain
> references to the new <subject> element.

[SIMON] This has already been done. What we have to mdify there (if  
the WG agrees on their new definitions) are the response-codes in the  
dumps.

> Regards
> Sean

[SIMON] Thank you once again for your invaluable feedback!

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Mon, 26 Apr 2010 12:15:24 +0100

Hi Simon,
	Thanks very much for sticking with me on this ... 
See below:-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 26 April 2010 10:59
To: Duddy, Sean (Sean)
Cc: [email-masked]; [email-masked]
Subject: Re: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt

Hi Sean,

> 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....

[SIMON]
Let us first suppose we have a "registered" conferencing client, characterized by:

The system presumably keeps track of at least a signaling URI for such user, since he already participates in a conference. This means that join requests can avoid to bring a "userInfo" parameter (unless we want to update the list of URIs associated with the user's xcon-userid). We can have the following cases:

    * confUserID = xcon-userid:[email-masked]
    * confObjID of the conference we wish to join
    * operation = create
    * conference-password = password associated with the conference with id equal to confObjID

   *** case 3: user authentication required by the system before entering a password protected conference

[SEAN] The thing is if I am moderator of my conference and I want xcon-userid:[email-masked] to join it, I could send
the above cmd and xcon-userid:[email-masked] would be placed in it without having knowledge of the moderator passcode of 
xcon-userid:[email-masked]'s existing conference? I think the cmd needs to have both passcodes...

    **** a) a user wants to exit the main conference and join a sidebar; then, he wants to go back to the main conference (while leaving the sidebar).

    We need 4 messages:

    * 1) userRequest/delete from the main conference
[SEAN] How does the server know that the client wants the user to enter a sidebar as opposed to just deleting the user from the main conference?
    * 2) userRequest/create on the sidebar
    * 3) userRequest/delete from the sidebar
[SEAN] How does the server know that the client wants the user to join back in to the main conference as opposed to just deleting the user from the sidebar conference?
    * 4) userRequest/create on the main conference

    **** b) a user wants to enter a sidebar while keeping on participating in the main conference (i.e. he will also appear in the roster of the main conference). Then, he wants to leave the previously joined sidebar.

    We need 2 messages:

>
> 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 
> 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.
> 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...

[SIMON] As to response codes, we completely restructured the way they are defined. We moved to IETF-style 3-digit codes, which have been defined like this in the schema:

As you will notice, code 511 has been introduced based on your suggestion in 3.3 above. 3.2 belongs in the 409 ("Conflict") category.  
As to 3.1, I think it might fall in the  501 ("Not Implemented)"  
category, if the case is that of a "valid" request which cannot be satisfied by the server because it either does not modify certain 'standard' parameters of the conf document or does not recognize 'special' elements which are there beacuse of the "any" in the schema.
In case the problem is instead due to the lack of resources at the server side, then the newly introduced 511 (Resources Not Available) can do the job.

What do you think about this?
[SEAN] sounds good to me.

> The same pattern could be applied to the other requests and the 

[SIMON] I personally find the current structure more readable. Though, I'm open to change the current schema if people see it fit.

[SEAN] thanks

Richard Barnes"
[SEAN] OK

I think you are suggesting to remove the sentence with "MUST NOT" from  
the first paragraph (associated with case 1. in the draft). It was our  
intention to somehow "drive" the clone-based creation of a conference  
through lean and mean operations: you first obtain a clone of the  
parent conference and then you modify it through subsequent update  
operations. Here again, we are open to change this in the document if  
others deem it worth.
[SEAN] Lean and mean operations are a desirable goal but also we should try to limit the number of requests
A client has to send. The clone operation is a very quick way to get conferences created but I
Do believe adding the ability to overide params in the clone operation via the confInfo param enhances the 
Clone operation

Simon

---

From: [email-masked]
Date: Mon, 26 Apr 2010 20:10:45 +0200

Hi Sean,

here we go again ;-). See [SIMON] in-line.

> [SEAN] The thing is if I am moderator of my conference and I want   
> xcon-userid:[email-masked] to join it, I could send
> the above cmd and xcon-userid:[email-masked] would be placed   
> in it without having knowledge of the moderator passcode of

[SIMON] Let's say Alice is the moderator (on the conference control  
plane) of a
password-protected conference, "alice_conf_", and Bob is the new  
conferencing client Alice wants to add to her conference. It is not  
relevant to Alice whether Bob is involved in another conference or  
not. If Alice wants Bob to join her conference, she has just to send  
the following userRequest/create:

   * subject : username = alice, password = alice_personal_pwd
   * confUserID = xcon-userid:[email-masked]
   * confObjID = xcon:[email-masked]
   * operation = create
   * conference-password = alice_conf_pwd
   * userInfo = <userInfo entity="xcon-userid:[email-masked]"/>

Now, let us suppose that Alice knows that Bob is currently involved in another
password-protected conference, "conf_2_", and that she wants Bob to  
leave that conference before joining her own conference. If Alice is  
aware of the conf_2_ conference-password ("conf_2_pwd") and the  
conferencing system allows she to perform this kind of action, Alice  
can send the following userRequest/delete message before the  
userRequest/create one:

   * subject : username = alice, password = alice_personal_pwd
   * confUserID = xcon-userid:[email-masked]
   * confObjID = xcon:[email-masked]
   * operation = delete
   * conference-password = conf_2_pwd
   * userInfo = <userInfo entity="xcon-userid:[email-masked]"/>

Does this clarify this issue? Or am I mistaking your concern?

> [SEAN] How does the server know that the client wants the user to   
> enter a sidebar as opposed to just deleting the user from the main   
> conference?
> [SEAN] How does the server know that the client wants the user to   
> join back in to the main conference as opposed to just deleting the   
> user from the sidebar conference?

[SIMON] Since CCMP is a state-less protocol, each operation is  
independent from the others. Hence, the server doesn't care about  
user's future actions when performing the requested operation. If you  
want that only the main conference participants can share a private  
sidebar conversation (leaving the main one) and then be allowed to  
re-join the main conference, you can't leverage CCMP to implement this  
kind of mechanism, but rather you can configure an appropriate policy  
mechanism exploiting, for example, the allowed-users-list of the two  
conferences (which is out of the scope of the protocol design). For  
example, you can envisage that, when creating an internal sidebar, in  
the sidebar allowed-users-list only the main conference participants  
appear (i.e. they are the only ones who are allowed to join), and  
that, even if a main conference user leaves the main conference,  
his/her name remains on the main conference allowed-users-list in  
order to accept that user if he/she wants to come back again (and also  
to allow for his/her participation in a possible future internal  
sidebar).

> [SEAN] Lean and mean operations are a desirable goal but also we   
> should try to limit the number of requests
> Do believe adding the ability to overide params in the clone   
> operation via the confInfo param enhances the
> Clone operation

[SIMON] OK. If you keep on stating this, it means you definitely need  
such functionality ;-). I'll change the paragraph in question in the  
very next version of the document (which will be uploaded as soon as  
we converge on the other issues and collect some more feedback from  
the WG...).

Cheers,

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 27 Apr 2010 11:10:57 +0100

Hi Simon,
	See below. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 26 April 2010 19:11
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: RE: [XCON] I-D Action:draft-ietf-xcon-ccmp-06.txt

Hi Sean,

[SIMON] Let's say Alice is the moderator (on the conference control
plane) of a
password-protected conference, "alice_conf_", and Bob is the new conferencing client Alice wants to add to her conference. It is not relevant to Alice whether Bob is involved in another conference or not. If Alice wants Bob to join her conference, she has just to send the following userRequest/create:

[SEAN] OK if Bob is not involved in another conference then there is no issue

Now, let us suppose that Alice knows that Bob is currently involved in another password-protected conference, "conf_2_", and that she wants Bob to leave that conference before joining her own conference. If Alice is aware of the conf_2_ conference-password ("conf_2_pwd") and the conferencing system allows she to perform this kind of action, Alice can send the following userRequest/delete message before the userRequest/create one:

Does this clarify this issue? Or am I mistaking your concern?
[SEAN] the issue here is that the delete will disconnect Bob's call and then the create will restablish his call with the new conference.
The behaviour I am looking for is that Bob get moved to another conference without any disconnection and reconnection 

> user from the sidebar conference?

[SIMON] Since CCMP is a state-less protocol, each operation is independent from the others. Hence, the server doesn't care about user's future actions when performing the requested operation. If you want that only the main conference participants can share a private sidebar conversation (leaving the main one) and then be allowed to re-join the main conference, you can't leverage CCMP to implement this kind of mechanism, but rather you can configure an appropriate policy mechanism exploiting, for example, the allowed-users-list of the two conferences (which is out of the scope of the protocol design). For example, you can envisage that, when creating an internal sidebar, in the sidebar allowed-users-list only the main conference participants appear (i.e. they are the only ones who are allowed to join), and that, even if a main conference user leaves the main conference, his/her name remains on the main conference allowed-users-list in order to accept that user if he/she wants to come back again (and also to allow for his/her participation in a possible future internal sidebar).
[SEAN] I don't think this clears my issue up.  My basic use case is I want to move particpants from main conference to sidebar without disconnection of their call and then back to the main conference again. 
Your original call flow was:-

The first delete will disconnect the user from the conferencing bridge which is not what I want. 

> should try to limit the number of requests A client has to send. The 
> clone operation is a very quick way to get  conferences created but I
> operation via the confInfo param enhances the Clone operation

[SIMON] OK. If you keep on stating this, it means you definitely need such functionality ;-). I'll change the paragraph in question in the very next version of the document (which will be uploaded as soon as we converge on the other issues and collect some more feedback from the WG...).
[SEAN] Thanks very much.
Cheers,

Simon