Subject: [Simple] Event Lists and aggregate state

From: Adam Roach <[email-masked]>
Date: Mon, 17 Mar 2003 18:49:42 -0600

From the discussion raised during the RPIDS presentation,
an idea occured to me. I don't think it's baked enough to
bother raising during my presentation today, but I wanted
to throw it out for more minds to chew on.

Based on the outcome of today's discussion, RPIDS will
include a mechanism to include the aggregate state of
a group (e.g. sip:[email-masked] might have a
simple OPEN/CLOSED indication). In particular, including
the detailed state of all of the included items is
relegated to the list draft.

The first issue that was raised was a slight inelagancy,
in the fact that one might want to subscribe to
"sip:[email-masked]" to get the aggregate state,
or they might want to subscribe to "sip:[email-masked]"
to get detailed information about the members. Without
requiring use to use different URIs (most practically,
different user IDs), there's no way with the current
way the mechanisms are defined to indicate which you
want. Now, we could make a minor tweak to event lists
which allows you to leave out indication of support for
lists if you just want the aggregate state (if supported),
this is a bit inelegant, and doesn't solve the problem
in the more general sense (e.g. the list
"sip:[email-masked]" may in turn contains the
lists "sip:[email-masked]" and
"sip:[email-masked]"; subscribers may want
aggregate information for each of those lists).

Now, the way that event lists is currently written, only
the "leaves" in the subscription tree can include state.
It would be a trivial excercise to add an optional "cid"
parameter to the <list> element that points to one of the
bodyparts, and allow this bodypart to contain aggregate
state for the list. This approach *feels* general to me,
although it may well require new body types for certain
packages. That's not really different than presnce,
actually: PIDF isn't designed to communicate such aggregate
state, although RPIDS is.

So, should we add this sort of mechanism to the event
lists draft?

Comments? Support? Opposition?

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

---

From: Sean Olson <[email-masked]>
Date: Mon, 17 Mar 2003 19:44:10 -0800 (PST)

Is this aggregate state computed in some way? If so,
what is the computation used to come up with the 
aggregate state? Issues that come to mind are 
extensions to the PIDF format and the use of tuple 
IDs (what is a tuple). These may be non-issues but
it would be nice to see this resolution in any 
recommendation for aggregation of state.

> Comments? Support? Opposition?

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 21 Mar 2003 09:38:53 -0800

In general, I think I agree with the mechanism you propose, if we really
do have a need for a state of the list, rather than state of the
members. But I am unsure of the problem we are trying to solve.

I realize the general futility of attacking an _example_, but it seems
to me that in the help desk example below, you are _not_ subscribing to
a list. You are instead subscribing to a _derived_ presentity, where the
helpdesk presence is derived in an application specific fashion. There
is no _generalizeable_ relationship between the presence info for
"helpdesk" and the presence info of the various people who might fill
the role of help desk. From this perspective, the helpdesk, and a list
of helpdesk operators, are different applications, and should have
different URIs. The application that generates state for the helpdesk
_might_ well subscribe to the list of help desk operators, but again,
that is application specific.

One possible "state of the list" item might be the membership roster
itself--but you already have a mechanism for that.

So, unless the consensus of the list really believes the use case under
discussion in fact is a list application (and history leads me to
believe I will be in the minority on that point), I would prefer to see
some more motivation for the need before we do to much work on it.