Subject: [XCON] Comments on draft-ekim-xcon-cpcp-bb-00

From: "Eric Burger" <[email-masked]>
Date: Fri, 7 Nov 2003 16:19:36 -0500

First, I'll staying far away from the draft-koskelainen-xcon-xcap-cpcp-usage-01.txt debate.  However, it is instructive to look into the "additional" stuff, or even at least see alternate interpretations of the same stuff (if it is the same stuff -- I'm not getting into the debate).  More discussion of the issues raised should help the work group produce better documents.

Section 3:
Why MUST the protocol be XML?  There is not reason for this implementation choice being a requirement.  Of course, everyone knows I would go ballistic if it was ASN.1, but that would be an implementation choice, not a need.

I don't think the document means the focus would ask the CPS for authentication of participants.  Authentication means proving *who* the client is.  The CPS would be needed to decide if the client is *authorized*.  It is probably useful to say the transport protocol (e.g., http/SOAP, SIP, etc.) would provide the authentication function.

Section 6.1:
What is the value of specifying static versus dynamic closed conferences?  For example, a client cannot tell the difference between a closed conference and a conference that has its maximum number of participants.  Either way, a new participant cannot join.  How about making availability to join a separate parameter (if that is useful)?

Section 6.1:
Does the conference time element say when the conference WILL BE, or when the conference WAS.  The text implies future scheduling.  That could be clearer.

Section 7.1.2:
Why is conf-name present?  If conf-URI is present (mandatory, so it should be), that is enough to uniquely identify the conference.  Adding conf-name confuses things.  For example, what if conf-name does not match conf-URI?  That adds an error condition to handle.

Allowing conf-name would make sense if you could identify the conference to be destroyed by *either* conf-name or conf-URI.  However, that adds another new error condition.  I don't think conf-name is necessarily unique.  Thus one would have to handle the "ambiguous name" error condition.

Allowing only conf-URI is so much cleaner.

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

---

From: "Eunsook Kim" <[email-masked]>
Date: Tue, 11 Nov 2003 08:11:47 +0900

Eric, thanks for your interests and comments. My answer is inline.

>Section 3:
>Why MUST the protocol be XML?  There is not reason for this implementation choice being a requirement.  Of course, everyone knows I would go >ballistic if it was ASN.1, but that would be an implementation choice, not a need.
>

IMHO, XML seems to easy to express and deliver the CPCP operations which request frequent change of the specified conference policy docuement.
(It is somewhat implementor's view, though)
In general behavior of CPCP, clients request to create/delete, list, or modify a specific conference information. When clients request to modify a specific element (such as conference time in general information, user info in participants managemnt information, etc.) clients easily describe the request information (in which conference, of which element) with Xpath and Xposition if it is originally written in XML, without delivering the whole document.  If CPS received the request, an XML parser decode the request, and CPS gets the decoded requested elements. Moreover, NOTIFY in RFC3265 and the conference package document already use XML, so many of APIs for handling the informatin can be re-used (sometimes with small modification). 
If we use text, both clients and the CPS need to implement encode and decode modules, unlikely to use well-known parser in XML case. It is also needed to hold various varibles to contain the many kinds of conference information.

About you opinion that it would be an implementation choice, I think it's better to have a standard mechanism like SDP rather than we leave it as implementor's choice when I concern interoperability between CPS and different companies's clients. 

>I don't think the document means the focus would ask the CPS for authentication of participants.  Authentication means proving *who* the client is.  >The CPS would be needed to decide if the client is *authorized*.  It is probably useful to say the transport protocol (e.g., http/SOAP, SIP, etc.) >would provide the authentication function.
>

Yes, authorization would be the proper expression. Thanks.

>
>Section 6.1:
>What is the value of specifying static versus dynamic closed conferences?  For example, a client cannot tell the difference between a closed >conference and a conference that has its maximum number of participants.  Either way, a new participant cannot join.  How about making availability >to join a separate parameter (if that is useful)?
>

Well, you are right. to define static or dynamic closed conference has its value only before it reaches the maximum number of participants. 
To consider this perspective, we may define 'availablility to join', as your suggestion.

>Section 6.1:
>Does the conference time element say when the conference WILL BE, or when the conference WAS.  The text implies future scheduling.  That could >be clearer.

okay. Thanks for the comment.

>
>Section 7.1.2:
>Why is conf-name present?  If conf-URI is present (mandatory, so it should be), that is enough to uniquely identify the conference.  Adding conf->name confuses things.  For example, what if conf-name does not match conf-URI?  That adds an error condition to handle.

>Allowing conf-name would make sense if you could identify the conference to be destroyed by *either* conf-name or conf-URI.  However, that >adds another new error condition.  I don't think conf-name is necessarily unique.  Thus one would have to handle the "ambiguous name" error >condition.
>

I thought that 'conf-URI' is the only mendatory element, and 'conf-name' is only for extra information.
Actually, I didn't check 'conf-name' when I implemented. Yes, if it is a confuses things, it would be better to removed. 
Thanks for the comment.

Eunsook Kim 
Â8ÙšŠX§‚X¬µpŽ6'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?ÅÊ'

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 Nov 2003 17:19:56 -0600

Eunsook,

To summarize.

It is a requirement that we pick something.  It is not a requirement 
that we pick XML. We are very likely to pick XML anyway, but not 
because it is a requirement.

thanks,
-rohan

On Monday, November 10, 2003, at 05:11 PM, Eunsook Kim wrote:

>> Why MUST the protocol be XML?  There is not reason for this 
>> implementation choice being a requirement.  Of course, everyone knows 
>> I would go >ballistic if it was ASN.1, but that would be an 
>> implementation choice, not a need.
>>
>
> IMHO, XML seems to easy to express and deliver the CPCP operations 
> which request frequent change of the specified conference policy 
> docuement.
> In general behavior of CPCP, clients request to create/delete, list, 
> or modify a specific conference information. When clients request to 
> modify a specific element (such as conference time in general 
> information, user info in participants managemnt information, etc.) 
> clients easily describe the request information (in which conference, 
> of which element) with Xpath and Xposition if it is originally written 
> in XML, without delivering the whole document.  If CPS received the 
> request, an XML parser decode the request, and CPS gets the decoded 
> requested elements. Moreover, NOTIFY in RFC3265 and the conference 
> package document already use XML, so many of APIs for handling the 
> informatin can be re-used (sometimes with small modification).
> If we use text, both clients and the CPS need to implement encode and 
> decode modules, unlikely to use well-known parser in XML case. It is 
> also needed to hold various varibles to contain the many kinds of 
> conference information.
>
> About you opinion that it would be an implementation choice, I think 
> it's better to have a standard mechanism like SDP rather than we leave 
> it as implementor's choice when I concern interoperability between CPS 
> and different companies's clients.
>
>> I don't think the document means the focus would ask the CPS for 
>> authentication of participants.  Authentication means proving *who* 
>> the client is.  >The CPS would be needed to decide if the client is 
>> *authorized*.  It is probably useful to say the transport protocol 
>> (e.g., http/SOAP, SIP, etc.) >would provide the authentication 
>> function.
>>
>
>> What is the value of specifying static versus dynamic closed 
>> conferences?  For example, a client cannot tell the difference 
>> between a closed >conference and a conference that has its maximum 
>> number of participants.  Either way, a new participant cannot join.  
>> How about making availability >to join a separate parameter (if that 
>> is useful)?
>>
>
> Well, you are right. to define static or dynamic closed conference has 
> its value only before it reaches the maximum number of participants.
>> Does the conference time element say when the conference WILL BE, or 
>> when the conference WAS.  The text implies future scheduling.  That 
>> could >be clearer.
>
>> Why is conf-name present?  If conf-URI is present (mandatory, so it 
>> should be), that is enough to uniquely identify the conference.  
>> Adding conf->name confuses things.  For example, what if conf-name 
>> does not match conf-URI?  That adds an error condition to handle.
>
>> Allowing conf-name would make sense if you could identify the 
>> conference to be destroyed by *either* conf-name or conf-URI.  
>> However, that >adds another new error condition.  I don't think 
>> conf-name is necessarily unique.  Thus one would have to handle the 
>> "ambiguous name" error >condition.
>>
> I thought that 'conf-URI' is the only mendatory element, and 
> 'conf-name' is only for extra information.
> Actually, I didn't check 'conf-name' when I implemented. Yes, if it is 
> a confuses things, it would be better to removed.
> Thanks for the comment.
>
>
> Eunsook Kim