Subject: [XCON] CPCP - is XCAP suitable or not

From: [email-masked]
Date: Sun, 30 Nov 2003 20:53:08 +0200

Hi,

There has been discussion on the mailing list and also in Minneapolis whether XCAP would be a good protocol to meet CPCP requirements or not. There is already a proposal showing how this could work by Hisham and Petri, but maybe there needs to be some more general discussion first. In the following I describe my understanding on the issues:

XCAP is designed for data manipulation, i.e. client can manipulate XML based information on a server. There is some limited intelligence included in the protocol via XML schema validation and computed data. XCAP is very suitable for operations which can be somehow modeled as configuration/data manipulation, i.e. manipulation some state on the server. It is less well suited for sending explicit commands to a server in a case where the client just wants the server to do some operation without creating more permanent state. XCAP as such lacks the abilty to convey events describing the state of what is going on in the requested operations (response to request needs to be sent according to HTTP rules), but to overcome that SIP could be used.

CPCP will presumably contain different types of operations/functionality. Conference creation and URI assigment seem equal to what is done with XCAP resource list AUID, so no problem there. Access and privilege rule management seems equal to what is done in XCAP presence authorization AUID, so that works too. Any parameter/metadata setting (subject, timing, ...) is also exactly what XCAP does. 

The main point of difficulty seems to be mass-invite/dial-out list and mass-kick-out functionality, since this seems more like commanding than configuring. It is however possible, even if not perhaps elegant, to model this as data manipulation as well, if we assume that the conference focus is an XCAP client too. It is possible to define that dial-out list is just another list which the client can manipulate, and the logic would be that if someone who is not currently in the conference is included to the list he is invited. Once the invitation attempt has been done (success or failure), the conference focus(?) may need to remove the entry from the list to prevent the list from growing eternally. SIP conference state event can be used  by the client to monitor the progress of the attempt. Kick-outs could be done similarly by managing the access control.

At least I didn't come up with any other type of functionality that would be needed in CPCP. Based on this and the desire to reuse existing protocols (XCAP is probably included in many of the clients having CPCP in the future) I came up with two options that I would be happy with:
a) Do everything with XCAP by modeling the commands as data manipulation, probably as explained above with mass-invitation case
b) Do conf creation, parameter setting, ACL management with XCAP, and leave mass-invitations/kick-outs to some other protocol, which could be some very simple XML-RPC thing, or indeed, SIP exploder mechanism.

Obviously, there is option c) not to use XCAP at all, but I didn't come up with a compelling reason for that.

I believe that we just have to decide on which requirements to keep and how we proceed with the protocol (XCAP or something else) before the end of this year to have something ready at least somewhat close to the charter deadlines.

Markus

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

---

From: [email-masked]
Date: Sun, 30 Nov 2003 21:18:49 +0200

I don't see a dial-out list as a non configuration thing for a conference. It is logical to configure a conference with the participant list that will be dialled out to just as well as a dial-in list. The focus has to read the list and send INVITE requests to the members. Adding members to a conference while the conference is in progress can also be achieved. The moderator configures them into the dial-out list, the focus learns of the changes to the dial-out list and generates INVITE requests to the added users.

Expelling users during the conference is an issue, but I think we solved it quite well with XCAP.

I prefer option a). I don't like the idea of developing 2 protocols that are only usable if combined.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 30.November.2003 20:53
> To: [email-masked]
> Subject: [XCON] CPCP - is XCAP suitable or not
> 
> 
> Hi,
> 
> There has been discussion on the mailing list and also in 
> Minneapolis whether XCAP would be a good protocol to meet 
> CPCP requirements or not. There is already a proposal showing 
> how this could work by Hisham and Petri, but maybe there 
> needs to be some more general discussion first. In the 
> following I describe my understanding on the issues:
> 
> XCAP is designed for data manipulation, i.e. client can 
> manipulate XML based information on a server. There is some 
> limited intelligence included in the protocol via XML schema 
> validation and computed data. XCAP is very suitable for 
> operations which can be somehow modeled as configuration/data 
> manipulation, i.e. manipulation some state on the server. It 
> is less well suited for sending explicit commands to a server 
> in a case where the client just wants the server to do some 
> operation without creating more permanent state. XCAP as such 
> lacks the abilty to convey events describing the state of 
> what is going on in the requested operations (response to 
> request needs to be sent according to HTTP rules), but to 
> overcome that SIP could be used.
> 
> CPCP will presumably contain different types of 
> operations/functionality. Conference creation and URI 
> assigment seem equal to what is done with XCAP resource list 
> AUID, so no problem there. Access and privilege rule 
> management seems equal to what is done in XCAP presence 
> authorization AUID, so that works too. Any parameter/metadata 
> setting (subject, timing, ...) is also exactly what XCAP does. 
> 
> The main point of difficulty seems to be mass-invite/dial-out 
> list and mass-kick-out functionality, since this seems more 
> like commanding than configuring. It is however possible, 
> even if not perhaps elegant, to model this as data 
> manipulation as well, if we assume that the conference focus 
> is an XCAP client too. It is possible to define that dial-out 
> list is just another list which the client can manipulate, 
> and the logic would be that if someone who is not currently 
> in the conference is included to the list he is invited. Once 
> the invitation attempt has been done (success or failure), 
> the conference focus(?) may need to remove the entry from the 
> list to prevent the list from growing eternally. SIP 
> conference state event can be used  by the client to monitor 
> the progress of the attempt. Kick-outs could be done 
> similarly by managing the access control.
> 
> At least I didn't come up with any other type of 
> functionality that would be needed in CPCP. Based on this and 
> the desire to reuse existing protocols (XCAP is probably 
> included in many of the clients having CPCP in the future) I 
> came up with two options that I would be happy with:
> a) Do everything with XCAP by modeling the commands as data 
> manipulation, probably as explained above with mass-invitation case
> b) Do conf creation, parameter setting, ACL management with 
> XCAP, and leave mass-invitations/kick-outs to some other 
> protocol, which could be some very simple XML-RPC thing, or 
> indeed, SIP exploder mechanism.
> 
> Obviously, there is option c) not to use XCAP at all, but I 
> didn't come up with a compelling reason for that.
> 
> I believe that we just have to decide on which requirements 
> to keep and how we proceed with the protocol (XCAP or 
> something else) before the end of this year to have something 
> ready at least somewhat close to the charter deadlines.
> 
> Markus
>