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

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

Yes, I think that's where we're getting.

The key distinction I was trying to make below is that we
almost certainly do *not* want to add the ability to say
"inform me only when the 'state' attribute of an <instance>
element transitions from 'active' to 'terminated'" to the
language that tells us how to filter presence. And the one that
tells us how to filter registrations. And the one that tells
us how to filter dialog state. And the one that tells us how
to filter SPIRITS. And the one that tells us how to filter
phoneconfig. And the one that tells us how to filter MWI.
And the one that tells us how to filter winfo. And the one
that tells us how to filter signalled digits. And the one
that tells us how to filter...

See where I'm going?

/a

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, March 24, 2003 18:35
> To: Adam Roach
> Cc: Robert Sparks; Jonathan Rosenberg; [email-masked]'
> Subject: RE: [Simple] Urgent: Event Lists Open Issue
> 
> 
> 
> 
> On Mon, 2003-03-24 at 17:05, Adam Roach wrote:
> > > -----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 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.
> 
> > 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: Sean Olson <[email-masked]>
Date: Mon, 24 Mar 2003 18:00:27 -0800 (PST)

The unfortunate consequence of this is that the
filter you place in a subscription needs to be
complete in the sense that it filters out anything
you might possibly not want to see because if you
happen to unknowingly subscribe to a list, you might
very well get back something you did not expect (a
leaf).

Thus filters will get long and complex and you
will probably need a better mechanism for managing
filters than SUBSCRIBE itself leading to even 
more protocol machinery that was supposed to simplify
the life of the client, not complicate it. 

Filters must be designed with hierarchy in mind
and must allow "everything but" and "nothing but"
definitions. Hmmmm.... sounds like a job for LISP.

> > > which body part applies to lists, and which

__________________________________________________
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: "Avshalom Houri" <[email-masked]>
Date: Tue, 25 Mar 2003 05:11:24 +0200

Sounds like a filtering working group is going to be created soon...

For the event lists draft are we all OK with having two filters in the 
SUBSCRIBE,
One applies to an atomic objects and the other applies to complex ones and 
leave
the details of the filter language to the filtering work?

Avshalom

Sean Olson <[email-masked]> 
Sent by: [email-masked]
25/03/2003 04:00

To
Adam Roach <[email-masked]>, Ben Campbell 
<[email-masked]>
cc
Robert Sparks <[email-masked]>, Jonathan Rosenberg 
<[email-masked]>, "[email-masked]'" <[email-masked]>
Subject
RE: [Simple] Urgent: Event Lists Open Issue

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Mar 2003 22:30:11 -0500

I dont even think we need to go that far. I think that it should say 
that a filter can appear in the body, and that work on filters is still 
under investigation. Period. We can have this nice long debate on the 
meaning of filters in infinitely deep trees later on.

-Jonathan R.

Avshalom Houri wrote:
>>>From: Ben Campbell
>>[mailto:[email-masked]]
>>
>>>Cc: Robert Sparks; Jonathan Rosenberg;
>>
>>[email-masked]'
>>
>>>Subject: RE: [Simple] Urgent: Event Lists Open
>>
>>Issue
>>
>>>
>>>
>>>
>>>>>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
>>
>>>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
>>
>>>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
>>
>>>>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
>>
>>>>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
>>
>>>>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
>>>

-- 
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: Ben Campbell <[email-masked]>
Date: 24 Mar 2003 21:40:22 -0600

> very well get back something you did not expect (a

I would assume that a watcher not prepared to deal with a list would not
include the supported tag for lists.

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 24 Mar 2003 20:47:13 -0800

Fair enough. I was beginning to put together a filter for this mail thread
;-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Monday, March 24, 2003 7:30 PM
To: Avshalom Houri
Cc: [email-masked]'
Subject: Re: [Simple] Urgent: Event Lists Open Issue

-Jonathan R.

> and must allow "everything but" and "nothing but" definitions. 
> Hmmmm.... sounds like a job for LISP.
> 
>