Subject: RE: [Simple] Mobility of Buddy List

From: "Robert Osborne" <[email-masked]>
Date: Tue, 19 Jun 2001 10:48:55 -0700

Hi,

in your discussion of where the buddy list should be stored, you
state that it should be stored on a server, which makes sense. However
you state that it need NOT be stored on the presence of proxy server.
My question is, why would the buddy list not be stored on the presence
server, but be stored somewhere else?

If it was, the client needs to have some additionl intelligence:

* Which server should I connect to in order to retrieve my buddy list
* All devices would need to understand HTTP or whatever other protocol
  is required
* Will I be able to connect to that server, because of firewalls etc

It seems to me that this is adding in further complexity to do something
which should be relatively simple. I think something similar to what
Sean suggests make sense and ensure that the client only requires some
minor capabilites, compared to a completely new protocol support.

Rob O

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 9:14 AM
>To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel';
>[email-masked]'
>Cc: Mayerhofer Andreas A
>Subject: RE: [Simple] Mobility of Buddy List
>
>
>Hang on here... I think we are all talking about a few 
>different things.
>
>First off, in my mind, the definition of a "buddy list" is the set of
>presentities that a particular user is subscribed to. Lets 
>just make sure we
>are clear about that. Where this list is stored, and what happens to my
>subscriptions when I go offline, are two very different things.
>
>First off, where is it stored? One place is in the client. 
>This doesn't mean
>that its deleted when I log off; it would presumably be stored 
>on disk in
>some way. When the client app is restarted, it looks at that list and
>generates subscription refreshes for all of the users in the 
>buddy list.
>
>The drawback of storing it on the client is that it ties you 
>to a particular
>desktop. An alternative idea is to store it on a server in the 
>network (this
>need NOT be the same as the presence server or proxy server or anything
>else). So, when I start my client app, it goes to a web 
>server, say, and
>fetches my buddy list. Then, the client app sends a SUBSCRIBE 
>for all of the
>entries there. Now, I can sit down at any machine, and log in, 
>and then get
>my buddy list there. This was the motivation for our buddy list format
>proposal as part of last summer's SIMPLE proposal:
>
>http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt
>
>In this model, the buddylist is only stored on the web server, 
>but edited on
>the client. Now, if you go for the model where it can be 
>edited on the web
>server as well, you run into this synchronization problem. 
>Now, you need to
>keep interested entities (like my client app) aware of changes 
>to this list
>that are made. There, having an event package for the "state" 
>of my buddy
>list makes sense. I think this is what Sean is talking about.
>
>Now, a separate issue is what happens to my subscriptions when 
>I go offline.
>Well, the nice behavior is to unSUBSCRIBE. If you don't, the 
>presence server
>will eventually send a NOTIFY which either generates a 481 or 404, or a
>timeout, in which case the presence server would delete the 
>subscription.
>Please note that this is totally unrelated to the state of my 
>buddy list.
>This subscription is at the presence server of the presentity, 
>whilst the
>buddy list is stored at a server in the domain of the watcher. They are
>totally unrelated.
>
>Brian is talking about a different model still. In this model, 
>the buddy
>list isn't just stored and edited on the server, the server uses it to
>generate subscriptions directly. Effectively, the server becomes the
>watcher. If 10 people in its domain subscribe to some user 
>bob, the server
>sends only one SUBSCRIBE to bob. The server can then use this 
>to deliver
>notifications to the clients in its domain. The result is 
>aggregation, in
>that fewer messages need to be sent out to the presentities (1 
>instead of 10
>in the example). However, there is a serious security issue in 
>this model,
>in that the presentity has no way to know the end user which 
>is requesting
>the subscription.
>
>This approach, which is what I think Brian is talking about, 
>is discussed in
>the original sip for presence draft:
>
>http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt
>
>Thanks,
>Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>  
>-----Original Message-----
>From: Rosen, Brian [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 11:22 AM
>To: 'Sean Olson (EUS)'; 'Vencour Marcel'; 
>[email-masked]'
>Cc: Mayerhofer Andreas A
>Subject: RE: [Simple] Mobility of Buddy List
>
>
>You might get the LIST this way, but getting the updates may be
>problematic because all of your buddies may not be served by the same
>presence server.
>
>You could imagine a server proxy that would do this; the list 
>had a full
>subscription info, the proxy got the individual Notifies and 
>created one
>composite Notify.  A mobile client might like this a lot, but 
>it's less 
>interesting for "well connected" clients because little 
>aggregation occurs
>unless there are "popular" buddies where the proxy can use one Notify
>as input for many lists.
>
>Still, it's a worthy idea, and sounds pretty cheap.  Seems to me the
>only protocol impact is that you need a composite Notify that gets
>you all the presence information in the list as one message.
>
>Brian
>-----Original Message-----
>From: Sean Olson (EUS) [mailto:[email-masked]]
>Sent: Tuesday, June 19, 2001 9:47 AM
>To: 'Vencour Marcel'; [email-masked]'
>Cc: Mayerhofer Andreas A
>Subject: RE: [Simple] Mobility of Buddy List
>
>
>I was thinking a little about this. What 
>about the possibility of subscribing to 
>your buddy list? The buddy list could be 
>stored offline in, for example, a database. 
>A SUBSCRIBE request with Event: presence.targets (?) 
>would retrieve the static buddy list in a NOTIFY as 
>well as subsequent updates in future NOTIFYs. 
>The buddy list could also be tailored for the 
>client/terminal. 
>Comments? 
>/sean 
>-- 
>Sean Olson <[email-masked]> 
>Ericsson Inc. 
>>-----Original Message----- 
>>From: Vencour Marcel [mailto:[email-masked]] 
>>Sent: Tuesday, June 19, 2001 7:41 AM 
>>To: [email-masked]' 
>>Cc: Mayerhofer Andreas A 
>>Subject: [Simple] Mobility of Buddy List 
>> 
>> 
>>Hello everybody, 
>> 
>>I have a problem concerning the buddy list used in a presence 
>>service: The 
>>question is, where is the buddy list of the watcher stored 
>>when the watcher 
>>goes offline? If it is stored in a file/database at the 
>location of the 
>>watcher, then it is bound to the watcher's client, i.e. it 
>>does not move 
>>around with the watcher (here watcher means the person, not 
>>the client used 
>>by that person) when he uses different machines to do his 
>>watching. Thus the 
>>buddy list would have to be stored at the presence 
>>server/presence agent 
>>(PS). But in this case how can the watcher go offline without 
>>deleting his 
>>buddy list at the PS? If he goes offline without sending any 
>>unsubscribe 
>>then the PS would continue to send notifications to the 
>>watcher which of 
>>course is unnecessary overhead. On the other hand, if the 
>watcher goes 
>>offline and sends unsubscribes for all his buddies then the 
>>buddy list would 
>>be removed from the PS. 
>>The next question then is, what happens when the watcher goes 
>>online again? 
>>How can he send a subscribe without giving a buddy in the 
>>request line (just 
>>to tell that he is online and thus wants to receive 
>>notifications again)? 
>> 
>>Thanks in advance for an answer, M. Vencour. 
>> 
>>_______________________________________________ 
>>simple mailing list 
>>[email-masked] 
>>http://mailman.dynamicsoft.com/mailman/listinfo/simple 
>> 
>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Vasilis Polychronidis <[email-masked]>
Date: Wed, 20 Jun 2001 01:07:04 -0700

Hi Robert,
Please see my comments below:

Kind Regards,

Vasilis Polychronidis

> server, but be stored somewhere else?

Well I think buddy lists are application specific data.
In my IM application for example I can have a different
contact list (buddy list) than my e-mail contact list.
Multiple applications with different requirements will need access
to the presence data of presentities. The grouping of presentities into
contact lists is dependent on the specific application and i do not think
is practical of requiring all application that want to use the presence
service
to store their contact lists to the presence server.

> which should be relatively simple.

I do not think that is so simple. I think Contact Lists, PIMs,
synchronization, etc.
issues are not easy to solve in a standards based approach.

> I think something similar to what