Subject: [Simple] RE: Buddy list per User per Event service association ???

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Nov 2001 01:47:58 -0500

> -----Original Message-----
> From: Theodore Havinis [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 5:38 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: Buddy list per User per Event service association ???
> 
> I have two questions for clarifications. I'd appreciate your feedback.
> 
> Clarification-I: Is it possible with the model you describe to build a
> buddy-list tree
> whereby each User has separate buddy lists for separate services ie
> effectively a buddy list
> for telephony buddies (ie buddies who want to subscribe to 
> his telephony
> event), a separate
> one for IM buddies, or even distinguish between a buddy list 
> for 'business
> telephony
> buddies' and a buddy list for 'family telephony buddies'.

Of course. A buddy list is just a named resource. I can subscribe to any
named resource - sip:[email-masked], sip:[email-masked], etc., so long as
those resources are defined. 

> 
> Example: A user gets a subscription from an operator for 
> telephony service,
> IM service, Voice Mail service etc.
> and he would like to build the following scenario that reach him via
> telephony you should become part of his
> telephony-buddies, for as long as needed ie just for the 
> duration of the
> call or longer.
> 
> 
> IM event                  Telephony event                     
>     VoiceMail
> event
> |-----------|             |--------------|------------|
> |---------------|
> |           |             |              |            |           |
> |
> fam.BLSS    buz.BLSS      fam.BLSS       friend.BLSS  buz.BLSS
> friends.BLSS    buz.BLSS
> 
> The sum of BLSS's is the User's BLSS which resides with his 
> home operator or
> 3rd party-provider.

I'm afraid you've lost me here. Just to be clear we are talking about the
same thing - my buddy list is the set of people I want to learn presence
about. In existing systems, this is the list of names you see on your own
messenger tool. Rather than subscribing to each one individually, I can
subscribe to sip:[email-masked], and the server handling
[email-masked] generates subscriptions for all the users in my list.

> 
> So, is that possible to be done when combining buddy-lists, 
> events etc.
> based on the buddy-list draft and on the
> event draft from Adam R. and also should all these events and 
> buddy lists be
> registered with IANA ???

You wouldn't IANA register buddy lists any more than you would IANA register
user names.

> 
> Clarification-II:
> I believe it would be good if you could explain the 
> connection between the
> 'watcherinfo' draft and this draft.
> In my understanding with the watcherinfo one can start 
> creating buddy lists
> as well, ie allow those watchers requesting
> my presence information to subscribe to my presence.

They are basically comverses of each other:

A buddy list is the set of people I want to subscribe to (i.e., the set of
people whose presence I want to learn)

The watcher list is the set of people who want to subscribe to me (which
includes those that have successfully subscribed and those who are merely
pending).

Both are lists, but represent different entities. A buddy list benefits a
subscriber, a watcher list is for a presentity.

I can set up authorization policy as a list that contains those folks that
are allowed to subscribe to me. Call this the "authorized watcher list". It
may so happen that my authorized watcher list is the same as my buddy list,
but that is not necessary; these are fundamentally different lists as far as
the protocol/architecture is concerned. They may be the same for a
particular deployment of a real service, but thats a separate matter.

-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: "Theodore Havinis" <[email-masked]>
Date: Wed, 21 Nov 2001 08:44:14 -0800

Hi Jonathan,

Thanks for your comments.

Please find my comments below.

Kind Rgds
Theo

>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Jonathan
>Rosenberg
>Sent: Tuesday, November 20, 2001 10:48 PM
>To: 'Theodore Havinis'; Jonathan Rosenberg
>Subject: [Simple] RE: Buddy list per User per Event service association
>???
>
>
>
>
>
>

I didn't mean it differently.

So what I was trying to understand is 'where we going' when combining
Events, Buddy Lists,
Wacher lists since these drafts can be very powerful in some ways when
combined.

So here is an example of what I was trying to say in my previous email.

Lets assume that John decides to call Bob for the first time.
One way to provide certain screening services on behalf of Bob for the call
he is receiving from John
is to have John first SUBSCRIBE to the Bob's authorized buddy list for the
telephony event.
So, as soon as John tries to SUBSCRIBE to Bob's "call event buddy list"
Bob gets notified that John wants to SUBSCRIBE to him. Bob has a number of
choices:
(a) reject the subscription
(b) allow John to talk to Bob without allowing him joining Bob's call event
buddy list
(c) allow Jonh to talk to Bob, and at the same time, let him join Bob's call
event buddy list

If Bob allows the subscription of John to his telephony event, then John
joins Bob's
buddy list for telephony. Next time John calls Bob, John is already a buddy
of his
for the telephony event, thus getting authorized and the call gets
established (assuming no other restrictions)

What I describe above for the call event, can be applied to any
communication mean  such as IM etc.

I was wondering if this one way of how we envision to make use of Events,
Buddy lists in future in order
to give more control to a Callee's communication.

>the protocol/architecture is concerned.

They may be the same for a
>particular deployment of a real service, but thats a separate matter.

Thanks, it helped.
So, I have a buddy list, with buddies who subscribed to
my call event, and my call event buddy list gets updated (through a watcher
client) about
my buddies presence, so I know who is available to be called and who isn't
because they
appear to be as  offline.
Does that make sense ?

Thanks
/Theo

>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Nov 2001 14:55:31 -0600

Theodore Havinis wrote:

<snip>

> my buddies presence, so I know who is available to be called and who isn't

Actually, it does not. Your buddy list(s) are lists of people you 
subscribe to, not lists of people who subscribe to you. If you are 
talking about automatically generating recipricol subscriptions, where 
you subscribe to everyone who subscribes to you, then that is an 
application level problem, not a protocol one. Nothing prevents an 
application from automatically adding a user to your buddy list if you 
authorize them to subscribe to you.

---

From: "Theodore Havinis" <[email-masked]>
Date: Wed, 21 Nov 2001 13:51:27 -0800

Hi Ben,

Pls find my comments below.

Thanks
/Theo

>From: Ben Campbell [mailto:[email-masked]]
>Sent: Wednesday, November 21, 2001 12:56 PM
>To: Theodore Havinis
>Cc: Jonathan Rosenberg; [email-masked]
>Subject: Re: [Simple] RE: Buddy list per User per Event service
>association ???
>
>
>
>
>Theodore Havinis wrote:
>
><snip>
>
>
>>
>> Thanks, it helped.
>subscribe to, not lists of people who subscribe to you.

It coulbe be a matter of definition, but I also see as buddies of mine
anyone who wants to SUBSCRIBE to me and I authorize him/her.

If you are
>application level problem, not a protocol one.

Not necessarily generating reciprocal subscriptions.
I agree this is an application issue.

Nothing prevents an
>authorize them to subscribe to you.

So here is the issue, and maybe its only a definition issue.
While in your first statement you say that my buddy list consists of people
that I subscribe
to, in your last statement you say that its also possible for somebody to
join my buddy list
provided I authorize his SUBSCRIBE request.

So the application is the entity which will decide if the person that wants
to SUBSCRIBE
to me is placed in the same buddy list with the persons that I have
subscribed to.

But in principle, both the ones that I SUBSCRIBE to and the ones I authorize
to SUBSCRIBE to me
are buddies of mine and the key reason for that is "authorization" as I see
it.

So, in my view it works both ways, and that can be used by an application on
my behalf
for building up say a buddy list consisting of people who accept my calls
when I call them,
and a buddy list of the people that I allow them to call me.
These two lists can be combined to one such "call service-buddy list" or can
be kept separate such as
'incoming call service buddy list' and 'outgoing call service buddy list'.

Theo

---

From: Ben Campbell <[email-masked]>
Date: Mon, 26 Nov 2001 09:39:24 -0600

Hi Theo,

Comments inline

Theodore Havinis wrote:

>>>my call event, and my call event buddy list gets updated
>>>
>>(through a watcher
>>
>>>client) about
>>>my buddies presence, so I know who is available to be called and
>>>
>>who isn't
>>
>>>because they
>>>appear to be as  offline.
>>>Does that make sense ?
>>>
>>>

You are correct, it is a matter of definition. The definition I gave is 
the working definition used in the draft.

> provided I authorize his SUBSCRIBE request.

No, I didn't say that. You (or an application on your behalf) add people 
to your buddy list. No one adds themselves to your buddy list. 
(Obviously there are exceptions, where you might grant a third party the 
right to add people to your list). Other people may choose to add you to 
their buddy lists.

 From a protocol level your buddy list and someone elses buddy list are 
completely decoupled. There is nothing that says that that you also 
subscribe to everyone that subscribes to you. This may be coincidentally 
true (you and a buddy just happen to subscribe to each other.) You might 
also write an application that enforces or facilitates this (Whenever 
you authorize someone to subscribe to you, the application automagically 
adds that person to your buddy list.)

> are buddies of mine and the key reason for that is "authorization" as I see

There is nothing at all to stop you from writing an application that 
uses the contents of your buddy list to make authorization decisions 
about people who wish to subscribe to you. In that case, you have a 
buddy list and an "authorized subscriber list" that just happen to be 
the same, or even two lists that happen to have the same contents. This 
is a matter of application policy and irrelevant to the draft.

> 'incoming call service buddy list' and 'outgoing call service buddy list'.

Again, it is perfectly reasonable to create an application where it 
works both ways. However, it is very useful when creating protocol to 
decouple the two concepts, making it also possible to create an 
interoperable application that does _not_ link the two.