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

From: [email-masked]
Date: Tue, 18 Mar 2003 06:07:55 +0200

What your saying here, if I understand correctly, is that if a subscriber leaves out the "supported: eventlist" header out, but subscribe to a list, then they are subscribing for an aggregate state of the list. Am I correct? If so, then I don't see any harm in that.

For filters, I would say the filter applies to the aggregated state (document).

This allows non-list implementations to subscribe to a list and get aggregate state. Only the user knows its a list. This only works if the format (XML document) of the aggregate state is the same as the format of the normal state document where the subscriber subscribes to one resource. Does this fit with your proposal?

The way the aggregate state is computed is then package specific.

/Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, March 18, 2003 2:50 AM
> To: [email-masked]'
> Subject: [Simple] Event Lists and aggregate state
> 
> 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Mar 2003 16:00:59 -0600

The idea isn't completely baked yet, but the general
idea was that computation of these aggregate states
would generally be an implementation decision, although
I expect that it would generally be a rather
straightforward excercise for implementors to come
up with some reasonable aggregation.

With the helpdesk example, presence aggregation could
be as simple as reporting "OPEN" if at least one
resource was "OPEN", and closed otherwise.

Specifying a canonical aggregation algorithm, I fear,
would tie the hands of implementors (i.e. I see this as
a potential area for significant value-add), and it
would also impose significant burden on specification
of event packages (including any PIDF extensions).
Specification of a *syntax*, of course, would be
necessary. I see this as adjunct work to defining
a package for which aggregation might be useful.

/a

> From: Sean Olson [mailto:[email-masked]]
> Sent: Monday, March 17, 2003 21:44
> To: Adam Roach; [email-masked]'
> Subject: Re: [Simple] Event Lists and aggregate state
> 
> 
> 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.
> 
> 
> --- Adam Roach <[email-masked]> wrote:
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>