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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 27 Nov 2001 17:50:28 -0500

The problem is that many people have a view based on the
current implementations of buddy lists that such a list
is on the watcher side, and not on the presentity side.

Nothing prevents you from making an implementation that
adds a buddy to the presentity's buddy list (who he watches)
as a consequence of some operation like authorizing
subscriptions to presence information.  If users like
that implementation, you may become famous.

I find the current implementations intuitively correct -
I decide who I care to watch, and just because you want to
see my presence does not mean I want to see yours.  YMMV.

Brian

> -----Original Message-----
> From: Theodore Havinis [mailto:[email-masked]]
> Sent: Friday, November 23, 2001 10:05 AM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: RE: [Simple] RE: Buddy list per User per Event service
> association ???
> 
> 
> 
> 
> 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
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]]On Behalf Of 
> Rosen, Brian
> >Sent: Wednesday, November 21, 2001 10:38 AM
> >To: 'Theodore Havinis'
> >Cc: [email-masked]'
> >Subject: RE: [Simple] RE: Buddy list per User per Event service
> >association ???
> >
> >
> >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
> >
> 
> 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple