Subject: Buddy Lists, generally

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 30 Jun 1999 06:30:15 -0500 (CDT)

Arjun's messages raise an interesting point: has there been any
exploration into interoperable 'buddy list' type applications
for SIP systems? For example, has anyone looked at how one could
define an interaction between SIP registrations and SGAP
notifications?

I only just stumbled across the SGAP draft, and it seems an interesting
(if somewhat un-SIP-ish) solution to this type of problem. If
anyone has any related comments (especially other ideas for
REGISTER notifications to clients), I'd be very interested in hearing
them.

http://search.ietf.org/internet-drafts/draft-day-sgap-01.txt

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Scott Petrack <[email-masked]>
Date: Wed, 30 Jun 1999 10:55:19 -0400 (EDT)

Hmmmm, just when we were running out of worms, a new can (or tin) opens up
before us....

Some time ago, there was a disussion about whether the "right" thing to do
to get on someone's buddy list or receive other kinds of notifications was
to "SUBSCRIBE" or to "REGISTER". I myself was a REGISTER fan, but was
overruled by Jonathan and Henning. My recollection was the the intended
general semantics were as follows:

REGISTER -- this is a request that future requests for communication to
the Request-URI in the To: field be automatically sent or redirected to
the Request-URI in the Contact: field.  If there is no Contact: field in
the REGISTER, the message is overloaded to mean "please send me the list
of current registrations".

SUBSCRIBE -- this is a request to have the server send subsequent NOTIFY
requests to the server listed in the Contact: field. (If there is no
Contact: field, then the subsequent NOTIFYs are sent to the SIP URI in the
From: field). 

Although it did seem to me that one could distinguish these two meanings
by looking at the payload of the request, my understanding was that
Henning and Jonathan thought that the semantics were different enough to
merit two different requests. 

I have to admit that upon reflection, I thought that the poor REGISTER
message was far too oveloaded as it is -- sometimes it means "UNREGISTER",
and sometimes it means "don't register, but tell me all the current
registrations" (something I would have done with SUBSCRIBE and Expires:0,
by the way ;-)). So I agree with Henning and Jonathan that we need a
different request for SUBSCRIBE.

Bottom line -- I would not like to use REGISTER for any buddy-list
service. I would rather use a pure SUBSCRIBE/NOTIFY exchange.

Scott