Re: [Simple] Comments on draft-thomson-simple-cont-presence-val-req-00

[Adam Roach <[e-mail]>]

I second what Cullen has to say about the quality of the document -- 
this is very well written, and you have clearly put a lot of thought 
into it. It is an excellent basis for a requirements document for the 
filtering work in GEOPRIV, regardless of whether I am ultimately 
successful in convincing you of the appropriateness of presence for your 
application.

I'm also quite pleased to see that you've internalized the preponderance 
of the points I attempted to make in our earlier discussions on the 
issue. However, you appear to have what I believe are a couple of 
lingering misconceptions about the potential behavior that filters can 
exhibit. These are most vividly expressed in sections 4.3 and 4.4.

In particular, the document reflects a belief that the filter framework 
has inherent limitations that make it appropriate only for discrete 
properties. Key examples of this misconception are conveyed in the text:

> The hard, boolean nature of a filter is not tolerant of variation in 
> quality.
and:

> If filter documents are used as a medium for communicating watcher 
> preferences, the watcher could set a filter that only selects highly 
> accurate information, which could inadvertently suppress all 
> notifications.

As in our previous conversations, I suspect you have confused cause with 
effect. There is nothing inherent in the filter framework that imposes 
or implies such limitations. What you are observing is a consequence of 
the fact that event packages so far have all been composed exclusively 
of discrete values -- not the *reason* that they have.

When GEOPRIV sets off to define the filter extensions that relate to 
location, they may elect to define them to have the useless (or, at 
best, infuriatingly limited) properties you describe in these excerpts. 
I will repeat my earlier advice on this topic: don't.

You are far more studied in the nature of the information a watcher 
would want to convey regarding the quality of information it receives 
from an LIS, so I won't even try to come up with an example of the 
parameters that need to be conveyed. However, if you can give an example 
of what a watcher would want to say, I'll happily format it into a 
plausible syntax for a filter, and provide the narrative that explains 
the semantics.

/a


On 11/15/08 4:49 PM, Cullen Jennings wrote:
>
> I really liked this draft and hope that we proceed with solutions to 
> some to these requirements.
>
> One small thing, I think an example might help illustrate all the 
> issues. I was trying to think of an example that illustrates many of 
> the problems yet is not too complicated or too tied up in other 
> controversial issues. Location seemed to complicated though it is 
> probably the most important use case. The example that came to mind 
> was imagine my communication device could measure my body temperature. 
> This information is privacy sensitive, associated with user more 
> though measured by device, continuous. It easy to imagine a sensor 
> that could be within a 2 degree error in an almost instantaneously 
> measurement seconds but needed to integrate for 45 seconds to get down 
> to 0.0 degree error.  (Yah, yah, I know error is a big vague but 
> forgive me that for now). It's easy to imagine some applications where 
> 1 degree is fine and there are others where one needs to be at the 0.1 
> degree level. One could have applications that wanted to be notified 
> if it went below 96 degrees fahrenheit or over 101 degrees. It easy to 
> imagine applications that want it report once an hour.
>
> The value based trigger section does not discuss the difficulties of 
> how noisy measurement randomly bouncing above and below the threshold 
> but this seems like it is often one of the issues.
>
> On requirement V1. As you know, specifying ranges of multivariate 
> values can get complicated. For multivariate values, I think it wold 
> be sufficient to have an scheme where a min max value for for each 
> variable was specified and any time any variable crossed one of these 
> thresholds, an update was triggered.
>
>
> Cullen in my individual contributor role
>
> PS - This was a really nicely written draft. I read just about ever 
> draft that was on a RAI agenda and this was probably the most coherent 
> easy to understand draft I read. 
> Thanks_______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple