Hi Simith & Meera: I don't think I have been able to express the situation coherently. Here is another try:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04.txt - represents a format to change the authorization policy RFC 3587 specifies a way for me to 'watch over' peoples subscribing to my event package What I need is this: A way in which an event server (ES), on receiving a SUBSCRIPTION from user "B" notifies "A" that "B" is trying to subscribe but does not authorize B till it hears back from "A". A cannot send an XCAP message to ES changing the policy for user "B" when it gets a NOTIFY from ES (Because A subscribed to the watcher info template for the event in question), because ES might have already authorized and accepted or rejected B, based on current rules uploaded at the ES. The environment that I am trying to deploy this solution is dynamic - it is impossible for A beforehand to know all the users who will subscribe to the event - hence subscriptions will be handled on a per subscription basis. However, A cannot host the event service by itself, because of certain constraints (the event in question has complex processing rules) and A is not capable of hosting such solutions , and therefore uses a network ES to host the event. So what I need is a way for A to tell ES, "manage the event for me, but ask me before you approve/deny any SUBSCRIPTION". In otherwords, I need a way to tie the two documents you mentioned above in one *synchronous* flow. regds arjun On 1/17/06, SiM <[EMAIL PROTECTED]> wrote: > > > > *Arjun Roychowdhury <[EMAIL PROTECTED]>* wrote: > > Hi, > RFC 3857 "A Watcher Information Event Template-Package...." defines a > mechanism by which a user can subscribe to subscription changes to a > particular event package. > > I am working on a situation where user 'A' is the 'moderator' of a > particular event package X that is hosted in a central presence server P. > A > subscribes to P with > event:X.winfo. > > Now when B subscribes to P for event X, P notifies A of this occurence. > However, 3857 provides no standard mechanism in which A can instruct/deny > this request (3857 leaves > this as 'out of scope'). > > Is there any draft / mechanism that allows an explicity 'allow / deny' > mechanim via SIP that A can use to instruct P to deny the subscription to > B > ? > > regds > arjun > > Hi Arjun, > I'am not sure whether you are looking for the below > Internet draft on Presence Authorization Rules, where a user can, express > his/her intent (Rule) to share presence information, to a particular > Subscriber . It uses XCAP , to manipulate the information in the Presence > Authorization Rules Document. > > > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-04.txt > > However, i do not know the status of the latest version of this ID. > > Cheers. > Simith > > > > > > Send instant messages to your online friends http://in.messenger.yahoo.com > -- Arjun Roychowdhury _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
