Hi Arjun - 3GPP specifies an architecture, Presence server has the XCAP server function co-located with it. (Refer to Section 6.2.2 in 24.141). In this architecture, the user will update his authorization policies using XCAP on getting NOTIFY of an impending presence subscription and presence server appropriately responds with NOTIFY to the subscriber. (Note that this is not the same as immediate NOTIFY).
Alternatively if they are not co-located, PS can subscribe to the XML file differences using http://www.jdrosen.net/papers/draft-ietf-simple-xcap-diff-02.txt. However, in this configuration XCAP server needs to be SIP aware to support SUBSCRIBE/NOTIFY. This is what is specified in OMA and you can refer to " Presence SIMPLE Architecture Document" of OMA. Regards Nagesh On 1/17/06, Arjun Roychowdhury <[EMAIL PROTECTED]> wrote: > > Sudhir, > Thanks. However, this is not the scenario I am talking about. In this > case, > A publishes its event package to Presence server P. If B wants to > subscribes > to A's event package, it subscribes to P (which acts on behalf of A). > > Now, the only way A knows if B is subscribing to its event package is to > subscribe using watcher info. The RFC provides a way in which P can NOTIFY > A > that B is subscribing to the package. However, it does not discuss a > mechanism where A can "instruct" P to deny the subscription (in other > words, > P does not have enough authentication information to allow this particular > user B). > > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
