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

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 5 Nov 2008 00:14:56 -0600

Today I reviewed the much neglected location filters draft.  I've stuck to the XML commenting format, below.

I think that the first comment is the most important, although I don't intend this to be an indictment of the editor(s).  Everyone has different priorities.

Cheers,
Martin

--

<comments about="http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03" by="mailto:[email-masked]" xml:lang="en">

  <comment id="general">
    <note>I'm really disappointed in the lack of attention that this document has attracted.  The document needs an overhaul, and it needs to either be integrated with existing solutions (RFC 4661 and niemi-sipping-event-throttle) or be a whole lot more robust so that it can stand alone.  The problem that this document solves is real, but in its current form, it's not useful.</note>
  </comment>

  <comment id="punctuation">
    <note>There are a lot of unterminated sentences in this document, starting with the abstract.  Was there something more that should have been said?</note>
  </comment>

  <comment id="rfc4660">
    <note>I wonder why the format specified by this document is still separate to the simple event filters (RFC 4661).  As has been pointed out, the civic address filter can easily be handled by existing filters.  In the RFC 4661 sense, I assume that each of the items in this draft is a trigger rather than a what.  The current document doesn't make a distinction, and it should.</note>
  </comment>

  <comment id="delta">
    <note>Providing an indication about why a notification was generated is not something that is necessarily unique to location.  In that regard, I believe that there is significantly more work required to get this to the point where it can be accepted.  To that end, I propose that this piece be split from the draft.</note>
  </comment>

  <comment id="remains">
    <note>In light of the previous comments, all that remains is the interesting events of movement, speed, and entry/exit.  Speed can be solved if pidf-lo-dynamic is adopted (which it should be).  I'll restrict my comments to movement and entry/exit only, apart from one little note.</note>
  </comment>

  <comment id="movedabsolute" section="3.1">
    <note>You need to note that movement is absolute - from the position noted in the last notification.  It's possible that a greater non-linear distance could be travelled by the presentity, but implementation of that would be totally inconsistent.</note>
  </comment>

  <comment id="movementuncertainty" section="3.1">
    <note>Detecting movement is subject to uncertainty considerations.  If cell sites are used as the basis of location determination, there are some interesting cases where this is extremely difficult to rule on.</note>
    <note>In the first example, the presentity doesn't move, but it hands over to a new cell.  The new cell is 8km away from the old cell, but the coverage areas of each is 12km, which overlaps.  Is this a movement of more than 1km?  (Exercise for the reader, try integrating to get the maximum likelihood movement, assuming 95% confidence and rectangular distribution.)</note>
    <note>In the second example, uncertainty from measurement is greater than the threshold.  Any amount of movement within the original uncertainty is undetectable.</note>
    <note>Don't feel obliged to solve these, mentioning the problem is probably enough for this stage.  This document could leave that up to implementations, or suggest a really simple principle (use centroid movement).</note>
  </comment>

  <comment id="uom" section="3.1">
    <note>The units of measure used in this document MUST be the same as in the pidf-lo-dynamic document.  Since this is a WG item first, it should be the one that picks them up or defines them.  See my comments on that draft.</note>
    <note>I shuddered to see the time units of measure.  Thankfully, there is a good single standard for time that is fairly universally used.  If it were necessary, the duration type defined in xml schema--which is based on iso 8601--is good enough.</note>
  </comment>

  <comment id="horizSpeed" section="3.1">
    <note>Whatever solution is adopted for speed, it needs to be consistent with PIDF-LO dynamic.  This isn't.  PIDF-LO dynamic is better, simpler and easier to understand.</note>
    <note>The only thing that RFC 4661 doesn't do well is manage differing units of measure.  This might be a good reason to define specific speed triggers in this document.  However, there should only be one allowed uom, so this point is largely moot.</note>
  </comment>

  <comment id="external" section="3.3">
    <note>The containment specification correctly refers to pidf-lo-profile (and by proxy OGC geo-shape).  However, the definition of external references is far too light.  What requirements and constraints on the URI?  What URI schemes are allowed or recommended?  Does this need to be a secured reference, or does that only apply if the request is made over a secured channel?</note>
  </comment>

  <comment id="feature" section="3.3">
    <note>GML feature might have sounded like a good idea once, but you are only interested in geometry.  Save implementers a whole world of hurt and explicitly limit it to geometry.</note>
  </comment>

  <comment id="geometry" section="3.3">
    <note>Require implementation of the shapes in PIDF-LO profile.  Your note on allowing other geometries is OK, but it doesn't need a "MAY".  All you need to do is allow it in schema and remain silent and those who need to use bicubic splines will work out how to do so.</note>
  </comment>

  <comment id="CRS" section="3.3">
    <note>No point in talking about 4326 and 4979, just refer to PIDF-LO profile.</note>
    <current-text>Any 2-dimensional region MUST be defined using the EPSG 4326 coordinate reference system.  Any 3-dimensional region MUST be defined using the EPSG 4979 coordinate reference system.</current-text>
    <proposed-text></proposed-text>
  </comment>

  <comment id="featurecruft" section="3.3">
    <note>I've been saying this for years about this draft, hopefully this time it sticks ;)</note>
    <note>The free-form nature of GML exists to make it easy for application schema to be tailored in many ways.  That doesn't mean that an application schema can leave all the unspecified pieces alone.  The use of my:Building, which is presumably a concrete instance of gml:_Feature is nice in theory, but it makes it much harder to implement this than is really necessary.  We don't need to name our shapes.  If we are going to refer to shapes, we can deep link into the geometry part from an external document that uses features as appropriate; for by-value geometry, we can demand that the important piece be extracted for us.  Remove my:Building, gml:name and gml:extentOf.  These don't add value.
    </note>
  </comment>

  <comment id="references" section="3.3">
    <note>Make an explicit container for references to external geometry.  There is no need to rely on xlink doing all the work here.</note>
  </comment>

  <comment id="wheee" section="3.5">
    <note>There appears to be three copies of the schema in this document.</note>
  </comment>

  <comment id="security" section="5">
    <note>Security considerations about geometry by reference need to be included.</note>
  </comment>
</comments>
------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 7 Nov 2008 12:36:02 -0500

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.

I found your comment style difficult to deal with.

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.

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?

I'll add some text about uncertainty in relation to movement

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.

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomson, Martin
Sent: Wednesday, November 05, 2008 1:15 AM
To: GEOPRIV
Subject: [Geopriv] Review of draft-ietf-geopriv-loc-filters-03

Today I reviewed the much neglected location filters draft.  I've stuck to
the XML commenting format, below.

I think that the first comment is the most important, although I don't
intend this to be an indictment of the editor(s).  Everyone has different
priorities.

Cheers,
Martin

--

<comments
about="http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03"
by="mailto:[email-masked]" xml:lang="en">

  <comment id="general">
    <note>I'm really disappointed in the lack of attention that this
document has attracted.  The document needs an overhaul, and it needs to
either be integrated with existing solutions (RFC 4661 and
niemi-sipping-event-throttle) or be a whole lot more robust so that it can
stand alone.  The problem that this document solves is real, but in its
current form, it's not useful.</note>
  </comment>

  <comment id="punctuation">
    <note>There are a lot of unterminated sentences in this document,
starting with the abstract.  Was there something more that should have been
said?</note>
  </comment>

  <comment id="rfc4660">
    <note>I wonder why the format specified by this document is still
separate to the simple event filters (RFC 4661).  As has been pointed out,
the civic address filter can easily be handled by existing filters.  In the
RFC 4661 sense, I assume that each of the items in this draft is a trigger
rather than a what.  The current document doesn't make a distinction, and it
should.</note>
  </comment>

  <comment id="delta">
    <note>Providing an indication about why a notification was generated is
not something that is necessarily unique to location.  In that regard, I
believe that there is significantly more work required to get this to the
point where it can be accepted.  To that end, I propose that this piece be
split from the draft.</note>
  </comment>

  <comment id="remains">
    <note>In light of the previous comments, all that remains is the
interesting events of movement, speed, and entry/exit.  Speed can be solved
if pidf-lo-dynamic is adopted (which it should be).  I'll restrict my
comments to movement and entry/exit only, apart from one little note.</note>
  </comment>

  <comment id="movedabsolute" section="3.1">
    <note>You need to note that movement is absolute - from the position
noted in the last notification.  It's possible that a greater non-linear
distance could be travelled by the presentity, but implementation of that
would be totally inconsistent.</note>
  </comment>

  <comment id="movementuncertainty" section="3.1">
    <note>Detecting movement is subject to uncertainty considerations.  If
cell sites are used as the basis of location determination, there are some
interesting cases where this is extremely difficult to rule on.</note>
    <note>In the first example, the presentity doesn't move, but it hands
over to a new cell.  The new cell is 8km away from the old cell, but the
coverage areas of each is 12km, which overlaps.  Is this a movement of more
than 1km?  (Exercise for the reader, try integrating to get the maximum
likelihood movement, assuming 95% confidence and rectangular
distribution.)</note>
    <note>In the second example, uncertainty from measurement is greater
than the threshold.  Any amount of movement within the original uncertainty
is undetectable.</note>
    <note>Don't feel obliged to solve these, mentioning the problem is
probably enough for this stage.  This document could leave that up to
implementations, or suggest a really simple principle (use centroid
movement).</note>
  </comment>

  <comment id="uom" section="3.1">
    <note>The units of measure used in this document MUST be the same as in
the pidf-lo-dynamic document.  Since this is a WG item first, it should be
the one that picks them up or defines them.  See my comments on that
draft.</note>
    <note>I shuddered to see the time units of measure.  Thankfully, there
is a good single standard for time that is fairly universally used.  If it
were necessary, the duration type defined in xml schema--which is based on
iso 8601--is good enough.</note>
  </comment>

  <comment id="horizSpeed" section="3.1">
    <note>Whatever solution is adopted for speed, it needs to be consistent
with PIDF-LO dynamic.  This isn't.  PIDF-LO dynamic is better, simpler and
easier to understand.</note>
    <note>The only thing that RFC 4661 doesn't do well is manage differing
units of measure.  This might be a good reason to define specific speed
triggers in this document.  However, there should only be one allowed uom,
so this point is largely moot.</note>
  </comment>

  <comment id="external" section="3.3">
    <note>The containment specification correctly refers to pidf-lo-profile
(and by proxy OGC geo-shape).  However, the definition of external
references is far too light.  What requirements and constraints on the URI?
What URI schemes are allowed or recommended?  Does this need to be a secured
reference, or does that only apply if the request is made over a secured
channel?</note>
  </comment>

  <comment id="feature" section="3.3">
    <note>GML feature might have sounded like a good idea once, but you are
only interested in geometry.  Save implementers a whole world of hurt and
explicitly limit it to geometry.</note>
  </comment>

  <comment id="geometry" section="3.3">
    <note>Require implementation of the shapes in PIDF-LO profile.  Your
note on allowing other geometries is OK, but it doesn't need a "MAY".  All
you need to do is allow it in schema and remain silent and those who need to
use bicubic splines will work out how to do so.</note>
  </comment>

  <comment id="CRS" section="3.3">
    <note>No point in talking about 4326 and 4979, just refer to PIDF-LO
profile.</note>
    <current-text>Any 2-dimensional region MUST be defined using the EPSG
4326 coordinate reference system.  Any 3-dimensional region MUST be defined
using the EPSG 4979 coordinate reference system.</current-text>
    <proposed-text></proposed-text>
  </comment>

  <comment id="featurecruft" section="3.3">
    <note>I've been saying this for years about this draft, hopefully this
time it sticks ;)</note>
    <note>The free-form nature of GML exists to make it easy for application
schema to be tailored in many ways.  That doesn't mean that an application
schema can leave all the unspecified pieces alone.  The use of my:Building,
which is presumably a concrete instance of gml:_Feature is nice in theory,
but it makes it much harder to implement this than is really necessary.  We
don't need to name our shapes.  If we are going to refer to shapes, we can
deep link into the geometry part from an external document that uses
features as appropriate; for by-value geometry, we can demand that the
important piece be extracted for us.  Remove my:Building, gml:name and
gml:extentOf.  These don't add value.
    </note>
  </comment>

  <comment id="references" section="3.3">
    <note>Make an explicit container for references to external geometry.
There is no need to rely on xlink doing all the work here.</note>
  </comment>

  <comment id="wheee" section="3.5">
    <note>There appears to be three copies of the schema in this
document.</note>
  </comment>

    <note>Security considerations about geometry by reference need to be
included.</note>
----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 9 Nov 2008 20:55:05 -0600

Hi Brian,

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

> From: Brian Rosen [mailto:[email-masked]]
> 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
> 

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.

> use it, but we still need a filter to control notification based on

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

> Did you want something more than that, or am I misunderstanding the

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.
 
> PIDF includes a speed report or not, the filter expression would be the

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.

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Nov 2008 12:23:23 -0500

So, it seems the disconnect is around how you deal with speed.

Suppose you got a series of reports (Event Notifications), where you got X/Y/Z, but not speed in the notification.

Can you filter on speed?  Does it make sense to talk about a change in value of something that isn't in the notify, even though the presence server could compute a speed?  

I'd be interested in Henning's thoughts on this subject.

Brian

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Sunday, November 09, 2008 9:55 PM
To: Brian Rosen; GEOPRIV
Subject: RE: [Geopriv] Review of draft-ietf-geopriv-loc-filters-03

Hi Brian,

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 10 Nov 2008 15:55:23 -0600

Actually, the presence server could calculate average velocity, but instantaneous speed might be more difficult.  Is speed simply |(position2 - position1)|/(time2 - time1) ?  Is there any inconsistency with the absolute movement distance?  This gets interesting, because instantaneous speed might be higher than that value.  How do you get any reliability in the result?

> Sent: Tuesday, 11 November 2008 4:23 AM
> Suppose you got a series of reports (Event Notifications), where you
> got X/Y/Z, but not speed in the notification.
> 
> Can you filter on speed?  Does it make sense to talk about a change in
> value of something that isn't in the notify, even though the presence
> server could compute a speed?
> 
> > and referenced throttle, although  I notice a dangling reference to
> the
> > old
> 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.
> 
> > be the same in both documents.  Happy to reference other uom for
> time.
> > I
> > approach of -dynamic), with a value filter in this doc.  Then,
> whether
> > the
> 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.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Nov 2008 17:26:08 -0500

Good question, but missing the point; I think we can come to agreement on how you calculate speed, using whatever -dynamic does.

Still have the question I asked: if speed is not reported, can you have a 4661 change in value filter on speed?

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 10 Nov 2008 16:35:37 -0600

Um, that was more or less the point of the question.  Can you sensibly calculate speed from a series of positions, or should you leave it up to the location generator.  My point was (obliquely) that this needs to be defined, or you can't.  I'm actually tending towards shouldn't.  That is, if the LG doesn't do the calculation for you, don't try to because of the aforementioned problems.

Martin

> Sent: Tuesday, 11 November 2008 9:26 AM
> Good question, but missing the point; I think we can come to agreement
> on how you calculate speed, using whatever -dynamic does.
> 
> Actually, the presence server could calculate average velocity, but
> instantaneous speed might be more difficult.  Is speed simply
> |(position2 - position1)|/(time2 - time1) ?  Is there any inconsistency
> with the absolute movement distance?  This gets interesting, because
> instantaneous speed might be higher than that value.  How do you get
> any reliability in the result?
> 
> > Noted; and it was more effort to do it that way, so I'll probably
> stick
> > to the tried-and-true methods in future.
> >
> > > other hand, I can't commit to make that happen, so I propose that
> we
> > > leave
> > > I'll go look up your uom comments on -dynamic.  Certainly agree
> they
> > > should
> > > Agree on your comments on the URI for containment.  I have much
> more
> > > work to
> > > do on this item.
> > >
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > ---------------------------------------------------------------------
> --
> > -------------------------
> > [mf2]
> >
>