[XCON] Control vs. Description protocol

[orit at radvision.com (Orit Levin)]

Hi!

I would like to bring to the discussion my concern about designing the CPCP
as a protocol around editing files (that describe the conferences).

In my opinion the CPCP needs to be a CONTROL protocol in addition to being
just a "Conference Description Protocol". Below are some of the arguments to
support this point of view:

2. CPCP is a protocol to be designed MOSTLY for the benefit of the end
users. (Operators may have other, not necessarily standard, means.) As a
result, a user must be able to get/modify/etc. his own view of the
conference or his position in the conference without being (necessarily)
exposed to the general conference view. 

1. Each communication with the CPS needs to be short and effective.
Non-default conference creation is the only exception, may be. Even so,
means should be defined to make it as effective as possible: such as using
conference profiles.

What would be your thoughts?
Orit Levin
Chief Architect
RADVISION
Phone: [phone]
Video: +1.201.6896430


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, July 02, 2003 2:48 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [XCON] Conference Policy Control -comments on draft-
> koskelainen-xcon-xcap-cpcp-usage-00
> 
> 
> 
> > -----Original Message-----
> > From: ext Eunsook Kim [mailto:[e-mail]]
> > Sent: Wednesday, July 02, 2003 8:57 AM
> > To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> > Cc: [e-mail]; Isomaki Markus (NRC/Helsinki);
> > [e-mail]; [e-mail]
> > Subject: Re: [XCON] Conference Policy Control -comments on
> > draft-koskelainen-xcon-xcap-cpcp-usage-00
> >
> >
> > 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?
> 
> It was deliberately left out. I guess this is a questions for the chairs
> to answer.
> 
> >
> > 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?
> 
> The dialog and media negotiation is between the CPS (focus) and the
> participants. Why would the creator care what codecs the other
> participants use between them and the focus?
> 
> In any case, you can read more about media policy in this draft (although
> I don't think codec preference is part of it:
> 
> http://www.ietf.org/internet-drafts/draft-mahy-xcon-media-policy-control-
> 00.txt
> 
> The author has been looking into XCAP for this as well.
> 
> 
> 
> >
> > 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.
> 
> It is required since without it, the conference cannot be addressed. The
> creator includes it, even though empty, as a way of indicating that it
> deliberately left it out for the server to fill in (not a mistake). Maybe
> others have a better answer.
> 
> Thanks for the interest in this work
> 
> Regards,
> Hisham
> >
> >
> > I'll appreciate your response.
> >
> > Sincerely,
> > Eunah
> >
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <[e-mail]>; <[e-mail]>
> > Cc: <[e-mail]>; <[e-mail]>;
> > <[e-mail]>; <[e-mail]>
> > Sent: Tuesday, July 01, 2003 10:35 PM
> > Subject: RE: [XCON] Conference Policy Control -comments on
> > draft-koskelainen-xcon-xcap-cpcp-usage-00
> >
> >
> > > 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:[e-mail]]
> > > > Sent: Tuesday, July 01, 2003 3:23 PM
> > > > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham
> > (NMP/Helsinki)
> > > > Cc: [e-mail]; Isomaki Markus (NRC/Helsinki);
> > > > [e-mail]; [e-mail]
> > > > 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: [e-mail]
> > > > > To: [e-mail] ; [e-mail]
> > > > > Cc: [e-mail] ; [e-mail] ;
> > > > [e-mail]
> > > > > 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:[e-mail]]
> > > > >>Sent: 27 June, 2003 16:44
> > > > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri
> > (NRC/Tampere)
> > > > >>Cc: [e-mail]; 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: [e-mail]
> > > > >>>To: [e-mail] ; [e-mail]
> > > > >>>Cc: [e-mail] ; [e-mail]
> > > > >>>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
> > > >
> > > >
> > > >
> > >
> > >
> >
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
From orit at radvision.com  Wed Jul  2 11:14:23 2003
From: orit at radvision.com (Orit Levin)
Date: Wed Jul  2 09:15:43 2003
Subject: [XCON] Conference Policy Control -comments on 	draft-koskelai
	nen-xcon-xcap-cpcp-usage-00
Message-ID: <[e-mail]>

My responses are inline.

Orit.


> -----Original Message-----
> From: Eunsook Kim [mailto:[e-mail]]
> Sent: Wednesday, July 02, 2003 1:57 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [XCON] Conference Policy Control -comments on draft-
> koskelainen-xcon-xcap-cpcp-usage-00
> 
...skip
> 
> 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?
> 
According to the Conference Design team discussions, the communications
between CPS and the focus is out of scope of XCON and is a matter of
implementation. 

> 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?

I agree very much. Please, also see
http://www.ietf.org/internet-drafts/draft-levin-xcon-cpcp-00.txt.
Specifically:

<Invite_Participant_Request>
...
   			<Set_Layout> TBD by MPCP </Set_Layout>
...
   </Invite_Participant_Request>

and "Functions and Issues Still to be Addressed":

   Coordination between CPCP and Media Policy Control Protocol (MPCP) hasn't
been addressed yet. Some of the operations will require joined execution of
CPCP and MPCP primitives in a single "atomic" operation.

> 
> 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.
> 
Right. The CPCP is orthogonal to the signaling protocol(s) to be used
between the focus and its participants. The Conference-URI definition and
the CPCP mechanism should support participation of users, which run
different signaling protocols, in the same conference.
> 
> I'll appreciate your response.
> 
> Sincerely,
> Eunah
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Sent: Tuesday, July 01, 2003 10:35 PM
> Subject: RE: [XCON] Conference Policy Control -comments on draft-
> koskelainen-xcon-xcap-cpcp-usage-00
> 
> 
> > 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:[e-mail]]
> > > Sent: Tuesday, July 01, 2003 3:23 PM
> > > To: Koskelainen Petri (NRC/Tampere); Khartabil Hisham (NMP/Helsinki)
> > > Cc: [e-mail]; Isomaki Markus (NRC/Helsinki);
> > > [e-mail]; [e-mail]
> > > 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: [e-mail]
> > > > To: [e-mail] ; [e-mail]
> > > > Cc: [e-mail] ; [e-mail] ;
> > > [e-mail]
> > > > 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:[e-mail]]
> > > >>Sent: 27 June, 2003 16:44
> > > >>To: Khartabil Hisham (NMP/Helsinki); Koskelainen Petri (NRC/Tampere)
> > > >>Cc: [e-mail]; 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: [e-mail]
> > > >>>To: [e-mail] ; [e-mail]
> > > >>>Cc: [e-mail] ; [e-mail]
> > > >>>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
> > >
> > >
> > >
> >
> >
> 
> _______________________________________________
> XCON mailing list
> [e-mail]
> http://www.softarmor.com/mailman/listinfo/xcon
From georg.mayer at nokia.com  Thu Jul 10 15:58:54 2003
From: georg.mayer at nokia.com ([e-mail])
Date: Thu Jul 10 06:59:02 2003
Subject: [XCON] 3GPP Requirements on CPCP
Message-ID: <[e-mail]>

Hello,

initially I planned to have a short presentation at the Vienna meeting on 3GPP requirements on CPCP, but unfortunately it seems that there is no time slot neither in SIPPING nor XCON which allows going into technical discussions during this meeting. So I decided to make my comments on the mailing list.

As you know in 3GPP we are planning to adopt the SIP conferencing solution for the IMS (IP Multimedia Subsystem). During the last (CN1 WG) meeting we had some discussions on CPCP and decided that we will also adopt this solution, although some delegates had some concerns. I therefore got the task to collect requirements on CPCP, what I did.

As always, the resources in wireless devices are a sacred thing and therefore the main concern was, that CPCP will introduce a whole new protocol and notation, that needs to be implemented "just" for CPCP. Therefore the main issues are:

1) that CPCP makes use of an notation mechanism that is already used within the IMS / SIP protocol. We think that XML is the way forward here. 

2) that CPCP makes use of a protocol that is already used in state-of-the-art wireless devices. As SIP is not an option here, we very much favour HTTP, as this is implemented in every new mobile phone model.

As the 3GPP architecture sees the protocols for any sort of application specific data manipulation over the same (Ut) interface, we also favour the approach to harmonize the data manipulation solutions as much as possible. I am aware that CPCP is more than just data manipulation, nevertheless there are very similar concepts in e.g. Presence DM and CPCP. As the IMS will also include (SIMPLE based) Presence and Presence Data Manipulation, we also see the need

3) that CPCP and Presence Data Manipulation solution must be aligned, in order to re-use as much functionality as possible.

This is also important, as we see lots of services in the future, which will also require Data Manipulation via the Ut interface - we want these solutions harmonized if possible. The XCAP proposal as currently discussed in SIMPLE seems to be the right way forward here. 

Finally there is a need that the UE gets aware of the CPCP server. This might be outside of the scope of XCON, maybe more related to SIPPING, but as it is related to this issue, I would like to see it also listed:

4) There must be a way for the UE to get aware of the address of a CPCP server (or any other server which allows the UE to perform data manipulation).

If the group agrees, I would reformulate these requirements into "requirements language", so that they can be added to CPCP requirements draft (draft-koskelainen-xcon-cpcp-reqs-00.txt). 

Thank you and best regards
Georg