Subject: RE: [Simple] Urgent: Event Lists Open Issue

From: Adam Roach <[email-masked]>
Date: Mon, 24 Mar 2003 16:15:28 -0600

> -----Original Message-----
> From: Avshalom Houri [mailto:[email-masked]]
> 
> I think that you can not do "only notify me when someone's
> location changes by *more than* 100 miles" with what is
> defined in RFC 3265. You will need to define a language etc. 
> So why the
> the events lists should be stopped by this when there is no complete 
> solution
> defined anyway?

I'm not trying to define the actual filters.

I'm trying to make sure that such a definition will
be possible at a later date.

3265 makes certain this *can* happen by basically leaving
the SUBSCRIBE bodies open for adding filters.

Now, if we're describing a way to conceptually create
several subscriptions all at once, we need to define
*how* these filters will apply, *not* what the filters
are.

> It might be that doing all the filtering needed in the 
> SUBSCRIBE itself 
> will not be
> possible since there might be an additional exchange of 
> information needed 
> in order
> to get the resource type and the filtering possibilities for that 
> resource.

With SUBSCRIBE in its original form, you could.
The "Event" header tols you the resource type.
Concrete filtering mechanisms would define the
possibilities, presumably using a 415-like
rejection of filter languages that aren't understood.

I know that the filtering problem is difficult.
I just want to make certain that the lists draft
doesn't make it impossible.

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

---

From: "Avshalom Houri" <[email-masked]>
Date: Tue, 25 Mar 2003 00:50:31 +0200

Inline.

> *how* these filters will apply, *not* what the filters

I am not sure that we can separate the two. Part of the filters
definitions might be their applicability.

As in the example you sent to Ben:
a) Only the root node?
b) Only the leaves?
c) Everything?
d) Everything but the leaves?
e) Some subset of nodes not listed above?

Part of the filter definition can be the subset that the filter applies 
to.

> The "Event" header tells you the resource type.

What I tried to say is that I assume that the filtering draft will
need to define a new method in order to enable the filtering.
For example a user will send a method to get the filter properties of
a resource before sending the actual SUBSCRIBE. It am afraid that it might
get even further then that. The filtering in RFC3265 is syntactic 
filtering
"byte-by-byte" as the draft says. We can not assume that this kind of 
filtering
can be applicable also to lists and probably other complex objects that 
might
come in the future.