Subject: RE: [Simple] Mobility of Buddy List

From: "Robert Osborne" <[email-masked]>
Date: Wed, 20 Jun 2001 20:16:47 -0700

I think we are discussing two different items here. As a user
I have a set of other users whose presence information I am
interested in, irrespective of which client or device I am
using.

So when I am sitting at my desktop I am interested in the
presence information for my friends and colleagues. When I
am at home using my laptop finishing up a spec, I am still 
interested in the presence information for my friends and 
colleagues. Therefore as these are two different devices I
do not wish to enter in the presentity information twice,
but rather have the buddy information available no matter
which device I am using.

As for contacts, by which I assume you mean something similar
to Outlook contacts where the address, phone number, email
etc is stored, then I partially agree that contacts and
presentities are different things. It is likely that the list
of presentities I am interested in is a subset of my contacts,
but not guaranteed. However, I am unsure what this has to do
with the fact that the presentities I am interested in should
be stored on a central SIP server, and available no matter which
device or application I am using.

Rob O

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 5:25 AM
To: 'Vasilis Polychronidis'; Robert Osborne
Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel;
[email-masked]; Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

I agree.  The basic contents of the lists are probably common 
(presentity), but the structure is not.  Consider the standard
AOL Instant Messenger list already has a two dimensional structure,
and it is easy to imagine more elaborate structures for the lists.
As Vasilis points out, contact information and "buddy lists" may
be combined, and we aren't going to standardize contacts are we?

In our implementation, we plan to have more information in our content
entries beyond just the presentity, so a standardized list format
would be problematic.

It is always possible to leave the list as an XML blob, but then 
I don't think anyone gets any advantage out of that.

Brian

> -----Original Message-----
> From: Vasilis Polychronidis 
> [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 4:07 AM
> To: Robert Osborne
> Cc: Jonathan Rosenberg; Rosen, Brian; Sean Olson (EUS); 
> Vencour Marcel;
> [email-masked]; Mayerhofer Andreas A
> Subject: Re: [Simple] Mobility of Buddy List
> 
> 
> Hi Robert,
> Please see my comments below:
> 
> Kind Regards,
> 
> Vasilis Polychronidis
> 
> Robert Osborne wrote:
> 
> > 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?
> 
> 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.
> 
> >
> >
> > 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 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
> > 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
> > >
> > _______________________________________________
> > simple mailing list
> > [email-masked]
> > http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 
> 
>

---

From: Vasilis Polychronidis <[email-masked]>
Date: Wed, 20 Jun 2001 22:33:48 -0700

Hi Robert,
I think we are in agreement here:
1. There are primary two types of contact lists (buddy lists):
    1.1 Server/network based = Contact lists are stored somewhere in the
network and
          provide device independence. This is exactly how many current IM
services are
          functioning today. For example when using a server based IM system
I can log on
          via my mobile client, desktop or "Web/HTML" client and still view
the same contact list (buddy list)
          regardless of the access method.
    2.1 Client based = Contact lists are stored on the client side. Of
course in this case when you change client
          or device, etc. in principle you do not view the same contact
list. In order to sync up the
          different contact lists you will need some king of peer to peer
sync protocol between the various
          clients, devices, etc.
2. There are and will be various applications besides IM that will use the
presence service.
    These applications in principle will have different structure and
possible different set of elements that
    comprise their associated contact lists.
    For example I can have:
    2.1 An IM application where my contact list is comprised of a set of
"friends", coworkers, etc.
    2.2 A gaming application (that is provided by a different vendor than
the IM one) that has a different
          contact list (structure, elements, etc.)
    Both applications are using the Presence Service (subscribing and being
notified of the current status of various
    presentities) but they have completely different contact lists.
    Mandating of storing all contact lists  (of the different apps) into a
single server i think is at best impractical.

As you correctly pointed out 1 is a different item than 2.
Please see additional comments below:

Kind regards,

Vasilis Polychronidis

> but rather have the buddy information available no matter

So in this case you should choose a provider that offers an IM system
with server/network based buddy lists (device/ access independent).

> As for contacts,

I use Contact list and Buddy list as equivalent terms. .
Please feel free to replace any reference to Contact list with Buddy list in
this thread.
If you want to be more precise Buddy List = a form of Contact List + status
info.

> by which I assume you mean something similar

Because as a service provider I may want to offer additional apps (different
than IM)
that make use of the presence data and I do not want to be forced to choose
the same
vendor for both my IM and the additional presence enabled apps.