Subject: [XCON] Conference Policy Control -comments on draft-koskelainen-xcon-xcap-cpcp-usage-00

From: hisham.khartabil at nokia.com ([email-masked])
Date: Tue Jul 1 08:44:16 2003

Hi Eunah,

Thanks for the comments and corrections. Your modifications will be taken into consideration.

We actually have not put the schema into a validator yet due to time constraints, but will do as soon as possible.  We felt that the XML validity is not a big issue now, but the community accepting the idea was.

Anyhow, the next version will hopefully have a valid XML schema.

Regards,
Hisham

> -----Original Message-----
> From: ext Eunsook Kim [mailto:[email-masked]]
> Sent: Tuesday, July 01, 2003 3:23 PM
> To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham (NMP/Helsinki)
> Cc: [email-masked]; Isomaki Markus (NRC/Helsinki);
> [email-masked]; [email-masked]
> Subject: Re: [XCON] Conference Policy Control -comments on
> draft-koskelainen-xcon-xcap-cpcp-usage-00
> 
> 
> Hi Petri, and Hisham
> 
> I went over XCAP and the related documents and admit that it 
> gives simple and light method to manipulate conference policy. :-)
> I also have looked over your document and the defined XML 
> schema, and found a lot of syntax errors and several schema 
> validation errors.
> I tried to correct them, and attach the schema file, which I 
> get the successful validation message by running it into the XMLSPY. 
> Currently, I changed or added some of definition to get a 
> valid schema. 
> I tried to read your intention as possible as I can, but 
> please let me know if the corrections doesn't carry well on 
> your intention.
>  
> -----------------
> The brief note of the errors is as following:
> 
> 1. Namespace should be defined for 'conference-policy' in 
> order to reuse types and elements defined in the document.
> 
> [[Syntax errors]]
> 
> 2. Comment type should be <!--   --> instead <! >
> 
> 3. There are many cases where definitions are unappropriately 
> ended. I cannot list all of them here; give an example:
>           <xsd:simpleType name="Visibility-type"/>   <!-- '/' 
> not necessary -->
>                      <xsd:restriction base="xsd:string">
>                                 <xsd:enumeration value="visible"/>
>                                 <xsd:enumeration value="invisible"/>
>                      </xsd:restriction>
>             </xsd:simpleType>
> 
> 4.And, there are some mismatched or missed or redundant end tags.
>          ex)       <xsd:element name="Host-info">  <!-- in 
> "Conference-time" element -->
>                                <xsd:complexType>
>                                        <xsd:sequence>
>                                                <xsd:element 
> name="SIP-URI"  type="xsd:anyURI" use="required"/>
>                                                 .......... 
> (some elements)
>                                         <xsd:sequence> <!-- 
> you need to close the "sequence" with </xsd:sequence> -->
>                                        <xsd:sequence>  <!-- 
> and, you don't need one of the two "xsd:sequence" -->
>                               <xsd:complexType>
>                     </xsd:element>
> 
> [[Unvalid Schema Definition Errors]]
> 
> 5. You use [use="required"] severral times in definition of 
> elements, which is not appropriate. minOccurs="1" can be 
> used, instead.
> 
> 6. in your definition)      <xsd:element name="Security-mechanism">
>                                        <xsd:complexType>
>                                              <xsd:attribute 
> value="TLS"  type="xsd:boolean" default="false"/>
>                                              <xsd:attribute 
> value="S-MIME"  type="xsd:boolean" default="false"/>
>                                        </xsd:complexType>
>                                   </xsd:element>
> 
>    I got an error indicating unappropriate use of "value" in 
> attribute;
>    I got the validation error in the following definition. I 
> defined the type of Security-mechanism, and reuse it for the 
> definition.
>    Please let me know if it is different from your intention. 
> Then, I'll correct it as your intention. 
> 
> 
> 7.          <xsd:element name="Authorization-mechanism">
>                <xsd:complexType>
>                      <xsd:restriction base="xsd:string">
>                           <xsd:enumeration value="Digest"/>
>                           <xsd:enumeration value="None"/>
>                      </xsd:restriction>
>                      <xsd:attribute name="Password"  
> type="xsd:string"/>
>               </xsd:complexType>
> 
>      I got an error indicating wrong use of "restrction" 
> based enumeration value in a complexType. 
>      I tried to define the type of Authorixation-type for the 
> enumeration values.
> 
> 
> 8.           <xsd:element name="ACL">
>                         <xsd:complexType>
>                                  <xsd:sequence>
>                                            <xsd:element 
> name="ACL-target-URI" type="xsd:anyURI"  use="required" minOccurs="1" 
>                                                
> MaxOccurs="unbounded"/>  
>                                                          
> <xsd:complexType>
>                                                               
>      <xsd:attribute name="Access-type"  type="Access-mode"/>
>                                                          
> </xsd:complexType>
>                                  </xsd:sequence>
>                         </xsd:complexType>
>                </xsd:element>
> 
>      Over the definition, the closed tag of "ACL-target-URI" 
> element followed by MaxOccurs="unbounded" is not correct here, right? 
>     I guess you'd like to make ACL-target-URI have an 
> attribute, am I correct?
>      Anyway, I got an error indicating unappropriate use of 
> attribute here, so I changed "ACL" element to the form of  
> "PCL" and "DL" in this moment, but it is not your intention, 
> please let me know.
> 
> ------------------
> 
> I hope this will be helpful. 
>    
> Sincerely, 
> Eunah
> 
> 
> 
> 
> >
> >
> > ----- Original Message ----- 
> > From: [email-masked] 
> > To: [email-masked] ; [email-masked] 
> > Cc: [email-masked] ; [email-masked] ; 
> [email-masked] 
> > Sent: Friday, June 27, 2003 10:51 PM
> > Subject: RE: [XCON] Conference Policy Control 
> > 
> > 
> > Hi Eunah,
> > 
> > Thanks for the input. CPCP is very different from floor 
> control so we don't need to have same protocol
> > for these (besides, XCAP is already used for presence-list 
> manipulation which is similar to conf policy manipulation etc).
> > 
> > If you can provide input to CPCP (e.g. what parameters 
> should be included in the policy, or finding errors in XML Schema) 
> > that would be highly appreciated.  
> > 
> > Thanks,
> > Petri
> >
> >
> >
> >>-----Original Message-----
> >>From: ext Eunsook Kim [mailto:[email-masked]]
> >>Sent: 27 June, 2003 16:44
> >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> >>Cc: [email-masked]; Isomaki Markus (NRC/Helsinki); JongHwa
> >>Subject: Re: [XCON] Conference Policy Control 
> >>
> >>
> >>Hisham,
> >>
> >>Thanks a lot for your response. 
> >>
> >>I've chosen SOAP for acessing server elements of conference 
> policy control, because  it is a well-known standardized protocol. 
> >>Besides, I believe there is a close relationship between 
> conference policy and floor controls, and I think that it 
> would be good for the two >>mechanisms to use the same protocol. 
> >>As you know, Xioatao and Petri have already proposed a 
> floor control draft using SOAP, 
> >>so, I've prototyped a few basic functions of policy control 
> using SOAP, and wrote my draft. 
> >>However, SOAP is just one of the methods to allow client to 
> access policy server information, and 
> >>I'm willing to do it by using XCAP, too
> >>
> >>I think,  the main focus of this work is not if it should 
> be SOAP or XCAP. 
> >>In my opinion, it is more important to design well-formed 
> schema for policy control operations which can be 
> standardized, and I think the >>conference design team has 
> been doing very good job in this point of view. And, as the 
> one who is very interested in and working on this area, >>I'm 
> very happy to hear the XCON bof announcement, and I'll be 
> very happy if I can help or contribute some parts on the 
> works of design team.
> >>
> >>I'll go over all the XCON drafts again, and I would like to 
> discuss on this topic with you more in the mailing list, if 
> you'd like to.
> >>
> >>I appreciate your response again.
> >>
> >>Yours faithfully, Eunah
> >>
> >>
> >>
> >>>----- Original Message ----- 
> >>>From: [email-masked] 
> >>>To: [email-masked] ; [email-masked] 
> >>>Cc: [email-masked] ; [email-masked] 
> >>>Sent: Friday, June 27, 2003 3:24 PM
> >>>Subject: RE: [XCON] Conference Policy Control 
> >>>
> >>>
> >>>Eunah,
> >>>
> >>>We appreciate your enthusiasm about the conferencing work.
> >>>
> >>>Your proposal so makes use of SOAP as a solution. To be 
> honest, our interest in SOAP as a solution for conference 
> policy protocol is very >>>minimal. That's why we chose XCAP, 
> its simple and much lighter to implement than SOAP.
> >>>
> >>>If you feel that your proposal is the superior one, please 
> feel free to involve yourself in the soon newly formed IETF 
> working group, named >>>XCON, specifically designed to 
> produce such conferencing protocols. The conferencing work so 
> far has been done in a closed design team >>>where the XCAP 
> has so far been well accepted as the conference policy solution.
> >>>
> >>>Much appreciated,
> >>>Hisham
> 
> 
>

---

From: eunah at etri.re.kr (Eunsook Kim)
Date: Wed Jul 2 00:57:28 2003

Hi Hisham,

First of all, I'd like to say that I've been also thinking the importance of your document is the idea in this momont. 
I don't think I misunderstand this point. 
I did the validation work because I think a valid schema would increase the readibility. 
(Because of the not-wellformed schema, I had some trouble when I tried to look over 
if the schema was well delivering your idea. So, I did the validation work, first.)

Second, I have a few questions on your document as following: 

1. Your document is mentioning that CPS lets Focus know the Dial-out List, and then Focus send INVITE to the members in the list,
    and CPS also have the FOCUS to send BYE when there is a BLOCKED member.
    However, there is no explanation of HOW the CPS carries the information to the Focus. 
    I know they are logical entities, but I don't think CPS and Focus are always configutated in local system. 
    So, I think they need a way to communicate each other.
    Is this the out of scope of the XCON work? Or, do you remain this work as future work?

2. I think we need a field for describing media (or codec) information when a client requests a conference creation.
    I DON'T mean the negotiation of media. The preference of the client should be considered, I think. 
    Is the "Conference-media-policy" which is not yet defined for this purpose? 

3. This can be minor in the moment, but .......;
    You defined "Conference-URI", the sub-element of "Conference" as a required element, and 
    "SIP-URI", the sub-element of the "Conference-URI" is also defined as a required element.
    However, the conferencing framework document ,and also your document are describing
    CPS can create the conference URI. In addition, your document mentions the conference URI can be 
    SIP, SIPS, or TEL URI. 
    Based on the describtions, I think it is definitely needed to define, but should not be defined as a required one. 

I'll appreciate your response.

Sincerely,
Eunah