Thanks Binu, So if a particular policy document has a <sub-handling>confirm</sub-handling> what mechanism does one use to confirm or deny ? All the documents I read till now leave it as an implementation specific detail without any further explanation.
regds arjun On 2/13/06, Binu K S <[EMAIL PROTECTED]> wrote: > > Hi Arjun, > > Sub-handling in an enumerated integer type (not Boolean). In this > case, the minimum value from all applicable rules will apply. Since > block has a value of 0 and confirm has 1, the new block rule will > apply. This won't work if you inserted a new allow rule though since > 'allow' has a value of 3. (Section 3.2.1 > > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04.txt > ) > > I don't see a way for you to add rules that apply for a specific > subscription attempt. One possibility would be to remove the presence > rule you just added as soon as you get a winfo event indicating that > the pending subscription has been rejected. A subscription attempt > after this will have to be confirmed. This approach will have its > limitations due to race conditions. If the next subscription attempt > is made between the winfo notification for the rejection and the rule > change being affected at the server, it will be rejected. Also, if you > add a rule to allow a subscription from a user, the rule will have to > stay until that subscription terminates. > > Regards, > Binu > > On 2/10/06, Arjun Roychowdhury <[EMAIL PROTECTED]> wrote: > > 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 > > > -- Arjun Roychowdhury _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
