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

[Jonathan Rosenberg <[e-mail]>]

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:[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