Subject: RE: [Simple] Mobility of Buddy List

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Jun 2001 12:13:33 -0400

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 
>

---

From: Nicolas Dramais <[email-masked]>
Date: Fri, 01 Feb 2002 16:52:02 +0100

Hi all,

I would like to know what the status is now with mobility of buddy 
lists. I'm referring to the thread created on this topic in June 2001.
I agree that draft-rosenberg-impp-buddylist-00.txt addresses one piece 
of the puzzle (even though it has expired now), being the storage and 
retrieval of buddy lists to and from a presence server. However, in 
order to have my presence server doing the dirty work of subscribing to 
each individual entry in my buddy list on my behalf, yet another piece 
is missing : some sort of composite Notify bringing back to the watcher 
presence statuses of all individual entries in my list residing at the 
server.

Is there enough interest on this list to re-activate the above buddylist 
draft as a SIMPLE work item ?
Is there enough interest on this list to define and standardize this 
composite Notify ?

Or is there a consensus that this puzzle is more an implementation matter ?

Thanks,
Nicolas.

-- 
Nicolas DRAMAIS
Indigo Software
"We join the dots"
~~~~~~~~~~~~~~~~~~~~~~
50, rue Wiertz
1050 Brussels
Belgium
Phone: +3222350952
Fax: +3222802676
mailto:[email-masked]
~~~~~~~~~~~~~~~~~~~~~~
http://www.indigosw.com

---

From: Nicolas Dramais <[email-masked]>
Date: Mon, 04 Feb 2002 11:32:06 +0100

All,

I hadn't seen that a new draft called 
draft-rosenberg-simple-buddylist-package-00.txt had been created to 
address part of my concern below : to have my presence server, acting as 
a BLSS, ie. do the dirty work of subscribing to each individual entry in 
my buddy list on my behalf. It looks fine.
This new draft also approaches the composite Notify mechanism by 
suggesting either multipart-body Notify or single-body Notify containing 
a list or lists of my buddies' presence data.
I think the draft should go further and specify the preferred way of 
using composite Notifies for interop' concerns.

However, even though I agree the transport mechanism to store, modify 
and retrieve buddy lists onto the server is to be performed with other 
protocols than SIP, SIMPLE should  nevertheless cite the preferred 
solution for doing it; for instance HTTP or SMTP; and thus should stay 
in the scope of SIMPLE. This is to increase interoperability among 
different SIMPLE implementation vendors.
As such, whatever the preferred transport method, a 
transport-independent buddylist xml format is necessary and should be 
agreed upon. Accordingly, as mentioned below, I think it would be a 
great idea to reactivate the standardization and agreement of such a 
format like attempted in draft-rosenberg-impp-buddylist-00.txt.

We suggest choosing for HTTP as transport carrying xml formatted 
buddylist documents for storing, modifying and retrieving buddy lists to 
and from  a presence server.

Reactions welcome.
 
Thanks,

Nicolas.

Nicolas Dramais wrote:

> order to have my presence server doing the dirty work of subscribing 
> to each individual entry in my buddy list on my behalf, yet another 
> piece is missing : some sort of composite Notify bringing back to the 
> watcher presence statuses of all individual entries in my list 
> residing at the server.
>
> Is there enough interest on this list to re-activate the above 
> buddylist draft as a SIMPLE work item ?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 05 Feb 2002 17:28:51 -0500

> format like attempted in draft-rosenberg-impp-buddylist-00.txt.

There is a general issue here about architectures vs. protocols. IETF
has traditionally not specified architectures. It has left that work to
other fora, such as 3gpp, packetcable, and so on, and has tried (without
as much success as they would like) to have these groups feed
requiremetns back to ietf for needed extensions.

The mechanisms for managing the buddy list fit into this category. It is
clear that there are multiple solutions for this, and that in some
cases, no standard is needed (a web page, for example, would allow a
user to edit there buddy list). 

So, IETF could not say "this is the mechanism you use for managing a
buddy list in a presence architecture". It could offer a standard for
such, and other people could specify an architecture that says "use
this". The question that needs to be asked, then, is how should such a
standard look?

We have debated this many times, without much resolution. It really is a
pressing issue, since there needs to be something beyond web pages for
several of these. We actually have several things which all fit into
this general space:

1. management of buddy lists - adding/removing/viewing members
2. management of explicit presence state; telling the PA that I'm
available, or not, or what have you. Also known as "publish".
3. management of authorization policies - telling the PA whether or not
users A or B can subscribe or not. These can be simple (yea/nea) or
arbitrarily complex.

I would argue we should solve these all in the same way, and I think
there is little dispute on that. Now, are these SIP, or something else?
Well, the only way to answer that in general is to look at requirements.
Steve Donovan has published some nice requirements already on this, in:

http://search.ietf.org/internet-drafts/draft-donovan-publish-requirements-01.txt

I happen to be of the personal opinion that SOAP works nicely for this.
They are all pure client/server, all transactional data manipulation or
query operations. They may involve large content (what is my buddy
list?). Furthermore, I can see cases where there might even be more than
one solution. Authorization, for example, is awfully complicated. Itd be
nice to have a really simple yea/nea interface, but more complex ones
that we can evolve over time. Since, with SOAP, one can simply define a
new WIDL for these as needed, its a bit easier.

The main arguments I have heard in SIPs favor are:

1. its already there in the end device,
2. its easier to tie in authentication
3. less UA configuration

Regarding point (1); this is one of those "binary v. text" things which
is nearly impossible to resolve, since it is not a techincal argument
per se. I think many handsets have http in them already. XML will be
there for PIDF. So, I don't know how big an issue it is for real.
Regarding (2), if you are allowing a user to manipulate these things via
a web page, you are already needing to solve the issue of tying in your
authentication DB with a web application. So, I don't see the real issue
per se. Regarding (3), the UA would need to be configured with the soap
server to talk to. If SIP were used, presumably the PUBLISH request, or
whatever it is, would go to the outbound proxy, avoiding the need to
have an additional piece of configuration. This is more of a system
issue, since for some architectures such configuration mechanisms likely
exist (wireless handsets), and in others they dont (PCs), and there
certainly is no standard way to do configuration of end devices at this
time.

SHould there be agreement on this direction (and I know there is not at
this time), the question is whether we would specify the widl here and
then submit the rfc to w3c, or if someone just goes and comes up with
one and registers it. I dont think there is precedent for that at all;
that might argue in favor of a SIP solution since the process is a bit
more known.

ANyway, I would really, really like to resolve this, since these
components are needed for many architectures, and they are the hangup to
a complete solution at this point.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Sean Olson <[email-masked]>
Date: Tue, 5 Feb 2002 16:05:26 -0800 (PST)

I also favor a SOAP solution for this problem space.
What is the right way forward from a process point
of view? Is this in the charter for SIMPLE, or 
can this work be safely labelled as out-of-scope?
I'm not sure W3C is the right place for this work
either, but it seems like a better fit than the
IETF.

my two cents,
sean

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

---

From: Tony Hansen <[email-masked]>
Date: Tue, 26 Feb 2002 17:31:40 -0500

Here are some ideas on how this could play out within the IETF.

One of the documents being put out in the SIP WG is SIP Call Flow
Examples. It shows how the SIP protocol should be used in an IP
Telephony service.

Another effort in the IETF is the Voice Profile for Internet Messaging
(VPIM) working group. That group has been figuring out how to do voice
messaging (for voice mailboxes) using existing protocols, such as SMTP
and IMAP. Where the existing protocols were lacking, they also worked on
filling in the gaps, either within the VPIM WG or in conjunction with
other working groups (e.g., imap-ext). Note: the VPIM WG was originally
formed due to input from an external organization, the EMA, but the work
has all been done here in the IETF.

The problem we're facing here in SIMPLE seems to be in the same
category, and the solution may be similar. It appears that what is
required is a profile for an instant messaging service saying how it
should pull together the different piece parts to form a coherent whole.

I'm convinced we can solve this problem. Getting feedback from the
industry is absolutely useful in the process, but I think the work needs
to happen here, in the IETF. And I'm willing to work on it.

Comments? Should something like this go on the SIMPLE agenda for
Minneapolis?

	Tony Hansen
	[email-masked]

---

From: Nicolas Dramais <[email-masked]>
Date: Wed, 27 Feb 2002 11:40:36 +0100

Hi Tony,

please see my comments below.

Nicolas.

>Examples. It shows how the SIP protocol should be used in an IP
Indeed, why not do the same kind of "informational" Call Flow Examples 
document for showing how SIMPLE should be used in deploying a SIP for 
Presence service (showing the use of SOAP transported by SIP or HTTP for 
buddy list mobility and list management, presence state and 
authorization management) ?

>should pull together the different piece parts to form a coherent whole.
Well, I guess like many other people on this list, we believe that SIP 
for Presence can be applied to a much broader scope of applications than 
just for an IM service.
Hence, we want to separate very much Presence from IM.
So I' d rather name it Presence service instead of IM service.

>to happen here, in the IETF. And I'm willing to work on it.
As mentioned below, we too want to insure a minimum of Presence service 
interoperability among different SIMPLE implementation vendors; 
especially for mobility of buddy lists and for the management issues 
Jonathan pointed out below.
We are also willing to contribute to it, being on the IETF list or the W3C.

Regards,
Nicolas.

>>this time),
>> the question is whether we would specify the widl here and

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Mar 2002 01:52:31 -0500

> should pull together the different piece parts to form a coherent whole.

Well, there are two parts.

Part one, is to specify the pieces, and to make sure they are all there.
Part two, is to specify an architecture that puts them together as a
whole.

Part one is definitely an IETF activity. We really have most of the
pieces, and the few that remain, are easy. I have written an I-D on this
subject, which discusess the pieces needed for a consumer IM/buddy-list
application:

http://www.ietf.org/internet-drafts/draft-rosenberg-simple-components-00.txt

I'd really like to get group input on whether there is
interest/agreement on which aspects of my proposed plan.

The second piece, part two, is to specify an architecture that pulls it
all together. If such a thing were done here, it would need to be
informational to say the least. There is precendent for publication of
informational architecture docs generated by other bodies (the DCS
architecture). I think SOMEONE needs to put this together, that is for
certain. If no one else is stepping up to the plate, I'd prefer IETF to
nobody, thats for sure.

> Comments? Should something like this go on the SIMPLE agenda for

I'd like to discuss it, yes.

-Jonathan R.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 19 Mar 2002 23:39:17 -0500

Discussion on the components document is scheduled for the last 45
minutes of the SIMPLE slot. While we can probably get some things agreed
on during that time, there are probably a number of issues that won't
be. Since face to face is so much higher bandwidth than email, are
people interested in continuing a discussion of the components document
and IM/P service profiles either over dinner on Wednesday after SIMPLE,
over lunch on Thursday, or over dinner on Thursday?

	Tony Hansen
	[email-masked]

---

From: Sean Olson <[email-masked]>
Date: Wed, 20 Mar 2002 06:33:23 -0800 (PST)

This sounds like a good thing. How about Wednesday 
evening over dinner before the plenary?

/sean

=====

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/