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

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Nov 2001 13:38:15 -0500

And, it's a race to see who types the fastest.....

The guy with the buddy list is John, not Bob.  John has a list
of buddies he sees presence for.  If he wants to add Bob to his
list, then he has to subscribe to Bob's presence, and indeed,
Bob can decide to not let him do that.

The point of the buddy list is when John logs on for the
umpteenth time, instead of again subscribing to John, and Mary,
and Fred, and Joe individually, he does one operation (subscribe
my buddy list), and all the individual subscription actions
are performed on John's behalf.  If any of them failed, that
"buddy" would not show presence to John. 

Bob may have his own buddy list, but it has the people Bob wants
to see presence for.  

So buddy lists are for watchers.  Presentities may have lists of
authorized subscribers, or they may have more complex rules.  So
far, that is beyond our specification work.  AFAIK, a buddy list
is really just a shorthand equivalent to a bunch of individual
subscriptions.  As Jonathan notes, this duplicates what is in AIM
or other commercial IM systems.  In those systems, each of the
buddy lists are watchers.  Of course, nothing prevents Bob from
being in John's buddy list, but that is up to John.  It is up to
Bob to decide if he will let John see his presence information,
or, more precisely, what he will let him see, since it isn't binary.

Brian

> -----Original Message-----
> From: Theodore Havinis [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 11:44 AM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: RE: [Simple] RE: Buddy list per User per Event service
> association ???
> 
> 
> 
> Hi Jonathan,
> 
> Thanks for your comments.
> 
> Please find my comments below.
> 
> Kind Rgds
> Theo
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]]On Behalf Of Jonathan
> >Rosenberg
> >Sent: Tuesday, November 20, 2001 10:48 PM
> >To: 'Theodore Havinis'; Jonathan Rosenberg
> >Cc: [email-masked]
> >Subject: [Simple] RE: Buddy list per User per Event service 
> association
> >???
> >
> >
> >
> >
> >
> >
> >> -----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.
> 
> 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.
> 
> 
> >>
> >> 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.
> 
> 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
> 
> >
> >-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
> >_______________________________________________
> >simple mailing list
> >[email-masked]
> >http://mailman.dynamicsoft.com/mailman/listinfo/simple
> >
> 
> 
> 
> _______________________________________________
> 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: "Theodore Havinis" <[email-masked]>
Date: Fri, 23 Nov 2001 07:05:29 -0800

I find it confusing taklking about buddies "one way only".
I think whether I join a buddy list or I allow somebody to join
my buddy list, if the application decides to put the 2 together,
as far as i see it is part of the same buddy list.

The determining factor should not be who initiates the SUBSCRIBE,
but it should the 'authorization'.

Theodore

>[mailto:[email-masked]]On Behalf Of Rosen, Brian
>Sent: Wednesday, November 21, 2001 10:38 AM
>To: 'Theodore Havinis'
>Cc: [email-masked]'