Consider the following rule uploaded that guides the policy for a particular event:
PUT http://xcap.home1.net/services/myservice/users/user1/ps.xml HTTP/1.1 User-Agent: IMS subscriber Date: Thu, 08 Jan 2004 10:13:17 GMT Content-Type:application/auth-policy+xml Content-Length: (…) <?xml version="1.0" encoding="UTF-8"?> <cr:ruleset xmlns="urn:ietf:params:xml:ns:pres-rules" xmlns:cr="urn:ietf:params:xml:ns:common-policy" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:new="urn:vendor-specific:foo-namespace" xsi:schemaLocation="urn:ietf:params:xml:ns:pres-rules pres-rules.xsd"> <rule id="1"> <conditions> <identity> <many/> </conditions> <actions> <pr:sub-handling>confirm</pr:sub-handling> </actions> </rule> </ruleset> This matches any authenticated user as per specs, but specifes that the server should place the subscription in pending state and await input from the presentity to determine how to proceed. Now assume that the presentity has subscribed to the watcher info template to be notified of subscriptions to its event package. In this case, the presentity will get a NOTIFY from the server that a new subscription is in pending state. At this stage, let's say the presentity wants to deny this pending subscription (lets say its from [EMAIL PROTECTED]) Should the new XCAP put actually modify "rule 1" to add an "except" clause, or should it just add a new rule at the end of the document that explictly blocks [EMAIL PROTECTED] ? I guess since the conditions in both the rules will apply and booleans and 10.2 of common-policy says the operation will be a logical OR, even if I were to explicitly add '[EMAIL PROTECTED]" as an exclusion for a new rule, the old rule will still match and therefore badboy will be allowed ? Finally, since I am using XCAP/auth-policy as the 'policy protocol' between my nodes, is there any way for the presentity to deny this pending xcap subscription without permanently adding it to the authorizatinon document ? (Consider it as some sort of a dynamic XCAP usage where I only deny it for this particular instance, but not permanently) In other words, it may be the case that the presentity wants to deny [EMAIL PROTECTED] for this particular subscription, but if it tries to subscribe again, it wants to decide if it will allow again or deny. I really want to avoid using one protocol for a dynamic policy and another for a (semi)static policy. regds arjun -- Arjun Roychowdhury _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
