Subject: [XCON] New version of CSCP draft

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Tue, 24 Jan 2006 09:40:35 +0100

Folks,

We would like to notify the new version of the CSCP draft. Until it
appears in the archives, you can fetch it from:

<http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-03.txt>
http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-03.txt

Here's an overall summary of the changes:

- Definition of new operations: Section 9.1 "Creation of a conference"
and Section 9.2 "Termination of a conference" 

- Definition of new attributes (Section 8: TEMPLATE-ID)  

- Definition of new error values of the protocol

- In Section 11 (Examples) added additional examples (Creation of a
conference, Modification of a conference, Destruction of a conference)
and additional text explaining the example

Cheers,

Oscar

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 26 Jan 2006 16:42:14 +0200

Hi,

I read the draft and would like to give the following feedback that
includes questions and comments.

1.       The document is using the conference event package after the
conference creation in order to get the elements IDs. My understanding
so far is that a UA subscribes to a conference that is running now and
not to one that is created and may run later.  I see this as a major
issue since the whole solution is based on it. It is not only issue of
when you can subscribe to a conference state but also about extending
the conference event package to include all the elements and attributes
that are needed to create conferences which are not there.

2.       In section 8 you sort of define the template, I suggest
referring to the framework document.

3.       In section 9.1 second paragraph - "The creator sets inside the
AddConferenceRequest the name of the conference" suggest using display
name.

4.       When creating a conference, how does the user learn the urn of
the templates he can use.

5.       In section 9.1  "If the AddConferenceRequest refers to a
conference which does already exist in the server," - how can it happen
since the conference ID in the header must be zero. The display name is
not unique as far as I understand.

6.       In 9.1  "If the AddConferenceRequest is successful, the server
responds with a AddConferenceAck, which includes the URI of the
conference created inside the ELEMENT-ID." It si not the conference URI
but the conference ID. The same comment is for section 9.2  in two
places -the element-id indicates the conference ID and not the URI.

7.       In section 9.4 you are talking about setting attributes value.
The second paragraph talks about retrieving - this is probably a cut and
paste from 9.3.

8.       In section 10 

8. "It is RECOMMENDED that once an ELEMENT-ID value is used in an
element within a conference, the same ELEMENT-ID value is not used in
the same conference again in a different element." I think RECOMMENDED
is too weak, according to section 5 the element id uniquely identify an
element withing a conference.

9.       In the example in section 11.1 the addConferenceAck message
returns Conference ID: 000. Shouldn't it be the same as the ELEMENT-ID.

10.   I noticed that section 12 talks about correlation with the
conference event package. Just note that the dial-out-list in the
example of section 11.3 is not a child element of users. There is no
dial-out list in the event package, since this is not a state. There is
information inside the endpoint element if this was a dial out or dial
in call.

11.   Nit - section 9.5 first line - add an element instead of add and
element.

Roni Even

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Fri, 27 Jan 2006 16:21:18 +0100

Hello Roni, 
 
Thank you very much to review the CSCP draft and provide interesting comment. I´ve updated  the draft according to your comments number 2,3,5,6,7,8, and 11. In the new version you will see the changes.
 
Comments to the other numbers are inline...

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Even, Roni
Sent: 26. tammikuuta 2006 16:42
To: [email-masked]
Subject: RE: [XCON] New version of CSCP draft

Hi,

I read the draft and would like to give the following feedback that includes questions and comments.

1.       The document is using the conference event package after the conference creation in order to get the elements IDs. My understanding so far is that a UA subscribes to a conference that is running now and not to one that is created and may run later.  I see this as a major issue since the whole solution is based on it. It is not only issue of when you can subscribe to a conference state but also about extending the conference event package to include all the elements and attributes that are needed to create conferences which are not there.

[ON] But the current conference event package represents just the state of the conference. Do you think is good idea to extend the conference event package to support more than the state? Maybe, the CSCP protocol should especify a mechanism to query the capabilities of the system. Now, the CSCP protocol only allow to retrieve the attribute values. What do you think?

4.       When creating a conference, how does the user learn the urn of the templates he can use.

 [ON] this is outside the scope of the document. Anyway, I´ve update the draft telling that this is outside the scope of the document and this information can be provided
   by other means, such as email or the Web.

9.       In the example in section 11.1 the addConferenceAck message returns Conference ID: 000. Shouldn't it be the same as the ELEMENT-ID. 

[ON] I just try to keep the same behaviour in the addConferenceAck message than in the other messages. Normally, when a server receives a CSCP or BFCP message, it copies in the response the same Conference-ID attribute than the one in the message receives.

10.   I noticed that section 12 talks about correlation with the conference event package. Just note that the dial-out-list in the example of section 11.3 is not a child element of users. There is no dial-out list in the event package, since this is not a state. There is information inside the endpoint element if this was a dial out or dial in call. 

[ON]  The dial-out-list is defined in the "Common Conference Information Data Model for Centralized Conferencing (XCON)" as an element of users. The dial-out-list is not defined in the event package because the event package only shows the state of the conference. 

Roni Even

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 30 Jan 2006 13:33:20 +0200

Oscar,

About

I read the other drafts (COMP and CCMP) both of them define the mechanism to learn the conference server capabilities (learn which template are supported) and to get the templates. 

Roni

From: Oscar Novo (JO/LMF) [mailto:[email-masked]] 
Sent: Friday, January 27, 2006 5:21 PM
To: Even, Roni; [email-masked]
Subject: RE: [XCON] New version of CSCP draft

Hello Roni, 

Hi,

[ON] But the current conference event package represents just the state of the conference. Do you think is good idea to extend the conference event package to support more than the state? Maybe,the CSCP protocol should especify a mechanism to query the capabilities of the system. Now, the CSCP protocol only allow to retrieve the attribute values. What do you think?

 

[ON]I just try to keep the same behaviour in the addConferenceAck message than in the other messages. Normally, when a server receives a CSCP or BFCP message, it copies in the response the same Conference-ID attribute than the one in the message receives.

 

Roni Even

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Mon, 30 Jan 2006 12:50:58 +0100

Hi,
 
So, if people think it is needed. We can add an operation "GetTemplate" to the CSCP protocol.
 
Oscar

From: Even, Roni [mailto:[email-masked]] 
Sent: 30. tammikuuta 2006 13:33
To: Oscar Novo (JO/LMF); [email-masked]
Subject: RE: [XCON] New version of CSCP draft

Oscar,

About

Roni

Hello Roni, 

Hi,

 

 

Roni Even