Subject: [Simple] Urgent: Event Lists Open Issue

From: Adam Roach <[email-masked]>
Date: Mon, 24 Mar 2003 14:00:49 -0600

I've been informed by the chairs that event lists is something we
want to close Really Soon Now.

As I mentioned during the SIMPLE meeting last week, there is still
one open issue, and it's pretty big. To summarize:

- RFC 3265 allows SUBSCRIBE messages to contain bodies and
  "Event:" header parameters to further refine subscriptions.
  In general, the type of information that can be usefully
  included in these two places is some form of filtering.

- Subscribing to a list resource typically creates a number of
  subscriptions.

- Including a filter in such a subscription is ambiguous: does
  it apply to the list subscription, the underlying subscriptions,
  or both?

Discussions so far seem to indicate consensus that applying
such bodies to the underlying subscriptions is problematic.
I agree. Given the forgoing, we're left with the question
of how to apply filters to any underlying subscriptions.

One obvious punt is to say that such filters are provisioned
as part of the list, just like the membership of such a list
is. This seems a bit inflexible, since it artificially ties
the filter to the list, regardless of the nature of the
subscriber.

Another approach might be to have some mechanism for the
subscriber to somehow retrieve the structure of the list,
and then post a set of filters for each element in the
list, but this seems horribly complicated and rife with
potential race conditions.

Alternately, we could push this issue off onto whoever creates
the actual filter definitions, forcing them to define them
in such a way that they make sense in a list context.
Obviously, this imposes a greater burden on what is already
a difficult problem.

I'm certain that this isn't the entire list of possible
solutions. This note is an urgent call for people to
ponder and discuss this particular issue. We can't close
event lists until this is decided in some way.

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

---

From: Robert Sparks <[email-masked]>
Date: 24 Mar 2003 14:16:13 -0600

SIMPLE List Members:

Please concentrate your efforts on resolving this issue. Post your
comments as soon as possible - we are going to try to close this
_this week_ and issue WGLC on this document shortly thereafter.

Thanks,
RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Mar 2003 15:34:36 -0500

inline.

>   it apply to the list subscription, the underlying subscriptions,

It applies to the list.

Its really simple - you subscribe to a resource. Whatever that resource 
is, the filters are applied to the resource you subscribe to. There is 
nothing special about a list as a type of resource.

> Obviously, this imposes a greater burden on what is already

I think this is the right answer. Filters are specific to the type of 
resource you are subscribing to. Thus, if you subscribe to a list, the 
filters have to know its a list.

Practically speaking, this doesnt seem hard, really. If you know how to 
build a filter for a single presentity, a filter for a list would simply 
include any filters to apply to a particular presentity. You can also 
have list wide filters that would apply no matter who the presentity is.

> event lists until this is decided in some way.

I strongly believe that this is a problem for the filters. The draft 
should merely point in that direction.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Avshalom Houri" <[email-masked]>
Date: Mon, 24 Mar 2003 22:52:05 +0200

It seems that filter definitions would need a lot more work anyway.
RFC 3265 defines a very basic filtering mechanism.
So I would say that we  should push this issue off to the filtering work.

Avshalom

Adam Roach <[email-masked]> 
Sent by: [email-masked]
24/03/2003 22:00

To
"[email-masked]'" <[email-masked]>
cc

Subject
[Simple] Urgent: Event Lists Open Issue

/a

---

From: Ben Campbell <[email-masked]>
Date: 24 Mar 2003 14:51:08 -0600

> nothing special about a list as a type of resource.

If I understand Jonathan correctly, then I agree completely. 

You have made some effort in the draft so far to be clear that the
presence of so-called "back-end" subscriptions are really an
implementation decision, and not part of the list subscription
specification. From that perspective, specifying that a list
subscription filter propagates to back-end subscriptions is
inappropriate. Assuming that back-end subscriptions exist. One list
implementation might choose to have non-filtered back-end subscriptions,
and perform filtering locally. Another might choose to create filters on
each back-end subscription. These filters may or may not derive from a
filter on the top list subscription. This is all up to local policy.

> should merely point in that direction.

Agreed. And to restate what I said above, the list draft should neither
assume nor prevent any relationship between filters specified at the top
level subscriptions, and any filters that may be applied in any
resulting back-end subscriptions.