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

["Thomson, Martin" <[e-mail]>]

I think that you've drawn on the one major aspect of the draft that I was almost immediately unhappy with.  As you point out, I was probably suckered by the existing examples, which interpreted in isolation paint a very specific picture that doesn't cover this use case.

I think that the types of things you are looking to convey for location are described in my location-quality draft [1].  One important aspect of this is the way that (as described in the draft), you might like uncertainty of 50m, you might settle for less.  I'd like your opinion on how quality "targets" fit into the RFC 4661 schema.  Maybe the sit in a new top-level item alongside <what> or <trigger>.

[1] http://tools.ietf.org/html/draft-thomson-geopriv-location-quality-01

> -----Original Message-----
> From: Adam Roach [mailto:[e-mail]]
> Sent: Sunday, 16 November 2008 3:28 PM
> To: Cullen Jennings
> Cc: [e-mail]; Thomson, Martin
> Subject: Re: [Simple] Comments on draft-thomson-simple-cont-presence-
> val-req-00
> 
> 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
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple