Hi Arjun,
Sub-handling in an enumerated integer type (not Boolean). In thiscase, the
minimum value from all applicable rules will apply. Sinceblock has a value of 0
and confirm has 1, the new block rule willapply. This won't work if you
inserted a new allow rule though since'allow' has a value of 3. (Section
3.2.1http://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 specificsubscription
attempt. One possibility would be to remove the presencerule you just added as
soon as you get a winfo event indicating thatthe pending subscription has been
rejected. A subscription attemptafter this will have to be confirmed. This
approach will have itslimitations due to race conditions. If the next
subscription attemptis made between the winfo notification for the rejection
and the rulechange being affected at the server, it will be rejected. Also, if
youadd a rule to allow a subscription from a user, the rule will have tostay
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>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
