Subject: RE: [Simple] Event Lists and aggregate state

From: Adam Roach <[email-masked]>
Date: Tue, 18 Mar 2003 17:44:22 -0600

> From: Henning Schulzrinne [mailto:[email-masked]]
> 
> Slightly related question: How do I tell the PA whether I only care 
> about the group status as a whole or the collection of individual 
> status? 

We can certainly look at other ways of addressing this,
but under the solution I'm proposing, it becomes a
question of filtering.

> Section 3.1 in the draft is less than clear on this. 
> It is not 
> clear (to me) whether including the 'Supported: eventlist' 
> requests the 
> list rather than the aggregate.

Once again, I *don't* think using "Supported: eventlist"
to indicate whether you want a list or an aggregate
is a very good idea. That's been the main point of this
whole thread.

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Mar 2003 01:23:16 -0500

> but under the solution I'm proposing, it becomes a

I agree that the correct solution is:

   1. RPIDS have attributes that describe group state (for example, a 
percentage that indicates the amount of presentities in the group which 
are in some state)
   2. The event list mechanism be capable of including such a presence 
document, using a cid attribute of the list element,
   3. Filtering is used to indicate whether this information is desired 
or not.

I am OK with doing (2) as part of the list draft. THinking about this a 
bit, I would prefer to defer the definition of group presence state from 
RPIDS at this time. It can always be handled separately, and its not 
clear to me that we really understand what states we want to convey for it.

Furthermore, since we don't have the filtering in place yet, in order 
for the list spec to proceed, the default mode of operation will need to 
be to never include the state of the list itself unless it is explicitly 
requested through some future filter mechanism, to be defined.

-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: Henning Schulzrinne <[email-masked]>
Date: Wed, 19 Mar 2003 12:31:45 -0500

> percentage that indicates the amount of presentities in the group which 

I'm not sure that a percentage is particularly useful in most cases. At 
least in most cases, an observer only cares whether contacting 
[email-masked] can reach somebody, not whether 27% of the sales staff 
is taking a cigarette break. (In ACD scenarios, membership in particular 
groups is fluid, as agents are shifted to different tasks as load 
changes. Thus, this number is often not well-defined.)

I can see the use for ad-hoc conferencing, but even there, it seems like 
a 0/100 scenario (everybody there) or you need to know who is there. (No 
point starting the meeting if the principals aren't there.)

In the interest of simplicity, I'd like to see additional use cases.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Mar 2003 16:30:13 -0500

I think group presence is generally a hard problem to define, much less 
solve. Its still a useful problem, but lets not delude ourselves that we 
can do quickly, so I agree it shouldn't be in RPIDS.

With normal presence of individuals, a buddy will typically use the 
presence status to pick a time to call when there is good probability 
that the call will be answered by the individual behind the presentity, 
rather than an answering machine.

In the case of groups and ACDs, you might imagine wanting to use 
presence the same way: I want to watch the presence of the Sales group 
at Acme.com and only call when someone is available to take my call.

That works sometimes, when talking on the phone is only a part time 
activity of the group members.

But consider when I want to call Sabre to make a flight reservation. I 
may *want* to wait until there is an agent free to take my call before I 
place the call, but I am unlikely to ever find such a time. I am working 
at cross purposes with the management of the group, which wants to 
ensure that every agent is on the phone all the time.

This means that in such cases I need a different form of availability. 
It might take the form of expected wait time. But even that is very 
difficult to predict in general - wait time will vary depending on who 
is calling and what they want, which may not even be communicated until 
after the call is made.

I am curious how many out there are interested in working on this problem.

	Paul

Henning Schulzrinne wrote:
>> percentage that indicates the amount of presentities in the group 
>> which are in some state)
> 
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Mar 2003 13:04:45 -0600

> can do quickly, so I agree it shouldn't be in RPIDS.

I believe Paul's observation below is fairly insightful in
approaching group presence.  I think we all agree that group
presence becomes harder to quantify as the number of group
members increase.  Furthermore, as Paul points out, subscribing
to the presence of a large group (such as ones comprised of
[email-masked] or [email-masked] or
[email-masked]) is at odds with the interest of the
said business since the business would ensure that agents
are always present.

More interesting (and approachable) use of group presence is
when the group cardinality is low (10, 15, I don't know what
the low water mark is, but definitely not in the hundreds).
These types of groups typically represent an individual's buddy
list or family member list.

>> I'm not sure that a percentage is particularly useful in most cases. 
>> At least in most cases, an observer only cares whether contacting 
>> [email-masked] can reach somebody, not whether 27% of the sales 
>> staff is taking a cigarette break. (In ACD scenarios, membership in 
>> particular groups is fluid, as agents are shifted to different tasks 
>> as load changes. Thus, this number is often not well-defined.)
>>
>> I can see the use for ad-hoc conferencing, but even there, it seems 
>> like a 0/100 scenario (everybody there) or you need to know who is 
>> there. (No point starting the meeting if the principals aren't there.)
>>

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Mar 2003 14:16:40 -0500

> list or family member list.

Finding group status for an 'amorphous' group of people, such as a buddy 
list, is probably not all that interesting. Knowing that 25.7% of my 
buddy list is online is probably of limited use.

I can see use for custom-lists such as 'my-project-team', but as I 
mentioned, in those groups, members are typically not simple counts.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Mar 2003 22:59:56 -0500

First off, I will preface this by saying that I still believe that group 
presence should be out of RPIDS. I am interested in working on it (and 
thus my response below), but lets get the basics done first.

More inline.

> buddy list is online is probably of limited use.

One application of group presence is to make a decision whether to 
subscribe to the list members (using Adam's list extensions). One way to 
make such a determination is through such a percentage. If no one in the 
group is at a particular state (such as OPEN), its probably not worth 
subscribing to the list to find more details.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 21 Mar 2003 12:41:06 -0500

> thus my response below), but lets get the basics done first.

<member> is already out (in my editing version). This differs from the 
notion of whole-group status.