Re: [Geopriv] Review of draft-ietf-geopriv-loc-filters-03

From: Thomson, Martin ^lt;>
Date: Sun Nov 09 2008 - 21:55:05 EST

Hi Brian,

Thanks for the response. A few responses below...nothing major.

> -----Original Message-----
> From: Brian Rosen []
> Sent: Saturday, 8 November 2008 4:36 AM
> To: Thomson, Martin; 'GEOPRIV'
> Subject: RE: [Geopriv] Review of draft-ietf-geopriv-loc-filters-03
> Thanks for your review
> I did not have time to reword the draft to use 4661. I note the
> original
> author (Rohan) is opposed to that change. I did remove the rate
> controls
> and referenced throttle, although I notice a dangling reference to the
> old
> mechanism which I will remove.

If the WG (and you should note the discussion in SIMPLE that is scheduled) decides to use the presence event package, then 4661 is necessary. If not, then it's less of a concern.

I can certainly appreciate the time constraints. A rewrite would be non-trivial.

> I found your comment style difficult to deal with.

Noted; and it was more effort to do it that way, so I'll probably stick to the tried-and-true methods in future.

> If -dynamic is accepted as a WG item, then I will reword the speed
> event to
> use it, but we still need a filter to control notification based on
> speed.

RFC 4661 only needs a small adjustment to allow for >=, >, < and <= operators on the <changed> element.

> Generally, I am in favor of fewer, more general purpose mechanisms and
> "changes in value" as a generalized filter may be one of those. On the
> other hand, I can't commit to make that happen, so I propose that we
> leave
> the "change in value" filter there, and if anyone else steps up and
> writes
> up a more generalized filter mechanism, I'll remove the one here and
> reference that.
> I'm confused on move absolute. The text says:
> The distance is measured absolutely from the point of last
> notification
> rather than in terms of cumulative motion
> Did you want something more than that, or am I misunderstanding the
> comment?

My bad, I missed that sentence.
> I'll add some text about uncertainty in relation to movement

Let's sort that out for -dynamic first.
> I'll go look up your uom comments on -dynamic. Certainly agree they
> should
> be the same in both documents. Happy to reference other uom for time.
> I
> don't understand your suggestion, but I'll ping you privately and
> figure out
> what you mean.
> As above, I agree that if we are adopting -dynamic, this doc ought to
> reference it for speed, and I do think we need a filter. We need a
> filter
> even if the PIDF-LO does not express a speed component as -dynamic
> describes. However, we certainly can use the same descriptions (the
> vector
> approach of -dynamic), with a value filter in this doc. Then, whether
> the
> PIDF includes a speed report or not, the filter expression would be the
> same.

I don't think that this is necessary or useful. If there is a standardized method for the expression of speed, then a general mechanism (<changed> from 4661) works adequately.

> Agree on your comments on the URI for containment. I have much more
> work to
> do on this item.
> As long as there are no objections, I will make it be geometry and not
> feature.
> I'll deal with the other comments in the text.
> Brian
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.
Geopriv mailing list
Received on Sun, 9 Nov 2008 20:55:05 -0600

This archive was generated by hypermail 2.1.8 : Sun Nov 09 2008 - 21:55:17 EST