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

From: Adam Roach <[email-masked]>
Date: Mon, 24 Mar 2003 17:05:39 -0600

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> 
> For other kinds of filters, particularly those based on filtering
> content, the burden _has_ to live in the definition of the filter.
> I'm not sure yet whether that means a filter has to be list agnostic.
> It may be that a filter can express "Do this if you are a list, 
> otherwise do that".

I was composing a note along the same lines, but you said it far more
succinctly.

Actually, my example was going to keep the list-agnostic property,
and suggest that you could specify two filters in a multipart
body: one filter applied to the list resources, and another
applied to the non-list resources.

I think it is important that we be able to keep the list stuff out
of the filters themselves. The filtering work is bubbling up all
over: SIP, XMPP, LEMONADE, WEBDAV... it looks very much like there
would be *great* benefit to coordinating te filtering work and
re-using it in a bunch of places.

If we make the filter syntax list-aware, we might have a harder
time fostering such re-use. Using a multipart body in the way
I describe would eliminate such a barrier.

If this sounds good, then the only provision we need to add
to the current lists draft is some mechanism for indicating
which body part applies to lists, and which applies to non-lists.

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

---

From: Ben Campbell <[email-masked]>
Date: 24 Mar 2003 18:34:37 -0600

> applied to the non-list resources.

I think the rule expression language should be agnostic to the mechanics
of list subscriptions, but it should _not_ assume that a given
subscription (and its resulting ruleset) is only about a particular
presentity.

For example, I would like to be able to express that a rule applies to
Bob. Also, I would like to be able to express that a rule applies to
everybody, or everybody in a domain, etc.

If you do that right, it ought to be equally applicable for a list
subsription and a scaler subscription. If I express a rule to apply to
everyone, that means all resources that show up in the tree. If I have a
scaler subscription, my tree is trivial. If I want a rule to apply to
Bob, then for a scaler subscription to Bob, it works fine. For a scaler
subscription to Carol, it is meaningless. For a list subscription in
which Bob shows up _anywhere_ in the tree, it applies to Bob. Note that
this does not require the rule language to have any concept of the tree
structure, or how lists work. It only requires a rule language that
accepts the idea of a 1 to many relationship between subcriptions and
presentities.

Now, if such a rule language existed, it seems to me the only thing that
the list draft needs to specify is that a ruleset may be delivered in
the body of a SUBSCRIBE request.