Hi Nagesh, thanks- this address my question. regds arjun
On 1/17/06, nagesh kumar <[EMAIL PROTECTED]> wrote: > > 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 > > > > -- Arjun Roychowdhury _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
