Subject: [XCON] Comments on draft-levin-xcon-cccp-03

From: "Morgan, Dave" <[email-masked]>
Date: Tue, 1 Nov 2005 17:08:48 -0500

Orit, Roni, and Pierre, here's my comments on your draft 

1.	I like how the four "operations" "add", "modify", "delete" and
"get" are used for each element.  Is it the case that "add", "modify"
and "delete" acting on the element can return the response codes you
describe, while "get" returns a response code and the desired XML code?
Along that line, I'm wondering why the addconference response in 6.2.1
returned the XML code in the request.  Also I see in 6.5.1 that
addEndpointMedia can return a new value for the "media-id."  So is it
the case that any request can have XML code returned in the
corresponding response?

2.	What you propose for system primitives works well.  I can
envision how "gettemplates" returns the data model of the conference
with all the elements listed.  These are in turn the elements that the
control protocol can successfully manipulate with the four operations.
Operations on all other elements not listed in the template (or
conference object in general) should return a failure.  Is that how you
envision it to work?

3.	Do you think the client should be able to change all if not most
of the conference elements defined in the conference object?  I think
that is a reasonable expectation.  If that's the case, then the number
of transactions you have to define is going to be very large.  For
example, in addition to what you've defined you could have the following
requests: "modifycodec", "getmaximum-user-count", addsecurity-level",
"modifylayout", modifyallow-conference-state", etc.  It would be nice to
separate the operations from the element (such as <modify codec/>) so
that coding for the permutations does not overwhelm the client.  But I
can't think of a way to do that and transmit well-formed XML in the
request.  How are you planning to address all the permutations?

4.	Do you intend to say anything about the CCCP server in this
draft?  Are you going to talk about how the server can have data access
rights to manipulate the values of the elements in the conference
object?  When Oscar and I discussed data access rights we agreed on two
things, that the manipulation would be based on the roles, and that the
elements should have attributes of "read-write" and "read-only"
(although we were hoping to see some comments/suggestions on the mailing
list on the mechanism for specifying the "privileges-control-list").  So
perhaps when the CCCP request comes in from a client, the CCCP server
(which I assume knows the role of the entity on that client) can examine
the conference object and determine if the operation succeeds.   For
example, if the entity is a "moderator" and the request is to
"modifyallow-sidebars" and <allow-sidebars read-only="moderator"
read-write="creator"/> is set in the conference object then the
operation should return a failure with a reason code for "unauthorized."

5.	Section 6.1.1, Cancel:  Why did you use "MCU" in the example
request to=https://Mcu55.company.com:444/MCU?  Aren't you communicating
with the CCCP server as you describe it in 6.4.1?

6.	Section 6.3.3, modifyUserRoles:  We need to get on the same page
with respect to user roles.  I see a "user-roles-type" in
sipping-conference-package-12 but not a "user-roles" defined (ah, I
found it in xcon-conference-package-ext-00).  In xcon-media-template-03
and xcon-roles-00 we used "role-type" instead of "user-roles-type."

Dave

------------------------------------------------------------------------

David P. Morgan, PhD 
VP, Architecture & Planning 
Fidelity Investments Systems Company - Telecom 
Phone:  617 563-2178 
Fax:      617 385 2122 
Mailing: 82 Devonshire St, MZ V8C 
            Boston, MA 02109-3614 
Office:   245 Summer Street, 8th Floor 

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Orit Levin" <[email-masked]>
Date: Tue, 1 Nov 2005 16:45:36 -0800

Dave,
Thank you very much for your comments!

My answers are inline. I think that my co-authors will be able to provide additional insights including their experience with older conference control protocols implementation.

Orit.

________________________________________
From: Morgan, Dave [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:09 PM
To: Orit Levin; Even, Roni
Cc: XCON
Subject: Comments on draft-levin-xcon-cccp-03

1. I like how the four "operations" "add", "modify", "delete" and "get" are used for each element.  Is it the case that "add", "modify" and "delete" acting on the element can return the response codes you describe, while "get" returns a response code and the desired XML code?  Along that line, I'm wondering why the addconference response in 6.2.1 returned the XML code in the request.  Also I see in 6.5.1 that addEndpointMedia can return a new value for the "media-id."  So is it the case that any request can have XML code returned in the corresponding response?

OL: Every response MUST include the code on the CCCP response level. Additionally, every primitive can define in XML a set of its own specific response codes (and additional data). In the current XML schema, all the primitives have their own codes defined, but they are optional and therefore are not used in all the examples.

BTW, note also that most of the responses can optionally carry the resultant XML data just for feedback. It is not required, though, because in the success case, the resultant XML should be obvious to the CCCP client.

2. What you propose for system primitives works well.  I can envision how "gettemplates" returns the data model of the conference with all the elements listed.  These are in turn the elements that the control protocol can successfully manipulate with the four operations.  Operations on all other elements not listed in the template (or conference object in general) should return a failure.  Is that how you envision it to work?

OL: Every implemented primitive must first be defined in the CCCP XML. Possible primitives are not restricted to add/modify/delete/get only. There is an explicit moveUserToSidebar() primitive, as an example. CCCP Server can choose to support just a subset of primitives. If the protocol takes off in the IETF, we will need to add the getSupportedPrimitives() primitive...

3. Do you think the client should be able to change all if not most of the conference elements defined in the conference object?  I think that is a reasonable expectation.  If that's the case, then the number of transactions you have to define is going to be very large.  For example, in addition to what you've defined you could have the following requests: "modifycodec", "getmaximum-user-count", addsecurity-level", "modifylayout", modifyallow-conference-state", etc.  It would be nice to separate the operations from the element (such as <modify codec/>) so that coding for the permutations does not overwhelm the client.  But I can't think of a way to do that and transmit well-formed XML in the request.  How are you planning to address all the permutations?

OL: No, no. The main objects (conference, user, endpoint, ...) need to be accessed explicitly. The most frequently used objects makes sense to update directly too. The modifyUserRoles() primitive is used to illustrate this. Rather than that, I think that most of the information will be accessed and modified through their parent objects. The "modify" request carries a "partial" information - i.e. just the information to be modified. 

4. Do you intend to say anything about the CCCP server in this draft?  Are you going to talk about how the server can have data access rights to manipulate the values of the elements in the conference object?  When Oscar and I discussed data access rights we agreed on two things, that the manipulation would be based on the roles, and that the elements should have attributes of "read-write" and "read-only" (although we were hoping to see some comments/suggestions on the mailing list on the mechanism for specifying the "privileges-control-list").  So perhaps when the CCCP request comes in from a client, the CCCP server (which I assume knows the role of the entity on that client) can examine the conference object and determine if the operation succeeds.   For example, if the entity is a "moderator" and the request is to "modifyallow-sidebars" and <allow-sidebars read-only="moderator" read-write="creator"/> is set in the conference object then the operation should return a failure with a reason code for "unauthorized."

OL: As above, this draft shows the direction in its raw form. If XCON likes it, we will definitely need to add the access control definitions.

5. Section 6.1.1, Cancel:  Why did you use "MCU" in the example request to=https://Mcu55.company.com:444/MCU?  Aren't you communicating with the CCCP server as you describe it in 6.4.1?

OL: The MCU runs the CCCP server inside :-) but it is a good idea to make the example simpler and more explicit.

6. Section 6.3.3, modifyUserRoles:  We need to get on the same page with respect to user roles.  I see a "user-roles-type" in sipping-conference-package-12 but not a "user-roles" defined (ah, I found it in xcon-conference-package-ext-00).  In xcon-media-template-03 and xcon-roles-00 we used "role-type" instead of "user-roles-type."

OL: Yes, I agree. (and I will check the XML syntax.)

Dave