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

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

Ben Campbell writes:

> You have made some effort in the draft so far to be clear that the
> presence of so-called "back-end" subscriptions are really an
> implementation decision, and not part of the list subscription
> specification. From that perspective, specifying that a list
> subscription filter propagates to back-end subscriptions is
> inappropriate. Assuming that back-end subscriptions exist. One list
> implementation might choose to have non-filtered back-end 
> subscriptions,
> and perform filtering locally. Another might choose to create 
> filters on
> each back-end subscription. These filters may or may not derive from a
> filter on the top list subscription. This is all up to local policy.

Sorry; I'm being a bit sloppy with my terminology.

You are correct in your assertion that literal back-end SIP
subscriptions may or may not exist; that's an implementation
decision. However, even if all the resources are controlled
by a single server, you still end up having conceptual
subscriptions (not SIP subscriptions, but "subscription" in
the more general information technology sense) to the state
of the resources in the list.

Perhaps the problem is that I'm not really being concrete
enough. Taking as an example location-enhanced presence
(as proposed in draft-peterson-geopriv-pres-00), let's say
that I want to subscribe to a presence list, but want to
install a filter that says, "only notify me when someone's
location changes by more than 100 miles".

In order to do this, I generally want to include such
information in the SUBSCRIBE request itself. If we relegate
the filtering of these (possibly conceptual, non-SIP)
subscriptions to be an RLS implementation decision, doing
so becomes impossible.

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

---

From: Ben Campbell <[email-masked]>
Date: 24 Mar 2003 15:53:55 -0600

> subscriptions to be an RLS implementation decision, doing

OK, I clearly misunderstood the question. In fact, I am not sure I
_currently_ understand the question either, as 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. As far as my UAC is concerned, its all the same
thing, isn't it?

Assuming we will have a mechanism to express a filter in a SUBSCRIBE
request (delivered as a separate work item), what is missing? Is it a
question of having sufficient expressivity in that mechanism to allow me
to associate filter with a specific entry on a list, vs the entire list?

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

If this is anywhere near the question you have in mind, then I still
believe it is a matter of establishing proper requirements for the
filtering work item, and out of scope for this document.

---

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

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?

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.

Avshalom

Adam Roach <[email-masked]> 
Sent by: [email-masked]
24/03/2003 23:35

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

/a