Subject: [XCON] CPCP issue 5: Conflicting rules in ACL

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

It is possible that a user creates conflicting rules in an ACL. Conflicting rules MUST NOT exist (e.g.  both allowed and blocked action is defined for same target).  It is the responsibly of the conference policy server (CPS) to ensure such conflicts do not occur.

Currently, it is not defined how the CPS would react. The obvious answer is that is returns an error using the protocol that is used to place the rule on the server.

In XCAP, this means sending a 409 error response to the PUT detailing what went wrong. Since the document defines the behaviour of XCAP as a possible protocol to carry and manipulate conference policies, the 409 error response will be used.

Any objections?

Regards,
Hisham

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

---

From: Aki Niemi <[email-masked]>
Date: Fri, 21 May 2004 10:35:09 +0300

Hi,

Seems to me there are two possibilities:

1) Use common-policy type rules, where conflicts are allowed and there's 
a clean way to recover from them

2) Design the schema such that for a given URI, there can only be a 
single entry. The way to do this would be to use the URI as a unique key 
in identifying a rule:

<ACL>
   <target uri="sip:[email-masked]>Allowed</target>
</ACL>

Note that there's still the possibility that conflicts occur, if a 
wildcarded <target> matches in addition to an exact one. But I think 
CPCP has rules for recovering from that happening.

Obviously, I'm personally in favor of 1), but 2) is fine as well.

Cheers,
Aki

ext [email-masked] wrote:
> It is possible that a user creates conflicting rules in an ACL.
> Conflicting rules MUST NOT exist (e.g.  both allowed and blocked
> action is defined for same target).  It is the responsibly of the
> conference policy server (CPS) to ensure such conflicts do not occur.
> 
> 
> Currently, it is not defined how the CPS would react. The obvious
> answer is that is returns an error using the protocol that is used to
> place the rule on the server.
> 
> In XCAP, this means sending a 409 error response to the PUT detailing
> what went wrong. Since the document defines the behaviour of XCAP as
> a possible protocol to carry and manipulate conference policies, the
> 409 error response will be used.
> 
> Any objections?
> 
> Regards, Hisham
> 
> _______________________________________________ XCON mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/xcon