Subject: [Simple] Centralize Presence Server...

From: Subir Saha <[email-masked]>
Date: Thu, 21 Jun 2001 09:30:27 -0700

Reading through the SIMPLE drafts and mailing list, it looks like a
centralize presence server is not must. Even the value of such an entity is
not well understood. However I see lot of vendors are working on a
centralized presence server in a big way. 
Any comments?

Subir Saha, Ph.D.
Sr Product Architect
LongBoard Inc.

-----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: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 21 Jun 2001 12:36:03 -0600

Initial implementations for simplicity's sake may use a single
centralized presence server. The longer-term reality will be closer to
domains of presence information with the possibility for multiple
aggregators and distributors even within a given domain. There are a lot
of possible topologies for the flow of presence information and the
centralized model is only one of them. When a critical mass of presence
service information is available, things will get decentralized in a
hurry.

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Subir Saha [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 10:30 AM
To: [email-masked]'
Subject: [Simple] Centralize Presence Server...

Reading through the SIMPLE drafts and mailing list, it looks like a
centralize presence server is not must. Even the value of such an entity
is
not well understood. However I see lot of vendors are working on a
centralized presence server in a big way. 
Any comments?

Subir Saha, Ph.D.
Sr Product Architect
LongBoard Inc.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 9:14 AM
To: 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour Marcel';

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:

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:

Thanks,
Jonathan R.

---
  
-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 11:22 AM
To: 'Sean Olson (EUS)'; 'Vencour Marcel';

interesting for "well connected" clients because little aggregation
occurs

Brian

---

From: "Rawlins, Diana" <[email-masked]>
Date: Thu, 21 Jun 2001 22:52:40 +0000

A nice feature of a presence server is that it helps scales mobility
scenarios and permits a single user oriented uri to be used to locate the
presentity's actual contact address. For example, one day I  "present
myself" on my PDA and the next I may register and "present" my  presence
application from a desktop with an entirely different contact address. The
presence server accepts the subscribe from the watcher addressed to the user
and when the presentity for the user become available the contact address
information is used by the presence server to facilitate the exchange of
presence data between the watcher and presentity --- authorization and
access being a prerequisite for the presence exchange.
 
-Diana
 
-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 1:36 PM
To: Subir Saha; [email-masked]
Subject: RE: [Simple] Centralize Presence Server...

Initial implementations for simplicity's sake may use a single centralized
presence server. The longer-term reality will be closer to domains of
presence information with the possibility for multiple aggregators and
distributors even within a given domain. There are a lot of possible
topologies for the flow of presence information and the centralized model is
only one of them. When a critical mass of presence service information is
available, things will get decentralized in a hurry.

--Andy Zmolek 

            [email-masked] 
              +1 720 444 4001 

-----Original Message----- 
From: Subir Saha [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, June 21, 2001 10:30 AM 
To: [email-masked]' 
Subject: [Simple] Centralize Presence Server... 

Subir Saha, Ph.D. 
Sr Product Architect 
LongBoard Inc. 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<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 

http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt
<http://www.jdrosen.net/papers/draft-rosenberg-impp-buddylist-00.txt>  

http://www.jdrosen.net/papers/draft-rosenberg-impp-presence-00.txt
<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 <http://www.jdrosen.net>                       PHONE:
(973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
  
-----Original Message----- 
From: Rosen, Brian [ mailto:[email-masked]
<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 

Brian 
-----Original Message----- 
From: Sean Olson (EUS) [ mailto:[email-masked]
<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 

>From: Vencour Marcel [ mailto:[email-masked]
<mailto:[email-masked]> ] 
>Thanks in advance for an answer, M. Vencour. 
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>  
_______________________________________________ 
simple mailing list 
[email-masked] 
http://mailman.dynamicsoft.com/mailman/listinfo/simple
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>  
_______________________________________________ 
simple mailing list 
[email-masked] 
http://mailman.dynamicsoft.com/mailman/listinfo/simple
<http://mailman.dynamicsoft.com/mailman/listinfo/simple>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jun 2001 12:27:06 -0400

Just to be clear, the SIMPLE group is not specifying architectures for
presence. It is not our role to dictate to providers how many presence
servers they have, how they are distributed, or even whether there is one.
The protocol is flexible enough to operate in a pure peer-to-peer mode
without any network servers (the presence agent function resides in the
clients), or with a single centralized server for the known universe.

-Jonathan R.

---
  
-----Original Message-----
From: Rawlins, Diana [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 6:53 PM
To: 'Zmolek, Andrew (Andrew)'; Subir Saha; [email-masked]
Subject: RE: [Simple] Centralize Presence Server...

-Diana