Subject: RE: [Simple] Mobility of Buddy List

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 19 Jun 2001 08:46:52 -0500

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
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 19 Jun 2001 11:22:25 -0400

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

Comments? 
/sean 

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

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Tue, 19 Jun 2001 10:55:49 -0600

Thanks for the excellent re-frame of the problem set, Jonathan.
Regarding Brian's aggregation model, how difficult would it be to allow
for aggregation by having the aggregator list the individual subscribers
in an aggregated SUBSCRIBE?

On the other hand, this could produce some unintended side problems. How
would one reject just one name on the list? How is the aggregator
trusted? (Or can we verify that any individual is/is not an aggregator
and redistributor?) 

I suspect that this aggregation/redistribution issue set is going to be
recurring in any discussion of presence systems and presence data
interchange so perhaps it's not worth tacking in this wg right now. On
the other hand, is it really possible to avoid it? 

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

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 10: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

interesting for "well connected" clients because little aggregation
occurs

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 19 Jun 2001 13:40:46 -0400

Yes, you have what I was talking about reasonably well represented.

I'll point out that the server can get more aggregation if it
is popular, in that, in theory, it can get one Notify from a
presentity that it then sends in aggregated Notifies to multiple
subscribers to its lists.  And yes, this makes the security problem
worse (since to be usefull, the real presentity has to actually
only send one Notify).

The security problem would have to be dealt with, but it seems to me
it's pretty straightforward - the client subscribes as usual with
the server proxying the subscription request, possibly including 
its own credentials.  The presentity would know the original 
subscriber, and the server.  The presentity could decline the 
subscription if it didn't trust the server.

You could even encrypt the presence information such that the 
server didn't know the contents - it's simply a relay for the 
presence information anyway.

Probably too complex for the first version of this stuff,
but thinking about proxying subscriptions, and structuring the
Notify so that an aggregate presence document can pass would
be usefull.

Brian

> Sent: Tuesday, June 19, 2001 12:14 PM
> presentities that a particular user is subscribed to. Lets 
> just make sure we
> 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
> 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
> 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
> 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
> 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
> 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
> watcher. If 10 people in its domain subscribe to some user 
> bob, the server
> 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

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 19 Jun 2001 14:15:22 -0500

My intention was to provide a mechanism to 
subscribe to changes in the status of the
buddy list itself and not necessarily the
presence status of the members of that
buddy list. This would support both 
retrieving of the initial buddy list (the first
NOTIFY) as well as any updates that were
made, perhaps by non-SIP mechanisms such
as a web interface. This is not intended to
solve the aggregation problem at all. That
is a whole different beast that requires much
more thinking. 
 
/sean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 01:52:40 -0400

> Sent: Tuesday, June 19, 2001 1:41 PM
> To: 'Jonathan Rosenberg'; 'Sean Olson (EUS)'; 'Vencour Marcel';

Right. Its important that this scenario be modeled as one where the server
which generates the notifies locally is a watcher itself. In SIP terms, its
a B2BUA. It receives multiple subscriptions from users in its domain, and
accepts them locally, as if it were a presence agent. To obtain the data it
needs to drive notifications, it subscribes itself (providing its own
credentials/keys to the presentity's presence agent) to the presentity. The
presentity would see that the subscription is from some domain server,
rather than individuals, and could decide, based on its own policies, about
whether to accept such an aggregated subscription or not. Assuming its
accepted, the server gets the notifications. It the generates notifications
back to its subscribers. It is NOT a proxy at all. 

Using this B2BUA model makes things vastly simpler than trying to
specifically support aggregation in this way. Andrew had suggested:

>Regarding Brian's aggregation model, how difficult would it be to allow for

>aggregation by having the aggregator list the individual subscribers in an 
>aggregated SUBSCRIBE?
>
would 
>one reject just one name on the list? How is the aggregator trusted? (Or
can we 
>verify that any individual is/is not an aggregator and redistributor?) 

These problems are all indicative of the difficulties of these hybrid
models. There are no easy solutions if this approach is taken. Keep the
basic SUBCRIBE/NOTIFY mechanism simple - some entity subscribes, its
authorized, and it gets notified. Build flexibility by varying what that
entity is, and what it does with the data once it gets it.

> subscription if it didn't trust the server.

The original subscriber is meaningless. There are other subscribers - why is
the first important? Its not. Furhermore, if encryption is used, the message
has to be encrypted with the public key of the SERVER, not of one of the
subscribers. The server will decrypt it, and then redistribute it by
re-encrypting it with the keys of each of the subscribers in its own domain.
Aggregation fundamentally implies a transitive trust relationship.

> presence information anyway.

Nope. WHose key would the presence data be encrypted with? As soon as the
server relays it to more than one person, it doesn't make sense. 

> Notify so that an aggregate presence document can pass would

Presence aggregation, as I describe it above, requires no special
standardization effort. Its a usage scenario.

Please note, though, that there are two types of aggregation:

1. multiple subscriptions for the same presentity, from subscribers in one
domain, are aggregated into a single subscription for that presentity from
the server for the subsciber's domain. Pictorally:

       Please view in a fixed-width font such as Courier.

  +----+
  |    |
  |    |
  +----+\
         \ SUB joe
          \
           \
            \     aggregator
             \                              joe's presence server
 +--+  SUB joe> +----+          SUB joe    +----+
 |  | --------->|    | ----------->        |    |
 +--+         > |    |                     |    |
            //  +----+                     +----+
           /
          /
        // SUB joe
  +----*
  |    |
  +----+

2. a single watcher subscribes to multiple presentities, but aggregates all
its subscribe requests into a single subscribe message to its local server.
For example, the user would send "SUBSCRIBE sip:[email-masked]".
That server generates individual subscriptions for each user in the
buddylist. Pictorially:

Please view in a fixed-width font such as Courier.

                                         /
                                        /
                                       /
                                      / SUB joe
                                     /
                                    /
                                   /
    +----+ SUB buddies     ------+/
    |    | ---------------|      |      SUB bob
    |    |                |      |---------------
    +----+                |      |
                          +------+ \
     user                           \
                          de-        \
                          aggregator  \  SUB ralph
                                       \
                                        \
                                         \
                                          \

These two cases are opposites, really. In the second case, you might want to
aggregate the notifications back to the user. This would require an
aggregate presence document which represents a group of users. Brian
mentions this above. Its something different, and I agree out of scope for
now.

-Jonathan R.

---

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Jun 2001 11:48:35 -0400

I have the view that I have a (potentially large) set of contacts,
a subset of whom I subscribe to their presence information.
It is beyond the SIMPLE charter to really deal with contacts per se,
and I don't want to force any implementation to mix contacts and
presentities, but I clearly want that to work, and work well.

Secondly, I don't think a "buddy list" is just a simple linear
list.  It has structure.  The issue is, of course, what is the
structure.  If we make buddy lists part of SIMPLE, we have to
define the structure of the list.  I don't think we are ready
for that.

So, I am leery of standardizing the concept of buddy list
	I think that in many cases the list is part of a larger
		database
	I think that the structure of the list is implementation
		dependent, we don't have enough experience to know
		what structures will be needed, and standardized
		simplistic structures tend to get in the way of
		future more elaborate structures

Brian

> From: Robert Osborne [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 11:17 PM
> To: Rosen, Brian; Vasilis Polychronidis
> Cc: Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel;
> [email-masked]; Mayerhofer Andreas A
> 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
> 
> 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
> 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
> 
> > 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
> > >
> > > >Sent: Tuesday, June 19, 2001 9:14 AM
> > > >that its deleted when I log off; it would presumably be stored
> > > >on disk in
> > > >desktop. An alternative idea is to store it on a server in the
> > > >network (this
> > > >entries there. Now, I can sit down at any machine, and log in,
> > > >and then get
> > > >In this model, the buddylist is only stored on the web server,
> > > >but edited on
> > > >keep interested entities (like my client app) aware of changes
> > > >to this list
> > > >Now, a separate issue is what happens to my subscriptions when
> > > >I go offline.
> > > >This subscription is at the presence server of the presentity,
> > > >whilst the
> > > >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,

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Jun 2001 12:02:22 -0400

I think that's a fine idea.  I agree we wouldn't do that
in SIMPLE.  Do you think IMPP could actually consider it?

Brian

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 1:25 PM
> To: Rosen, Brian
> Cc: 'Vasilis Polychronidis'; Robert Osborne; Jonathan Rosenberg; Sean
> Olson (EUS); Vencour Marcel; [email-masked]; 
> Mayerhofer
> Andreas A
> This seems like a topic where standardization may be useful, but
> certainly not required. After all, we do have a standard for address
> books that's followed reasonably widely, namely LDIF and the 
> underlying
> "Internet person object" out of LDAP. I suspect that a common
> interchange format may emerge that allows different applications to at
> least exchange (import/export) this information, as long as the major
> apps vendors play along. However, this would seem an appropriate topic
> for IMPP, not SIMPLE.
> 
> It would be useful to be able to subscribe to one's address book or
> contact list and get (in the LDIF update format) a list of 
> changes since
> the last update. I suspect that if IMPP or similar doesn't standardize
> this, a certain large software company will make this part of Snow
> breeze or whatever it's called.
> 
> "Rosin, Brian" wrote:
> >

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Thu, 21 Jun 2001 13:30:33 -0500

> If we have a common buddy list, what you get is the ability for a watcher to 
> switch clients.  That is not the problem you are worried about - you want
> any client to be able to see presence information for buddies who have their
> own choice of clients.  Specifying a buddy list format won't help that.

Actually, this is exactly the problem I am looking to solve. 
I want to be able to access the same buddy list from a 
wireless handset, my PDA, my laptop, my desktop at work, 
my SIP "PBX", etc.  I realize this may not be interesting
for everyone. I certainly don't expect this to be a
mandatory part of SIMPLE. I would just like to explore
the idea of a simple buddy list format (perhaps in IMPP
as Henning has suggested)

/sean

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Jun 2001 14:45:35 -0400

Well, I surely agree that if anything is done, it's an interchange issue,
and therefore
has to be done in IMPP and not SIMPLE.
 
I was okay with what Henning proposed, as long as the information is
structured
so that extensions are easy.  If you want to infer a buddy list from that, I
wouldn't
actually have a problem.  It will be interesting to see how your various
clients
deal with our LDIF.  
 
Brian

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 2:31 PM
To: 'Rosen, Brian'; 'Robert Osborne'; Vasilis Polychronidis
Cc: Jonathan Rosenberg; Vencour Marcel; [email-masked];
Mayerhofer Andreas A

/sean

---

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 22 Jun 2001 08:34:52 -0500

Jonathan,

Your second case (please see below) brings up a very interesting question -
do groups have presence? For instance you have said "SUBSCRIBE
sip:[email-masked]" - now what happens if some members are online
and others are offline? Is the group online or offline? 

It is my personal opinion that groups do *NOT* have presence, its only the
individual members of the group that have presence. Hence I strongly feel
that individual SUBSCRIBES have to be sent for each of the members, the
resulting NOTIFIES are used to indicate the presence of individual
presentities in your buddy list. 

Example:
mybuddies ====> note groups have no presence
	John <Online>
	Mary <Offline>
	Jack <Online>

Comments?
Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, June 21, 2001 12:53 AM
To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)'; 'Vencour
Marcel'; [email-masked]'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List
<<<<<<<snip>>>>>>>>>>>>>>>
2. a single watcher subscribes to multiple presentities, but aggregates all
its subscribe requests into a single subscribe message to its local server.
For example, the user would send "SUBSCRIBE sip:[email-masked]".
That server generates individual subscriptions for each user in the
buddylist. Pictorially:

                                         /
                                        /
                                       /
                                      / SUB joe
                                     /
                                    /
                                   /

-Jonathan R.

---

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Jun 2001 11:12:24 -0400

Right, this is why I suggest that to handle the current notion of groups, 
in fact the list is a simple list, and individual entries on the list have a
list of 
groups to which they belong.   Of course the entry may want a few 
more fields so that you can render it the way the client (and the user)
wants.
For example, you may want an icon, or a picture.  This is where the idea
Henning had of using the LDIF format to represent the presentity comes in.
 
So now the list is an LDIF file.
Hmmm, can you put an icon in an LDIF/LDAP entry?  You get a photo, but
I don't remember an icon.  Hmmmm, I smell an extension for inetOrgPerson.
There are a couple of fields I can see co-opting for group membership
but there isn't an exact match.  Is that another extension?
 
But, of course, a simple list may not be appropriate for all
implementations,
but we've covered that :)
 
Brian

-----Original Message-----
From: Sriram Parameswar [mailto:[email-masked]]
Sent: Friday, June 22, 2001 9:35 AM
To: 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)'; 'Vencour

Jonathan, 

Example: 

Comments? 
Regards, 

Sriram 

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 

                                         / 
                                        / 
                                       / 
                                      / SUB joe 
                                     / 
                                    / 
                                   / 

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

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 22 Jun 2001 09:43:32 -0700

I don't see that the structure of a document for describing the users
and groups that an application subscribes to has anything to do with
SIMPLE.

We should assume that an application has some way of determining the set
of presentities it wants to subscribe to.  But any assumption beyond
this becomes completely application specific.  There are so many
applications in use that contain information on people, and there's no
reason any of them wouldn't offer the ability to watch at least some of
those people.  If an implementer wants a "buddy list", that's up to them
to figure out.  If an implementer wants to create a URI for a group of
presentities and aggregate the presence state of those presentities into
the state of the group, that's fine too.  But it has nothing to do with
the protocol. They're just scenarios that can be implemented with the
subscription and authorization methods that are being discussed in
SIMPLE.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Friday, June 22, 2001 8:12 AM
To: 'Sriram Parameswar'; 'Jonathan Rosenberg'; Rosen, Brian; 'Sean Olson
(EUS)'; 'Vencour Marcel'; [email-masked]'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

Right, this is why I suggest that to handle the current notion of
groups, 

in fact the list is a simple list, and individual entries on the list
have a list of 

Henning had of using the LDIF format to represent the presentity comes
in.

I don't remember an icon.  Hmmmm, I smell an extension for
inetOrgPerson.

Brian

	-----Original Message-----
	From: Sriram Parameswar [mailto:[email-masked]]
	Sent: Friday, June 22, 2001 9:35 AM
	To: 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson (EUS)';
'Vencour Marcel'; [email-masked]'
	Cc: Mayerhofer Andreas A
	Subject: RE: [Simple] Mobility of Buddy List

	Jonathan, 

	Your second case (please see below) brings up a very interesting
question - do groups have presence? For instance you have said
"SUBSCRIBE sip:[email-masked]" - now what happens if some
members are online and others are offline? Is the group online or
offline? 

	It is my personal opinion that groups do *NOT* have presence,
its only the individual members of the group that have presence. Hence I
strongly feel that individual SUBSCRIBES have to be sent for each of the
members, the resulting NOTIFIES are used to indicate the presence of
individual presentities in your buddy list. 

	Example: 

	Comments? 
	Regards, 

	Sriram 

	__________________________________________ 
	Sriram Parameswar              Phone: 972-685-8540 
	Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563 
	Nortel Networks, Richardson USA  Email:
[email-masked] 

	-----Original Message----- 
	From: Jonathan Rosenberg [mailto:[email-masked]] 
	Sent: Thursday, June 21, 2001 12:53 AM 
	To: 'Rosen, Brian'; Jonathan Rosenberg; 'Sean Olson (EUS)';
'Vencour 
	Marcel'; [email-masked]' 
	Cc: Mayerhofer Andreas A 
	Subject: RE: [Simple] Mobility of Buddy List 
	<<<<<<<snip>>>>>>>>>>>>>>> 
	2. a single watcher subscribes to multiple presentities, but
aggregates all 
	its subscribe requests into a single subscribe message to its
local server. 
	For example, the user would send "SUBSCRIBE
sip:[email-masked]". 
	That server generates individual subscriptions for each user in
the 
	buddylist. Pictorially: 

	

	                                         / 
	                                        / 
	                                       / 
	                                      / SUB joe 
	                                     / 
	                                    / 
	                                   / 

	These two cases are opposites, really. In the second case, you
might want to 
	aggregate the notifications back to the user. This would require
an 
	aggregate presence document which represents a group of users.
Brian 
	mentions this above. Its something different, and I agree out of
scope for 
	now. 

	-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Jun 2001 13:13:02 -0400

> From: Theodore Havinis [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 4:26 PM
> To: Vencour Marcel; [email-masked]
> Hi Vencour,
> I don't think we should mix the presence service and its 
> services (provide
> notification of state  changes) with the capabilities of a specific
> application that helps you create a buddy-list and
> potentially may also support 'reachability/mobility' 
> capabilities which will
> mean that you will beb able to access the 'buddy list' from 
> any device.

Agree totally. IM is one potential application of presence, and the
buddylist is an application-specific (i.e., for IM) tool that allows
cross-device access to the application. However, its worth noting that there
are clases of data which are "cross-application subscriber feature data",
which means that they are data, created by a user, but specific to several
related applications. There are other apps, not IM, which may want to know
your "set of buddies". Therefore, having a standardized format provides two
benefits:

1. allows access to the IM application from many devices
2. allows other related applications to access this important piece of data

There are other examples of such datum. iCalendar is another example;
knowing the set of meetings I'm scheduled for is useful for a PC based
calendar application (like Outlook), but also useful for a call processing
language script in a proxy, which wants to filter calls when you're in a
meeting (and indeed, this integration is happening). One might imagine that
instead of embedding the date information in a CPL, a SIP servlet on a proxy
fetches my calendar information, and processes it in its native iCalendar
format, rejecting calls when I'm in a meeting. This wouldn't be possible if
iCalendar weren't a standardized format.

Because of the cross-application nature of the IM buddy list,
standardization is definitely useful. I agree its not a SIMPLE issue.
Whether its an IMPP issue is also a good question. Perhaps if there is
sufficient interest, we can have a BoF on this topic at the next IETF.

-Jonathan R.

---

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 22 Jun 2001 12:12:08 -0700

Hi,

I'd like to give a counter example: a group that has presence, where the 
desired behavior is that if one member of the group is online, then the 
group is online.

         sip:[email-masked]

I think the merge policy is up to the PA that is repsonsible for the merge.

thanks,
-rohan

At 06:34 AM 6/22/01, Sriram Parameswar wrote:

>Jonathan,
>
>Your second case (please see below) brings up a very interesting question 
>- do groups have presence? For instance you have said "SUBSCRIBE 
>From: Jonathan Rosenberg 
>[<mailto:[email-masked]>mailto:[email-masked]]
><http://www.jdrosen.net>http://www.jdrosen.net                      PHONE: 
>(973) 952-5000
><http://www.dynamicsoft.com>http://www.dynamicsoft.com
>
><http://mailman.dynamicsoft.com/mailman/listinfo/simple>http://mailman.dynamicsoft.com/mailman/listinfo/simple 
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Jun 2001 15:26:25 -0400

I would assert that sip:[email-masked]
is a presentity, and not a group. That presentity obtains it's presence 
status by subscribing to the individual member's presence and then 
advertises its presence according to whatever rules it has.
 
To me, groups are buckets I put people into, and a given person can 
be in more than one bucket (friend, co-worker, volleyball-team-member).  
If you want the sip:[email-masked]
presentity to define it's state based on all the people in the 
east-coast-call-center-agents group, fine.
 
Brian

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Friday, June 22, 2001 3:12 PM
To: Sriram Parameswar; 'Jonathan Rosenberg'; 'Rosen, Brian'; 'Sean Olson

Hi,

thanks,
-rohan

Jonathan, 

Example: 

Comments? 
Regards, 

Sriram 

-----Original Message----- 

                                         / 
                                        / 
                                       / 
                                      / SUB joe 
                                     / 
                                    / 
                                   / 

-Jonathan R. 

---

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 22 Jun 2001 13:24:56 -0700

Sounds reasonable.  The term "group-presentity" may be useful.   is there a 
formal definition for "group" now?

thanks,
-r

At 12:26 PM 6/22/01, Rosen, Brian wrote:
>>It is my personal opinion that groups do *NOT* have presence, its only 
>>the individual members of the group that have presence. Hence I strongly 
>>feel that individual SUBSCRIBES have to be sent for each of the members, 
>>the resulting NOTIFIES are used to indicate the presence of individual 
>><http://www.jdrosen.net>http://www.jdrosen.net 
>>PHONE: (973) 952-5000

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 22 Jun 2001 13:55:33 -0700

There doesn't need to be.  We just need to define how to work with a
presentity.  Whatever an implementation does to determine the state of
the presentity is up to the implementation (e.g. Brian's call center
example).

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Friday, June 22, 2001 1:25 PM
To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan Rosenberg';
'Sean Olson (EUS)'; 'Vencour Marcel'; [email-masked]'
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

Sounds reasonable.  The term "group-presentity" may be useful.   is
there a formal definition for "group" now?

thanks,
-r

 

Brian

-----Original Message----- 

Cc: Mayerhofer Andreas A 

Hi,

I think the merge policy is up to the PA that is repsonsible for the
merge.

thanks, 

-rohan

Jonathan, 

Example: 

        John <Online> 

        Mary <Offline> 

        Jack <Online> 

Comments? 

Regards, 

Sriram 

-----Original Message----- 

Cc: Mayerhofer Andreas A 

2. a single watcher subscribes to multiple presentities, but aggregates
all 

its subscribe requests into a single subscribe message to its local
server. 

buddylist. Pictorially: 

                                         / 

                                        / 

                                       / 

                                      / SUB joe 

                                     / 

                                    / 

                                   / 

    |    |                |      |--------------- 

    +----+                |      | 

                          +------+ \ 

     user                           \ 

                          de-        \ 

                          aggregator  \  SUB ralph 

                                       \ 

                                        \ 

                                         \ 

                                          \ 

These two cases are opposites, really. In the second case, you might
want to 

mentions this above. Its something different, and I agree out of scope
for 

now. 

-Jonathan R. 

--- 

simple mailing list

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 22 Jun 2001 17:36:22 -0400

-----Original Message-----
>From: Robert Brown [mailto:[email-masked]]
>Sent: Friday, June 22, 2001 4:56 PM
>To: Rohan Mahy; Rosen, Brian; Sriram Parameswar; Jonathan Rosenberg; Sean
Olson >(EUS); Vencour Marcel; [email-masked]
>presentity.  Whatever an implementation does to determine the state of the 
>presentity is up to the implementation (e.g. Brian's call center example).

There are two cases of what it means to subscribe to a group:

1. The group is a regular presentity, in that it is indistinguishable from a
presentity thats a single person. It has an aggregated status that masks the
status of individuals within the group. How the state of this
group-presentity is determined, and how the set of users in the group are
determined, is orthogonal and has no impact of SIMPLE. We don't need to do
any work to support this model. There are many, many good uses for these.
For example, a presentity can be sip:[email-masked], and this
presentity is available so long as any customer support person for
company.com is available. 

2. The group is not a regular presentity. The set of people within the group
are visible at the individual level. That is, I can get a NOTIFY from
sip:[email-masked], and these notifies contain state for the individuals
within that group. Why do this? The benefit is to avoid the overhead of
individual refreshes. I can SUBSCRIBE to sip:[email-masked], and this
causes the foo.com server to generate SUBSCRIBEs for all the users on my
buddy list. This does require modest standardization, in the sense that we
need to allow for a NOTIFY for a presentity to contain a presence doc for
another presentity, and possibly even contain multiple presence docs.

-Jonathan R.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Friday, June 22, 2001 1:25 PM
To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan Rosenberg';

thanks,
-r

 

---

---

From: Subir Saha <[email-masked]>
Date: Fri, 22 Jun 2001 15:00:02 -0700

The idea of a group can also be help full when I have quite a few
presentities : cell phone, sip phone, PC and couple of games. All these
individually send presence information to my presence server as a group
[email-masked]. So my complete presence info can be made available
by a single subscription to the watcher. 

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

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, June 22, 2001 2:36 PM
To: 'Robert Brown'; Rohan Mahy; Rosen, Brian; Sriram Parameswar;
Jonathan Rosenberg; Sean Olson (EUS); Vencour Marcel;
[email-masked]
Cc: Mayerhofer Andreas A
Subject: RE: [Simple] Mobility of Buddy List

-----Original Message-----

-Jonathan R.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Friday, June 22, 2001 1:25 PM
To: Rosen, Brian; 'Rohan Mahy'; Sriram Parameswar; 'Jonathan Rosenberg';

thanks,
-r

 

---

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 22 Jun 2001 18:03:04 -0400

Doesn't this seem to be a pretty small benefit for a bunch of
standardization (you need a way to specify the group, and a way
to modify the list,...).  It only helps a refresh (a watcher 
wouldn't get much gain).

Could we make this a simpler optimization - something where 
you ask for multiple refreshes in a single message and get
multiple docs back?

Brian

> Sent: Friday, June 22, 2001 5:36 PM

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 22 Jun 2001 15:15:58 -0700

> From: Subir Saha [mailto:[email-masked]] 

If it helps to think of this as grouping, sure, that's a valid
conceptual model.  But it is purely an implementation decision.

A presence agent (server) may support subscription to a presentity
representing a person.  And it may represent that presentity's state as
an aggregation of the presence states of individual devices owned by
that person.  But this is just the functionality of that particular
implementation.

---

From: "Robert Brown" <[email-masked]>
Date: Fri, 22 Jun 2001 15:34:41 -0700

> another presentity, and possibly even contain multiple presence docs.

This is an interesting proposal.

I do have a concern that in deployments that involve the common use of
large groups, real-time group expansion could place a lot of load at a
single point in the network and limit scale.  A lot of email users are
familiar with distribution lists and equate them conceptually to groups.
Email servers can get away with this because they don't have a real-time
delivery expectation and can afford to store and expand.

I'm also wondering about the complexity of state management logic
involved - for example will we find this to be of similar complexity to
forking INVITE?

BTW, has a similar discussion happened for other methods relating to
groups?  E.g. send IM to a group, start a conference call with a group,
etc.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Jun 2001 03:45:07 -0400

> Sent: Friday, June 22, 2001 6:35 PM
> To: Jonathan Rosenberg; Rohan Mahy; Rosen, Brian; Sriram Parameswar;
> Sean Olson (EUS); Vencour Marcel; [email-masked]
> Cc: Mayerhofer Andreas A
> > 2. The group is not a regular presentity. The set of people 
> within the
> > group
> > causes the foo.com server to generate SUBSCRIBEs for all 
> the users on
> my
> > need to allow for a NOTIFY for a presentity to contain a 
> presence doc
> for

I suppose this could be an issue, yes. However, it seems no different than
the general scaling issues with any sort of network server. The standard
techniques of load balancing, coupled with the benefits of Moore's law, are
on your side as always. I think its up to the operators of these servers to
make sure they are big enough to handle whatever groups they are trying to
handle.

> involved - for example will we find this to be of similar 

Goodness, no. The group server in this model is more like a B2BUA, which is
conceptually (and programming-wise) simpler than a forking proxy. There is
certainly state here. For any given group foo, the server will need to
maintain the list of subscribers to foo and their associated state, and also
maintain the subscriptions to the users comprising the group foo, and their
state.

> to modify the list,...).  It only helps a refresh (a watcher 

I think that group management would be outside of the scope of our concerns.
Typically, web interfaces would be used, voice browsers, or whatever, none
of which require standardization. Specifying groups is easy; they are just
SIP URLs that you know are groups. Much like for SIP conferences; its a
request URI that just happens to be a conference resource.

> you ask for multiple refreshes in a single message and get

That was the idea; the SUBSCRIBE has a group in the R-URI, and this results
in NOTIFYs that contain presence docs from different users. I was not
proposing that there is some way to merge the presence docs from the users
in the group.

> groups?  E.g. send IM to a group, start a conference call 

IM-ing to a group has been discussed a bit. When you take the approach of
IM-as-a-stream, as has been proposed (and I think there was consensus for),
group conferences are really easy, as they are done identically to the way
they are done for regular INVITE-initiated sessions. There are many
mecahnisms for conferencing in SIP, documented in:
http://www.jdrosen.net/papers/draft-rosenberg-sip-conferencing-models-00.txt

All of these would then work for IM. If you work with IM as a standalone
message, conferencing becomes more complex, and then you need to explicitly
think about how things like distribution lists might work, and define
support for them.

-Jonathan R.
---