Subject: [XCON] CPCP issue 7: Conference URIs assignment

From: [email-masked]
Date: Thu, 20 May 2004 18:40:34 +0300

Currently the ID says that the conference policy server must fill the conference URI(s), if a conference URI was not proposed by the client.

This problem is similar to that on the XCAP List usage where the XCAP server needs to fill in the list URI if the user did not suggest one. There is an ongoing discussion on the SIMPLE mailing list about a proposal where the server does not actually create a URI, but merely rejects the PUT request with a 409. The body of the 409 response would carry a list of suggested URIs. This looks like a solid proposal that will be adopted.

We can do a similar thing here for conference URIs. This leaves one open issue: Since a conference server may support, along with SIP, multiple session signalling protocols, does the server still create and populate the conference policy with additional URIs reflecting all the signalling protocols it supports that were not suggested by the creator?

My proposal is for the conference policy server to do so since the creator does not have the knowledge to know what signalling protocols a server supports in order to create a full list of URIs.

Comments?

Regards,
Hisham

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

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 13:12:47 +0300

ext [email-masked] wrote:
> Currently the ID says that the conference policy server must fill the
> conference URI(s), if a conference URI was not proposed by the
> client.
> 
> This problem is similar to that on the XCAP List usage where the XCAP
> server needs to fill in the list URI if the user did not suggest one.
> There is an ongoing discussion on the SIMPLE mailing list about a
> proposal where the server does not actually create a URI, but merely
> rejects the PUT request with a 409. The body of the 409 response
> would carry a list of suggested URIs. This looks like a solid
> proposal that will be adopted.
> 
> We can do a similar thing here for conference URIs. This leaves one
> open issue: Since a conference server may support, along with SIP,
> multiple session signalling protocols, does the server still create
> and populate the conference policy with additional URIs reflecting
> all the signalling protocols it supports that were not suggested by
> the creator?

Can a conference policy exits without a conference URI? I think it can, 
and theefore I think the server should only respond with a conflict if 
the user actually tries to PUT a conference URI. In other words, if the 
policy document contains no <conference-URI> elements in it, no conflict 
would occur. Strictly speaking, since the element is optional, the 
document would be valid anyway.

Secondly, I don't think the server should always offer all possible 
types of URIs to the client. At least I think the client should have a 
way to tell what kind of URIs it is interested in.

Like if the client attempted to PUT:

<conference-URI type="sip">sip:[email-masked]</conference-URI>

and the URI was not appropriate, the server would respond with a 409 and 
offer alternatives.

A PUT with:

<conference-URI type="h323"></conference-URI>
<conference-URI type="pots"></conference-URI>

would conflict with both types of URIs offered (meaning that an empty 
URI is not acceptable).

Cheers,
Aki

> My proposal is for the conference policy server to do so since the
> creator does not have the knowledge to know what signalling protocols
> a server supports in order to create a full list of URIs.
> 
> Comments?
> 
> Regards, Hisham
> 
> _______________________________________________ XCON mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/xcon