> -----Original Message-----
> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> Sent: Wednesday, July 15, 2009 7:42 PM
> To: Brian Rosen; Hannes Tschofenig; geopriv@ietf.org
> Subject: RE: [Geopriv] loc-filters additional requirements
>
> The second is OK, the first doesn't work.
>
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]
> > Sent: Wednesday, 15 July 2009 11:38 PM
> > To: Thomson, Martin; 'Hannes Tschofenig'; geopriv@ietf.org
> > Subject: RE: [Geopriv] loc-filters additional requirements
> >
> > How about:
> > <include type="xpath">/tuple/status/gp:geopriv/gp:location-
> > info/gml:location </include>
> > and
> > <include type="xpath">/tuple/status/gp:geopriv/gp:location-
> > info/cl:civicAddress</include>
> >
> > That is neither brittle nor cumbersome.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
> > > Sent: Tuesday, July 14, 2009 7:35 PM
> > > To: Brian Rosen; Hannes Tschofenig; geopriv@ietf.org
> > > Subject: RE: [Geopriv] loc-filters additional requirements
> > >
> > > If I get you right, you want to be able to just use the information
> > > that is directly expressed in the PIDF to do everything. Then you
> > > don't need a loc-filters document. What you need is a much (much)
> > > smarter implementation of RFC 4661 - a specification that is
> already
> > > difficult to implement.
> > >
> > > I know how to force inclusion of geodetic in the fashion you
> suggest,
> > > but it's cumbersome, indirect and brittle:
> > >
> > > <what>
> > > <include type="xpath">
> > > //gp:location-info/*[@srsName="urn:ogc:def:crs:EPSG::4326" or
> > > @srsName="urn:ogc:def:crs:EPSG::4979"]
> > > </include>
> > > </what>
> > >
> > > How a PA is expected to see this and infer that it needs to perform
> > > geocoding, is probably beyond the ken of many. The PA could just
> > > recognize the string and infer from that, but that's massively
> > brittle.
> > >
> > > I sat down and figured out how something like this might be
> > implemented
> > > by a generic(-ish) PA. You need to know that only GML geometries
> > have
> > > an srsName attribute (which is actually not true: srsName cannot be
> > > namespace qualified, so this relies on an assumption). Then the
> > > solution requires that the PA have further specialized knowledge.
> > Once
> > > you get to that sort of complexity, it's not that hard to just do
> > > something simple:
> > >
> > > <what><lf:locationType>geodetic</lf:locationType></what>
> > >
> > > At some point, you need to know about the content in order to do
> the
> > > geocoding. Why overcomplicate matters trying to avoid putting this
> > > knowledge in the filter?
> > >
> > > Someone once submitted a centroid draft. Derived properties in the
> > > PIDF could lead to some confusion. Again, the same argument
> applies.
> > >
> > > Quality filters need proper feedback to be properly useful [1].
> Even
> > > with the proposed filters, this is necessary. It's very easy to
> > > implement filters that don't actually achieve the intended goal.
> > >
> > > --Martin
> > >
> > > [1] http://tools.ietf.org/html/draft-thomson-simple-cont-presence-
> > val-
> > > req
> > >
> > > > -----Original Message-----
> > > > From: Brian Rosen [mailto:br@brianrosen.net]
> > > > Sent: Wednesday, 15 July 2009 7:14 AM
> > > > To: 'Hannes Tschofenig'; Thomson, Martin; geopriv@ietf.org
> > > > Subject: RE: [Geopriv] loc-filters additional requirements
> > > >
> > > > I'm particularly interested in keeping the same functionality for
> > > > filtering
> > > > for SIP and HELD, so I don't want to see HELD-specific solutions.
> > > >
> > > > I think you could easily force a civic by requiring country code
> > > field,
> > > > with
> > > > something similar for the geo.
> > > >
> > > > I suspect, but haven't thought out how to do something similar to
> > > force
> > > > a
> > > > particular shape
> > > >
> > > > I'd probably go along with adding quality filters, but I'd prefer
> > we
> > > > first
> > > > make the quality parameters actual elements in a PIDF instead of
> > > > implicitly
> > > > using something like the circle radius. We could then ask for a
> > > > specific
> > > > value or range of those elements of the PIDF.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: geopriv-bounces@ietf.org [mailto:geopriv-
> bounces@ietf.org]
> > On
> > > > > Behalf Of Hannes Tschofenig
> > > > > Sent: Tuesday, July 14, 2009 4:32 PM
> > > > > To: 'Thomson, Martin'; geopriv@ietf.org
> > > > > Subject: Re: [Geopriv] loc-filters additional requirements
> > > > >
> > > > > Hi Martin,
> > > > >
> > > > > This functionality is not directly related to the original goal
> > of
> > > > the
> > > > > filters document that tried to limit the amount of
> notifications
> > > that
> > > > > are
> > > > > being sent to the watcher.
> > > > >
> > > > > Anyway, functionality (1) is already in the HELD specification
> > and
> > > > has
> > > > > also
> > > > > been re-used in the HTTP dereference document (that was
> actually
> > > the
> > > > > reason
> > > > > for having more functionality than just an HTTP lookup). Also
> > > > providing
> > > > > the
> > > > > functionality in this document would be very much inline with
> the
> > > > Deref
> > > > > document. This, I believe, is a good idea.
> > > > >
> > > > > Regarding functionality (2): This is neither in HELD nor in
> > Deref.
> > > If
> > > > > you
> > > > > believe it is useful then we should add it to the Deref
> document
> > as
> > > > > well. In
> > > > > general, we should think about how to keep this type of
> > > functionality
> > > > > (from
> > > > > a semantic point of view) roughly aligned and separated from
> the
> > > > actual
> > > > > transport.
> > > > >
> > > > > You mentioned the quality aspects: As a brief note I wanted to
> > > > mention
> > > > > that
> > > > > some basic functionality (in the form of the 'responseTime'
> > > > attribute)
> > > > > is
> > > > > already in the HELD base specification and is therefore
> inherited
> > > by
> > > > > the
> > > > > Deref document. As such, I believe it should be provided also
> in
> > > this
> > > > > document.
> > > > >
> > > > > Ciao
> > > > > Hannes
> > > > >
> > > > >
> > > > > >I apologise for not getting these in earlier, but this came
> > > > > >out of a discussion that James Polk and I had over his filters
> > > > > >draft. We concluded that the draft would become informational
> > > > > >and would provide a "cookbook" type of assistance to
> > > > > >implementers rather than defining new filters.
> > > > > >
> > > > > >To that end, there were a few fairly basic filters that could
> > > > > >not be accommodated by the current loc-filters document. We
> > > > > >decided to raise these in the GEOPRIV WG:
> > > > > >
> > > > > > 1. location type: A requirement to specify the desired
> > > > > >location type: geodetic or civic. This would be a simple
> > > > > >addition and would either filter out the undesired type, or -
> > > > > >if the PA supported it - allow for the application of
> > > > > >(reverse) geo-coding.
> > > > > >
> > > > > > 2. location shape: For geodetic locations, it might be
> > > > > >desirable to have the server perform shape conversion. For
> > > > > >instance, on a serving node it's possible to make certain
> > > > > >assumptions about shapes that result in a smaller shape when
> > > > > >converting. This could be significantly better than leaving a
> > > > > >client to perform any conversions (perhaps based on
> > > > > >draft-thomson-geopriv-uncertainty) without that additional
> > > > > information.
> > > > > >
> > > > > >I also have some more general requirements on quality that I
> > > > > >would like to see included (see
> > > > > >draft-thomson-geopriv-location-quality). These might require
> > > > > >a somewhat different approach, as they regard the continuous
> > > > > >nature of location information. I would have liked for these
> > > > > >to be considered, but am pragmatic enough to accept dealing
> > > > > >with these at a later date.
> > > > > >
> > > > > >In casting unsubstantiated dispersions about the maturity of
> > > > > >this document, these are the issues that I believe were not
> > > > > >covered. ...and need to be. I hope that this is adequate
> > > > > >substantiation.
> > > > > >
> > > > > >--Martin
> > > > > >
> > > > > >p.s. We probably also need to go to SIMPLE to discuss the
> > > > > >addition of a != operator in 4661. There was a good use case
> > > > > >for that included in James' document, but my notes don't
> > > > > >elaborate on it.
> > > > > >
> > > > > >--------------------------------------------------------------
> -
> > > > > >---------------------------------
> > > > > >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
> > > > > >Geopriv@ietf.org
> > > > > >https://www.ietf.org/mailman/listinfo/geopriv
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/geopriv
> > > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -------------------------
> > > 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]
> >
>
> -----------------------------------------------------------------------
> -------------------------
> 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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
