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

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

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

Actually, that seems to me to just point out that the rate-limiting
solution needs to be "average over some period", not "absolute".
(This is in reference to the filtering dicussion on the topic,
not worth rehashing here).

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

---

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

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> 
> Now, it could also do this by attaching a derived filter to each
> delegated subscription, so that _it_ only sees the changes that match
> the rule, and passes them all on to the watcher. That would 
> _seem_ like
> option B. But from the watcher's perspective, these two approaches
> should be indistinguishable.

For this example, yes.

Think more closely about the example Robert gives, in which the
difference is not just detectable, but also substantial.

/a

---

From: [email-masked]
Date: Tue, 25 Mar 2003 09:14:33 +0200

The draft below discusses this issue and defines a filter for presence that handles situations where a filter is made for a list or a member of that list. It mentions that a filter applies to all the URIs that result in a lookup of the list URI. It does not mention that the filter is propagated down to the leaf subscriptions. This is an RLS behaviour that needs to be defined in list draft, IMO.

http://www.ietf.org/internet-drafts/draft-khartabil-simple-presence-filter-00.txt

I would suggest that the RLS should not propagate the filter down to the leaves. The reason for that is it then requires UAS (edge presence servers) to understand, interpret and apply the filters. It is the job of the RLS to filter the NOTIFYs coming into the RLS and create new NOTIFY bodies according to that filter.

I think I'm advocating option a) below.

Regards,
Hisham

> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 2:12 AM
> To: Ben Campbell; Adam Roach
> Cc: Jonathan Rosenberg; [email-masked]'
> Subject: RE: [Simple] Urgent: Event Lists Open Issue
> 
> 
> After some further reflection, I think I see the disconnect
> here.
> 
> When I say "applied to the root only", you're still thinking
> of what I mean by "applied to everything".
> 
> The type of filter that would be "applied to the root only"
> or "applied to non-leaves only" would be something along
> the lines of "inform me only when the 'state' attribute of an
> <instance> element transitions from 'active' to 'terminated'".
> (Visual aid: example at the top of page 13 of
> draft-ietf-simple-event-list-00)
> 
> The point of my "tell me when someone moves by more than 100
> miles" example is that this is exactly the sort of filter
> that CANNOT be applied to the root node, only to leaf nodes.
> 
> /a
> 
> > Sent: Monday, March 24, 2003 17:55
> > To: Adam Roach
> > Cc: Jonathan Rosenberg; [email-masked]'
> > Subject: RE: [Simple] Urgent: Event Lists Open Issue
> > 
> > 
> > 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".
> > > 
> > 
> > No, actually what I had in mind was "a) Only the root.".
> > 
> > Maybe my disconnect is it still feels that the only 
> rational model is
> > "A) only the root", and options B and C are, among others, possible
> > mechanisms the root can use to implement that. (Which, by the 
> > way, seems
> > to take us back to my first response.)
> > 
> > Since we seem to be talking _way_ past each other, let me 
> extend your
> > concrete example. If I only want to see notifies that 
> involve a 100 mi
> > or more change in geoloc, I express that on my SUBSCRIBE 
> > request to the
> > list. Now, the list server could go about that in a number 
> of ways. It
> > could delegate subscriptions for each list entry (with real or
> > conceptual subscriptions), and only pass through 
> > notifications when the
> > threshold is reached. This seems like a clear case of option a).
> > 
> > I guess my point is, it seems to me this should be 
> specified based on
> > what goes into the root subscription, and what comes back out--which
> > should be doable without explicitly dealing with filters in the list
> > draft, just as it is without explicitly reving 3265.
> > 
> > 
> > > /a
> >

---

From: [email-masked]
Date: Tue, 25 Mar 2003 14:43:13 +0200

Or rather we need some rate limit. There seemed to be a bit of a burst in this thread overnight - makes it really difficult to follow... ;)

But to the issue, I also agree with the below statement.

Cheers,
Aki

 > From: ext Sean Olson [mailto:[email-masked]]
 > Sent: 25 March, 2003 06:47
 > To: 'Jonathan Rosenberg'; 'Avshalom Houri'
 > Cc: [email-masked]
 > Fair enough. I was beginning to put together a filter for 
 > this mail thread
 > ;-)
 > 
 > 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
 > 
 > 
 > 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:
 > > 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
 > > 
 > > 
 > > 
 > > 
 > > 
 > > 
 > > 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.
 > > 
 > > 
 > > --- Adam Roach <[email-masked]> wrote:
 > > 
 > >>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
 > >>
 > >>
 > >>>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:
 > >>>
 > >>>>>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
 > >>>
 > > __________________________________________________
 > > Do you Yahoo!?
 > > Yahoo! Platinum - Watch CBS' NCAA March Madness, live on 
 > your desktop! 
 > > http://platinum.yahoo.com 
 > -- 
 > 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: [email-masked]
Date: Tue, 25 Mar 2003 14:57:53 +0200

It seems to me we're trying to get all the benefits of throttles, filters and list subscriptions (and combinations of those) without any of the drawbacks. My feeling is that we should make the simple case work first, and not worry about the more complex scenarios. For example, a rate limit of 1/min is not real useful for a list with 10 buddies. In fact it's pretty much as useless as a 1/10min throttle for a single buddy.

I think an optimization will fail or never get finished if it becomes too complex and tries to solve too many sub-cases.

Cheers,
Aki

 > From: ext Robert Sparks [mailto:[email-masked]]
 > Sent: 25 March, 2003 01:08
 > To: Jonathan Rosenberg
 > Cc: Adam Roach; Ben Campbell; [email-masked]'
 > On Mon, 2003-03-24 at 16:44, Jonathan Rosenberg wrote:
 > > Robert Sparks wrote:
 > > 
 > > > 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 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.
 > > 
 > > > 
 > > 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.
 > > 
 > 
 > 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
 >

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Mar 2003 13:11:19 -0600

You're falling into the same trap that Ben did. We're not
discussing *who* applies the filters; we're discussing
*to* *what* *data* are they applied.

/a

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 1:15
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> The draft below discusses this issue and defines a filter for 
> presence that handles situations where a filter is made for a 
> list or a member of that list. It mentions that a filter 
> applies to all the URIs that result in a lookup of the list 
> URI. It does not mention that the filter is propagated down 
> to the leaf subscriptions. This is an RLS behaviour that 
> needs to be defined in list draft, IMO.
> 
> I would suggest that the RLS should not propagate the filter 
> down to the leaves. The reason for that is it then requires 
> UAS (edge presence servers) to understand, interpret and 
> apply the filters. It is the job of the RLS to filter the 
> NOTIFYs coming into the RLS and create new NOTIFY bodies 
> according to that filter.
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Mar 2003 13:14:26 -0600

Once again: we don't need to actually define the filters themselves
at this point; we just need to make certain that there *will* be a
way to define them. I want to make certain that people attacking
the filtering work item won't look back on the lists work and say,
"well, that was stupid. If they'd just done this one little thing,
our job wouldn't be impossible."

/a

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 6:58
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> It seems to me we're trying to get all the benefits of 
> throttles, filters and list subscriptions (and combinations 
> of those) without any of the drawbacks. My feeling is that we 
> should make the simple case work first, and not worry about 
> the more complex scenarios. For example, a rate limit of 
> 1/min is not real useful for a list with 10 buddies. In fact 
> it's pretty much as useless as a 1/10min throttle for a single buddy.
> 
> I think an optimization will fail or never get finished if it 
> becomes too complex and tries to solve too many sub-cases.
> 
> Cheers,
> Aki
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Mar 2003 13:24:59 -0600

Jonathan Rosenberg [mailto:[email-masked]] writes:

> under investigation. Period. We can have this nice long debate on the 

You are making an erroneous assumption that the filter work
will be SIP only.

There is a growing need for notifiction filtering everywhere:
SIP/SIMPLE, CalSched, VPIM, Lemonade, OPES, LDAP-EXT, IPP, 
WebDav, and XMPP have all had proposed working group items
that touch on this topic.

Hallway conversations I've had with reasonably well-connected
individuals indicate that there is growing support for some
sort of coordination of this work. Avshalom is correct in
predicting that a working group may well surface around this
topic.

I'm certain that input for requirements will be solicited from
all interested groups; however, if SIP has gone and done something
that requires a particularly onerous requirement -- or one that
cannot be generally understood -- it *will* be ignored in any
such effort.

/a