Subject: [XCON] Comments on draft-ietf-xcon-ccmp-05

From: Alan Johnston <[email-masked]>
Date: Sat, 16 Jan 2010 16:36:52 -0600

I have no technical issues in the draft.  All these comments are 
editorial in nature.

Overall, I am very happy with the draft and think it is ready to 
progress.  Good job to everyone who has worked so hard over the years on 
this, our core XCON protocol.

- Alan -
(as individual)

Abstract:

It would be nice if the Abstract mentions that this document defines a 
new sub-URN, an XML schema, a MIME type, and DNS NAPTR extensions.

The phrase "the CCMP" appears in a lot of places.  Usually, we only use 
"the" when spelling out the whole name (i.e. "the Centralized 
Conferencing Manipulation Protocol") - otherwise, drop the article and 
just say "CCMP".

1. Introduction:

"Operations on conferences
   include adding and removing participants, changing their roles, as
   well as adding and removing media streams and associated end points."

change to:

"Operations on conferences
   include adding and removing participants, changing the roles of 
participants, as
   well as adding and removing media streams and associated end points."

4.1 Conference Objects:

It would be nice to reference the data model when the XCON-URI is first 
mentioned so the reader knows where this is defined.

4.2 Conference Users

"provides a mean" -> "provides a means"

5. Protocol Overview:

This section is called the overview, but it is actually the formal 
definition of the protocol, as 5.1 has the first normative statement.  
I'm OK with keeping the section name, but it might be worth saying this 
is where the protocol is normatively defined.

"state-less" -> "stateless"

6.1 CCMP Request Message Type

"This is specialization" -> "This is a specialization"

Table 1:

This table needs a few minor formatting.  One heading reads  "-Request 
Type" which I presume should be just "Request Type"  Also the element 
"Gets sidebars-by-val element" and "Gets sidebars-by-ref element" has 
some weird formatting.

6.3.6. userRequest and userResponse

"like creating a conference" -> "such as creating a conference"

The example:

"   Request fields:

   confUserID=null;
   confObjID=confXYZ;
   operation=create;
   userInfo=

   <userInfo entity=null>
           <endpoint entity="sip:GHIL345@blablabla">
           ...

   Response fields (in case of success):

   confUserID=user345;
   confObjID=confXYZ;
   operation=create;
   response-code=success;
   userInfo=null; //or the entire userInfo object"

I'm not sure why this is not in XML - is there a reason?  If so, I'd 
suggest explaining.  If not, I'd suggest making it XML like the rest of 
the examples.

Table 2:

This table also has a few formatting nits.  The wrapping of single 
characters ("d" and "t") looks like it could be avoided.  The item with 
"3rd party invite with third user entity" has some very confusing 
formatting - I'm also not sure I know exactly that that means.

7. A complete example of CCMP in action

It might be worth stating that this example is non-normative.

7.1

"           <info:purpose>Simple Room:
              conference room with public access,
              where only audio is available, more users
              can talk at the same time
              and the requests for the AudioFloor
              are automatically accepted.
           </info:purpose>"

should "more users" be "multiple users"?  If not, make it clear what is 
meant.

7.5

"                     <xcon:target method="refer"
                                  uri="tel:+390817683823"/>"

Can a REFER be sent to a tel URI?  Or am I mistaking the meaning here?

7.6

"Notice that such element includes
   information about the user's Address of Records, as well as her
   current end-point. "

Do you really mean AORs or do you just mean AOR?  Does having a single 
user have multiple AORs have any security/authentication issues?

8. Locating a Conference Control Server

This section probably should reference RFC 3958 somewhere the first time 
U-NAPTR is mentioned.

13.1 URN Sub-Namespace Registration

Should the URN have double double quotes?

15. Changes Since Last Version

I'd suggest deleting this in the next version.

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Wed, 20 Jan 2010 23:26:03 -0000

Hi All,
	Some more comments:-

1. What is the expected behaviour of a CCMP server when a client
attempts to create a conference via implicit cloning, and the supplied
xcon URI (via the entity attribute) already exists on the server side? I
am thinking we should have another ResponseCode of
'objectAlreadyExists'.
BTW: In the CCMP examples - "Create Basic Conference from user provided
conference-info", the xml is missing the mandatory entity attribute.

I would imagine most CCMP servers would generate the XCON URI, so do we
need to define a default XCON URI to indicate to the server that it must
generate one?

2. The 'blueprintInfo' element needs to have a minOccurs="0" to allow
for responses that may not have a info:conference-type element e.g. for
blueprint delete, or for blueprint operations that have returned in
error.
The same applies for 'confInfo' element. There are probably other
response elements that require this change also...

Regards
Sean

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Thu, 21 Jan 2010 10:35:51 -0000

Hi All,
	I would like some clarification on the use of the
<cloning-parent> element with the CCMP protocol.
My understanding is that this element is not returned in confResponse
where a conference is cloned from a blueprint. Is that correct?

What if I want to clone an existing conference? Would the
<cloning-parent> element be returned in the confResponse?

If a conference has a <cloning-parent> element, does that imply that it
inherits attributes not specified in its conference object from the
parent that is specified by the <cloning parent>? And if a parent obect
is modified, these changes would be applied  to its children also by the
server?

I recall a while back that it may be possible to specify what attributes
can be overridden by a child conference. How is that achieved?

Finally, I assume CCMP would support the possibility to break this
parent/child relationship, by sending an confRequest update with an
empty <cloning-parent> element?

I think the ccmp draft needs to add in some more detail and possibly
examples for cloning conferences ...

Regards
Sean

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Fri, 22 Jan 2010 12:18:11 -0000

Minor change:

In section 4, there is an '*' after the <conference-time> element
indicating that this element has been defined in rfc4575. 
This '*' should be removed because <conference-time> is a new extension
defined in this model...

Sean

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Fri, 22 Jan 2010 12:19:49 -0000

Hi,
	This docoument should have an example on how the
<conference-time> element gets populated...

Sean

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Fri, 22 Jan 2010 15:47:41 -0000

Hi,
	
The elements

    <xs:element name="cloning-parent" type="xs:unsignedLong"/>
    <xs:element name="sidebar-parent" type="xs:unsignedLong"/>

Have the wrong type, they should have type "xs:anyURI"

Sean

---

From: [email-masked]
Date: Mon, 25 Jan 2010 19:29:28 +0100

Hi again, Sean,

> need to define a default XCON URI to indicate to the server that it must

[spromano] Actually, you are right on this and you are raising here a  
general issue, concerning all cases in which the client provides  
information to the server in the form of a conference document (or  
part of it). We did not take into account the fact that there are some  
fields in the data model which are required (e.g. "entity" in  
"conference-type" or in "conference-medium-type", "id" in  
"media-type", etc.). This is due to the fact that the original data  
model in RFC4575 has been conceived for sending information FROM a  
conference server TO a conference client, while CCMP has been devised  
also with the opposite hypothesis in mind (information flows also  
along the direction FROM client TO server). Hence, we should  
definitely modify our document by introducing a sort of "wildcard"  
value for the above fields in all cases where they cannot be populated  
by the client since they have not been created yet.

As an example, in the mentioned case of the "implicit cloning" of a  
conference (as in par. 5.2 of draft-ietf-xcon-examples-02), we should  
modify the call flow as follows:

********* CURRENT VERSION *********
     <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ccmp:ccmpRequest
         xmlns:info="urn:ietf:params:xml:ns:conference-info"
         xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
         xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
      <ccmpRequest
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:type="ccmp:ccmp-conf-request-message-type">
         <confUserID>xcon-userid:[email-masked]</confUserID>
         <operation>create</operation>
         <ccmp:confRequest>
            <confInfo>
               <info:conference-description>
                   <info:display-text>
                   [......]
            </confInfo>
         </ccmp:confRequest>
      </ccmpRequest>
   </ccmp:ccmpRequest>
******** END CURRENT VERSION *******

******* UPDATED VERSION ************
     <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ccmp:ccmpRequest
         xmlns:info="urn:ietf:params:xml:ns:conference-info"
         xmlns:ccmp="urn:ietf:params:xml:ns:xcon:ccmp"
         xmlns:xcon="urn:ietf:params:xml:ns:xcon-conference-info">
      <ccmpRequest
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:type="ccmp:ccmp-conf-request-message-type">
         <confUserID>xcon-userid:[email-masked]</confUserID>
         <operation>create</operation>
         <ccmp:confRequest>
            <confInfo entity="CREATE">
               <info:conference-description>
                   <info:display-text>
                   [......]
            </confInfo>
         </ccmp:confRequest>
      </ccmpRequest>
   </ccmp:ccmpRequest>
******** END UPDATED VERSION ********************

The difference between the two versions resides just in the use of a  
"CREATE" wildcard value for the mandatory "entity" attribute.

The same solution should be applied to all of the above mentioned cases.
Do you think this is the right approach? In such case, we'll modify  
both the CCMP and the call flows drafts.

> response elements that require this change also...

[spromano] Right. We'll check all of them.

Cheers,

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: [email-masked]
Date: Mon, 25 Jan 2010 19:30:39 +0100

Hi again :-),

> <conference-time> element gets populated...

...we'll work on it. We'll try and provide a nice example.

Simon

---

From: [email-masked]
Date: Mon, 25 Jan 2010 20:03:48 +0100

Hi Sean,

> where a conference is cloned from a blueprint. Is that correct?

[spromano] Yes, it is.

> <cloning-parent> element be returned in the confResponse?

[spromano] Yes.

> parent that is specified by the <cloning parent>?

[spromano] From your comment I derive that you're envisaging a  
scenario in which I can clone a conference by issuing a  
confRequest/create message containing a conference document which  
explicitely states its will of being created as a clone of an existing  
one. This is done by providing the XCON URI of the parent object  
inside the <cloning-parent> element. Is this right? Indeed, the only  
way to clone a conference object is (see section 5.3 in  
draft-ietf-xcon-examples-02) by sending a confRequest/create message  
to the server, with no conference document attached and with the  
XCON-URI of the object-to-be-cloned in the confObjID parameter.  
Subsequent updates to such new document can be made through  
confRequest/update messages.

Note that the <cloning-parent> element is created by the server and  
sent back to the client.

> And if a parent obect

[spromano] This part is quite tricky, indeed. Though, this is not  
related to the CCMP. Cloning and associated policies are treated in  
RFC 5239, section 7.1 (Cloning Tree). Our interpretation of such part  
of the framework is that the so-called "parent-enforceable" mechanism  
is something hidden from the clients (i.e. it is a server-specific  
issue). If this were not the case, then the data model should contain  
a boolean "parent-enforceable" attribute for all elements that can be  
subject to such mechanism, which is not the case at this moment.

Do Mary, Oscar and the other authors of the mentioned documents (RFC  
5239 and draft-ietf-xcon-common-data-model) confirm our assumption?

Thanks again for your invaluable feedback!

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 26 Jan 2010 11:09:17 -0000

Hi Simon
	See below:-

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 25 January 2010 18:29
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05

Hi again, Sean,

> xcon URI (via the entity attribute) already exists on the server side? 
> I am thinking we should have another ResponseCode of 
> 'objectAlreadyExists'.
> BTW: In the CCMP examples - "Create Basic Conference from user 
> provided conference-info", the xml is missing the mandatory entity attribute.
>
> I would imagine most CCMP servers would generate the XCON URI, so do 
> we need to define a default XCON URI to indicate to the server that it 
> must generate one?
>

[spromano] Actually, you are right on this and you are raising here a general issue, concerning all cases in which the client provides information to the server in the form of a conference document (or part of it). We did not take into account the fact that there are some fields in the data model which are required (e.g. "entity" in "conference-type" or in "conference-medium-type", "id" in "media-type", etc.). This is due to the fact that the original data model in RFC4575 has been conceived for sending information FROM a conference server TO a conference client, while CCMP has been devised also with the opposite hypothesis in mind (information flows also along the direction FROM client TO server). Hence, we should definitely modify our document by introducing a sort of "wildcard"  
value for the above fields in all cases where they cannot be populated by the client since they have not been created yet.

As an example, in the mentioned case of the "implicit cloning" of a conference (as in par. 5.2 of draft-ietf-xcon-examples-02), we should modify the call flow as follows:

The difference between the two versions resides just in the use of a "CREATE" wildcard value for the mandatory "entity" attribute.

The same solution should be applied to all of the above mentioned cases.
Do you think this is the right approach? In such case, we'll modify both the CCMP and the call flows drafts.
[SEAN]: Well I think the default/wildcard entity should still conform to the xcon URI format for consistency of this field, 
How about xcon:[email-masked]? 

> for responses that may not have a info:conference-type element e.g. 
> for blueprint delete, or for blueprint operations that have returned 
> in error.

[SEAN] Thanks

Cheers,

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 26 Jan 2010 11:09:51 -0000

Thanks Simon. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 25 January 2010 18:31
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: Re: [XCON] Comments on draft-ietf-xcon-examples-02

Hi again :-),

> Hi,
> 	This docoument should have an example on how the <conference-time> 
> element gets populated...

Simon

---

From: [email-masked]
Date: Tue, 26 Jan 2010 12:30:58 +0100

Hi Sean,

> [SEAN]: Well I think the default/wildcard entity should still   
> conform to the xcon URI format for consistency of this field,

+1 from me! I like this proposal.

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 26 Jan 2010 11:37:54 -0000

Hi Simon,
	See below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 25 January 2010 19:04
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: Re: [XCON] Comments on draft-ietf-xcon-ccmp-05

Hi Sean,

> Hi All,
> 	I would like some clarification on the use of the <cloning-parent> 
> element with the CCMP protocol.

[spromano] Yes, it is.
[SEAN] OK Section 7.3 of the CCMP spec needs to change to reflect this. BTW do we need examples in the CCMP doc as well as the new examples doc?
Personally I think we should have only one reference for examples and maybe as an appendix to the CCMP?

[spromano] Yes.

>
> If a conference has a <cloning-parent> element, does that imply that 
> it inherits attributes not specified in its conference object from the 

[spromano] From your comment I derive that you're envisaging a scenario in which I can clone a conference by issuing a confRequest/create message containing a conference document which explicitely states its will of being created as a clone of an existing one. This is done by providing the XCON URI of the parent object inside the <cloning-parent> element. Is this right? Indeed, the only way to clone a conference object is (see section 5.3 in
draft-ietf-xcon-examples-02) by sending a confRequest/create message to the server, with no conference document attached and with the XCON-URI of the object-to-be-cloned in the confObjID parameter.  
Subsequent updates to such new document can be made through confRequest/update messages.

Note that the <cloning-parent> element is created by the server and sent back to the client.
[SEAN] that's all fine by me. However I think it would be a nice feature to allow a conference doc to be passed down in a cloning operation. Right now if I want to use a blueprint but obviously want a person name for my conference, I must
first send down the create and then follow this up with the update. I don't see any down side to allowing a conf doc to be supplied in the create also, so the CCMP server would first clone the existing conference, then apply the changes from the conf doc provided all in one transaction...

> And if a parent obect
> is modified, these changes would be applied  to its children also by 
> the server?
> I recall a while back that it may be possible to specify what 
> attributes can be overridden by a child conference. How is that achieved?
>

[spromano] This part is quite tricky, indeed. Though, this is not related to the CCMP. Cloning and associated policies are treated in RFC 5239, section 7.1 (Cloning Tree). Our interpretation of such part of the framework is that the so-called "parent-enforceable" mechanism is something hidden from the clients (i.e. it is a server-specific issue). If this were not the case, then the data model should contain a boolean "parent-enforceable" attribute for all elements that can be subject to such mechanism, which is not the case at this moment.
[SEAN] OK it is not CCMP related and it is data model related, but it all needs to tie in to a complete solution. The CCMP/Data model needs to provide clarity on this issue.
Well yes I think a "parent-enforceable" attribute would be a very useful feature. This would allow admin to modify a blueprint (e.g. max user count) which could get pushed down the conferences that got created from it etc

Simon

---

From: [email-masked]
Date: Wed, 27 Jan 2010 19:51:32 +0100

Hi Sean,

here we go again ;-). First of all, as regards blueprints, conferences  
and the parent/child relationship, our proposal would be to consider  
blueprints and conferences as two related yet independent concepts.
If you allow me to draw a comparison, I would say that a blueprint is  
like a C++ "template", whereas a conference is like a C++ "class".  
Under this perspective, the parent/child relationship just holds  
between conferences (i.e. conference B may be a child of conference A,  
but no conference is a child of a blueprint, even though it might have  
been created through a blueprint cloning operation). I think we  
discussed this some IETFs ago, at the f2f meeting; though, we can  
decide that we don't want to keep on having this distinction.

This said, your idea of having modifications to a parent conference  
propagate (through the parent-enforceable attribute -- which btw  
should be explicitely introduced in the data model) to the children it  
has generated looks interesting to us. Here again I would ask for  
other people's opinions on the list. Once we have an agreed-upon  
decision, we go and modify the draft in order to reflect it.

> [SEAN] that's all fine by me. However I think it would be a nice   
> feature to allow a conference doc to be passed down in a cloning   
> operation. Right now if I want to use a blueprint but obviously want  
>  a person name for my conference, I must
> first send down the create and then follow this up with the update.   
> I don't see any down side to allowing a conf doc to be supplied in   
> the create also, so the CCMP server would first clone the existing   
> conference, then apply the changes from the conf doc provided all in  
>  one transaction...

[spromano] This was also discussed before. I think we decided to stick  
to the simpler mechanism whereby you issue "atomic" requests to the  
server. This avoids any potential complication due to server-specific  
implementations of the cloning mechanism.

> [SEAN] OK it is not CCMP related and it is data model related, but   
> it all needs to tie in to a complete solution. The CCMP/Data model   
> needs to provide clarity on this issue.
> Well yes I think a "parent-enforceable" attribute would be a very   
> useful feature. This would allow admin to modify a blueprint (e.g.   
> max user count) which could get pushed down the conferences that got  
>  created from it etc

[spromano] Apart from my initial comment associated with blueprints  
(i.e. everything looks ok to us if you replace the blueprint with a  
parent conference..), conferences and cloning operations, I do agree  
that this would be a nice feature to add.

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Wed, 27 Jan 2010 21:35:12 -0000

Hi Simon,
	See below... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 27 January 2010 18:52
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: RE: [XCON] Comments on draft-ietf-xcon-ccmp-05

Hi Sean,

here we go again ;-). First of all, as regards blueprints, conferences and the parent/child relationship, our proposal would be to consider blueprints and conferences as two related yet independent concepts.
If you allow me to draw a comparison, I would say that a blueprint is like a C++ "template", whereas a conference is like a C++ "class".  
Under this perspective, the parent/child relationship just holds between conferences (i.e. conference B may be a child of conference A, but no conference is a child of a blueprint, even though it might have been created through a blueprint cloning operation). I think we discussed this some IETFs ago, at the f2f meeting; though, we can decide that we don't want to keep on having this distinction.

[SEAN] Well I think the CCMP protocol should be as flexible as possible and should treat the behaviour of blueprints and conferences the same when they are parents. I also think the CCMP protocol should allow the possibility of breaking the parent/child relationship by allowing updates with null <cloning-parent> elements. I think a typical use case is where somebody has a known working conference and just wants an independent clone of it. I don't really see the usecase for parent/child conferences but it is no harm having that possibility though...

This said, your idea of having modifications to a parent conference propagate (through the parent-enforceable attribute -- which btw should be explicitely introduced in the data model) to the children it has generated looks interesting to us. Here again I would ask for other people's opinions on the list. Once we have an agreed-upon decision, we go and modify the draft in order to reflect it.

> conference, then apply the changes from the conf doc provided all in  

[spromano] This was also discussed before. I think we decided to stick to the simpler mechanism whereby you issue "atomic" requests to the server. This avoids any potential complication due to server-specific implementations of the cloning mechanism.
[SEAN] Well it is still an atomic operation, actually with the current mechanism, a CCMP client will at least need to make two CCMP requests to create a conference... I don't see wny the CCMP draft should restrict supplying a conf doc in the update, It really simplfies CCMP client behaviour...

> max user count) which could get pushed down the conferences that got  

[spromano] Apart from my initial comment associated with blueprints (i.e. everything looks ok to us if you replace the blueprint with a parent conference..), conferences and cloning operations, I do agree that this would be a nice feature to add.

Simon

---

From: [email-masked]
Date: Thu, 28 Jan 2010 12:04:41 +0100

Hi Sean,

I think we are stuck on the points below, meaning that both your  
modification proposals are applicable, even though I personally keep  
on preferring the way they are currently done. Once again, I encourage  
people on the ML to raise their voice ;-).

More precisely:

1: as to the distinction between blueprints and actual conference  
objects, I would be in favour of keeping it;

2: as to the "atomicity" of CCMP creation requests, I would be in  
favour of keeping creation via cloning separate from a subsequent  
modification via update. With respect to this last point, in  
particular, even though the "create+update" operation might look  
atomic from the client perspective, it definitely is not such from the  
server's viewpoint.

Our experience with implementing the CCMP taught us that there are a  
bunch of tricky issues you have to face when playing with all of the  
subtle interrelations among the fields of the data model, especially  
wnen creating chieldren and sidebars. BTW, are you guys in Avaya  
currently implementing the protocol? In such case, it would be nice to  
share our experiences and start asap some interoperability tests.

Cheers,

Simon

Quoting "Duddy, Sean (Sean)" <[email-masked]>:

> here we go again ;-). First of all, as regards blueprints,   
> conferences and the parent/child relationship, our proposal would be  
>  to consider blueprints and conferences as two related yet   
> independent concepts.
> If you allow me to draw a comparison, I would say that a blueprint   
> is like a C++ "template", whereas a conference is like a C++ "class".
> between conferences (i.e. conference B may be a child of conference   
> A, but no conference is a child of a blueprint, even though it might  
>  have been created through a blueprint cloning operation). I think  
> we  discussed this some IETFs ago, at the f2f meeting; though, we  
> can  decide that we don't want to keep on having this distinction.
>
> [SEAN] Well I think the CCMP protocol should be as flexible as   
> possible and should treat the behaviour of blueprints and   
> conferences the same when they are parents. I also think the CCMP   
> protocol should allow the possibility of breaking the parent/child   
> relationship by allowing updates with null <cloning-parent>   
> elements. I think a typical use case is where somebody has a known   
> working conference and just wants an independent clone of it. I   
> don't really see the usecase for parent/child conferences but it is   
> no harm having that possibility though...
>
>
> should be explicitely introduced in the data model) to the children   
> it has generated looks interesting to us. Here again I would ask for  
> [spromano] This was also discussed before. I think we decided to   
> stick to the simpler mechanism whereby you issue "atomic" requests   
> to the server. This avoids any potential complication due to   
> server-specific implementations of the cloning mechanism.
> [SEAN] Well it is still an atomic operation, actually with the   
> current mechanism, a CCMP client will at least need to make two CCMP  
>  requests to create a conference... I don't see wny the CCMP draft   
> should restrict supplying a conf doc in the update, It really   
> simplfies CCMP client behaviour...
>

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Thu, 28 Jan 2010 11:20:35 -0000

Hi Simon,
	Yes we are considering using this protcol....

Well the "create+update" is atomic as far as the client is concerned which is all that matters regarding the protocol, right?
Regarding the server implmentations, I think even a simple create in a server implementation could map to a set of operations to be applied to the server's existing data model depending on how closely the server's existing datamodel maps back to the xcon data model...

Sean

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 28 January 2010 11:05
To: Duddy, Sean (Sean)
Cc: [email-masked]
Subject: RE: [XCON] Comments on draft-ietf-xcon-ccmp-05

Hi Sean,

I think we are stuck on the points below, meaning that both your modification proposals are applicable, even though I personally keep on preferring the way they are currently done. Once again, I encourage people on the ML to raise their voice ;-).

More precisely:

1: as to the distinction between blueprints and actual conference objects, I would be in favour of keeping it;

2: as to the "atomicity" of CCMP creation requests, I would be in favour of keeping creation via cloning separate from a subsequent modification via update. With respect to this last point, in particular, even though the "create+update" operation might look atomic from the client perspective, it definitely is not such from the server's viewpoint.

Our experience with implementing the CCMP taught us that there are a bunch of tricky issues you have to face when playing with all of the subtle interrelations among the fields of the data model, especially wnen creating chieldren and sidebars. BTW, are you guys in Avaya currently implementing the protocol? In such case, it would be nice to share our experiences and start asap some interoperability tests.

Cheers,

Simon

Quoting "Duddy, Sean (Sean)" <[email-masked]>:

> have been created through a blueprint cloning operation). I think we  
>> a person name for my conference, I must first send down the create 
>> and then follow this up with the update.
>> [SEAN] OK it is not CCMP related and it is data model related, but it 
>> all needs to tie in to a complete solution. The CCMP/Data model needs 
>> to provide clarity on this issue.