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

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

But only for rate limiting. Think about other kinds of filters.

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, March 24, 2003 16:31
> To: Robert Sparks
> Cc: Adam Roach; Ben Campbell; [email-masked]'
> Subject: Re: [Simple] Urgent: Event Lists Open Issue
> 
> 
> The answer is A.
> 
> -Jonathan R.
> 
> Robert Sparks wrote:
> > So consider this question from the perspective of the
> > rate-limiting kind of filter. We've asserted earlier
> > that these kinds of filters aren't event package specific,
> > so we can carve away solutions that call to individual
> > packages. The question then becomes do you have to be
> > able to talk about lists when you express one of these
> > generic rate limiting filters?
> > 
> > If you place a "No more than once a minute" filter on
> > a subcription to a list, are you saying
> > 
> > A) I don't want more than one NOTIFY per minute as
> >    a result of this list subscription.
> > 
> > or
> > 
> > B) I don't want more than one NOTIFY per minute for
> >    any given leaf in the list/tree.
> > 
> > I think what we have to decide first is whether the
> > answer is always A or always B, or if the generic rate
> > filter needs to be able to specify one of those options.
> > 
> > 
> > RjS
> > 
> > On Mon, 2003-03-24 at 16:08, Adam Roach wrote:
> > 
> >>Ben Campbell [mailto:[email-masked]] writes:
> >>
> >>
> >>>I have a hard time
> >>>understanding the distinction between applying a filter to the list
> >>>subscription and applying the subscription to the "conceptual"
> >>>underlying subsriptions.
> >>
> >>Thinking still of these conceptual underlying subscriptions,
> >>a subscription to a list creates an arbitrarily deep tree
> >>of subscriptions, in which all of the leaves are non-list
> >>resources, and all other nodes are list resources.
> >>
> >>Keeping this tree in mind, the question being posed fundamentally
> >>boils down to this: When a filter document is included in a
> >>SUBSCRIBE message to a list, which of these nodes does it apply to?
> >>
> >>a) Only the root node?
> >>b) Only the leaves?
> >>c) Everything?
> >>d) Everything but the leaves?
> >>e) Some subset of nodes not listed above?
> >>
> >>
> >>>For example, is it a question of saying "only tell me when 
> >>>someone moves
> >>>100 miles" vs. "Tell me when Alice moves 50 mi or Bob moves 75 mi"?
> >>
> >>That's interesting, but not really what I had in mind. It also
> >>indicates to me that the model you had in your mind was option
> >>"b) Only the leaves".
> >>
> >>/a
> >>_______________________________________________
> >>Simple mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/simple
> > 
> > 
> 
> -- 
> 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
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

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

I'm not convinced the answer is always A for rate limiting.
More on that below.

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".

Back to rate limiting. The effect of A below for presence is that
if 10 of my buddies happen to change their presence state about
the same time (which happens frequently at the end of meetings),
I won't find out about one of them until at least 10 minutes later.

This points out value in being able to assert B as the right thing
to do.

RjS

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Mar 2003 17:44:32 -0500

> It may be that a filter can express "Do this if you are a list, 

I still assert that for the most common cases, you will want to apply 
the same filter across all users in the list. In the cases where you 
dont, the filter mechanism merely needs to provide the ability to 
specify per-user filters.

> This points out value in being able to assert B as the right thing

Its the same point as above. A baseline rate limiting mechanism will 
work for lists and single user presentities. It may not be sufficient 
for all list subscriptions, in whcih case we could define additional 
rate limiting mechanisms that define behavior on a per-user basis.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: 24 Mar 2003 17:08:25 -0600

> rate limiting mechanisms that define behavior on a per-user basis.

So are you saying, then, that the default behavior is A (from earlier)
but that we need to pass a requirement to sipping to be able to express
a choice for B for the baseline rate limiting mechanism?

Or are you saying that the baseline behavior is A, not matter what, and
that if you want B behavior, you have to specify it in a package 
specific filter document?

RjS