Re: [Simple] FW: I-D Action:draft-rosen-simple-watcher-count-00.txt

["Brian Rosen" <[e-mail]>]

The authors have discussed having the list in the subscribe, and the delta
problem was the reason we left it as an XCAP managed document.  I think we'd
be amenable to exploring a more general solution.

I'm generally am in favor of more general purpose mechanisms, and I agree
that the general problem of knowing changing state of a set of URIs is a
general problem.  Of course, you never know for any particular problem if a
focused point solution really is better than a more general solution.  The
authors presented a point solution as a conversation starter, but I think
again we would be amenable to a more general purpose mechanism if that was
the consensus in the WG.  It probably generalizes beyond SIMPLE, but I
suspect we can keep the discussion going here for the time being.

We would like to keep the property that all it takes is one transaction for
the PS to tell the PNA about any changes that have happened (as opposed to
transaction per presentity), but I think we're pretty open on the semantics
of what the operation was doing.

I should also mention that we would even like to generalize the mechanism we
have proposed in a different dimension: a PNA may publish a number of
elements and would actually like to know if there are watchers for a
particular element rather than just the over-all watcher count.  The more
general the basic mechanism, the more realistic that kind of extension
should be.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: Wednesday, February 27, 2008 10:24 PM
> To: Brian Rosen
> Cc: [e-mail]
> Subject: Re: [Simple] FW: I-D Action:draft-rosen-simple-watcher-count-
> 00.txt
> 
> If I understand this correctly, there are two problems you are trying to
> address, and there are two pretty separate mechanisms in here:
> 
> 1. how does the PNA know which presentities to publish for, and this is
> solved by having the PNA subscribe to the new event package, and
> 
> 2. how does the PS know which presentities are served by a particular
> PNA, and that is what the xcap usage is for
> 
> 
> is that right?
> 
> It seems to me that an alternative way to handle #1 is a subscription.
> When the number if watchers for a presentity on the PS goes above zero,
> the PS SUBSCRIBEs to the PNA for that presentity (basically a back-end
> subscription). When it goes back to zero, it unsubscribes. To avoid
> having N subscriptions, one for each active presentity, it'd be ideal to
> have a single subscription with something like Uri-list services. In
> other words, there is one subscription and one dialog, and the list of
> URI to subscribe to is provided in the body of the SUBSCRIBE. We have
> specs for that today (draft-ietf-sip-uri-list-subscribe). The only
> problem is that spec doesn't allow you to change the list over time. We
> need that here. Including a delta in SUBSCRIBE refreshes is an easy
> solution, and hinted at in that spec.
> 
> There are a LOT of cases where one server is interested in the state of
> a whole lot of URIs, the set of which changes over time. Having an
> optimized way to do this with a single subscription usng
> uri-list-subscribe is, I think, a more general solution that would be
> really valuable.
> 
> The second problem is really a ROUTING problem. How do I find the server
> in my domain that has information on a particular event package for a
> particular user? There are lots of variations on this problem that all
> look the same. See draft-ietf-simple-intradomain-federation for another
> case - how do I find the one (of many) presence servers in my domain
> that serve the presence event package for a particular user? All of the
> mechanisms defined in that document for routing could be used here too -
> its the same problem. Your xcap proposal is basically using a central DB
> and writing it with xcap. I think it'd be worth exploring this problem
> space more generally.
> 
> -Jonathan R.
> 
> 
> 
> 
> Brian Rosen wrote:
> > Please take a look at this draft.  The authors would appreciate your
> > comments.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:i-d-announce-
> [e-mail]]
> >> On Behalf Of [e-mail]
> >> Sent: Monday, February 18, 2008 3:30 PM
> >> To: [e-mail]
> >> Subject: I-D Action:draft-rosen-simple-watcher-count-00.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>
> >> 	Title           : Optimizing Notifications for Presence Network
> >> Agents
> >> 	Author(s)       : B. Rosen, et al.
> >> 	Filename        : draft-rosen-simple-watcher-count-00.txt
> >> 	Pages           : 19
> >> 	Date            : 2008-02-18
> >>
> >> In large presence systems deployed in multiservice networks, presence
> >> information is often known by the network in addition to, or instead
> >> of the presentity's devices (endpoints).  Examples of such
> >> information include location and availability for various kinds of
> >> session establishment.  Even if devices know the information, the
> >> network often has more bandwidth and better scale to keep the
> >> presence server up to date.  A Presence Network Agent (PNA) can
> >> publish presence information to a Presence Server(PS).  When done
> >> large scale, the basic publish operation can be inefficient.  When
> >> the network has millions of subscribers, only some of which have
> >> watchers, blind Publish operations are unecessary.  WINFO can be used
> >> to determine watchers, but the efficiency of maintaining WINFO per
> >> subscriber, and the size of the messages involved, make that solution
> >> unattractive.  The PNA would prefer to have the Presence Server
> >> simply tell it when there was at least one watcher.
> >>
> >> This document describes an XML document stored on the PS by which the
> >> PNA maintains a list of subscribers it can provide presence for as a
> >> SIP event package that tells the PNA when the number of watchers for
> >> a presentity on the list (or a specific presence element for a
> >> presentity) goes from 0 to at least 1 or from 1 to 0.
> >>
> >> A URL for this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-rosen-simple-watcher-count-
> >> 00.txt
> >>
> >> To remove yourself from the I-D Announcement list, send a message to
> >> [e-mail] with the word unsubscribe in the body of
> >> the message.
> >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> >> to change your subscription settings.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login with the
> >> username "anonymous" and a password of your e-mail address. After
> >> logging in, type "cd internet-drafts" and then
> >> 	"get draft-rosen-simple-watcher-count-00.txt".
> >>
> >> A list of Internet-Drafts directories can be found in
> >> http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >> 	[e-mail].
> >> In the body type:
> >> 	"FILE /internet-drafts/draft-rosen-simple-watcher-count-00.txt".
> >>
> >> NOTE:   The mail server at ietf.org can return the document in
> >> 	MIME-encoded form by using the "mpack" utility.  To use this
> >> 	feature, insert the command "ENCODING mime" before the "FILE"
> >> 	command.  To decode the response(s), you will need "munpack" or
> >> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> >> 	exhibit different behavior, especially when dealing with
> >> 	"multipart" MIME messages (i.e. documents which have been split
> >> 	up into multiple messages), so check your local documentation on
> >> 	how to manipulate these messages.
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> >> implementation to automatically retrieve the ASCII version of the
> >> Internet-Draft.
> >>
> >> -----------------------------------------------------------------------
> -
> >>
> >> _______________________________________________
> >> Simple mailing list
> >> [e-mail]
> >> http://www.ietf.org/mailman/listinfo/simple
> 
> --
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [e-mail]
> http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple