Re: [Geopriv] loc-filters additional requirements

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

Let's assume that the PA is intelligent enough to identify an element in an <include> that doesn't exist, link that to a particular presence source and populate that data.  Let's assume that the PA has presence sources that are able to source location of either type, or presence sources that are able to acquire the alternative location type and perform (reverse-)geocoding.

There isn't one single form for geodetic data.  You need to select one of a set.  RFC 4661 doesn't offer any option to say "include one of these elements".  What you propose depends on one of two things: location conversion, or a new form of geodetic location, such as you seem to want to include.  Neither of those work especially well - one degrades location, the other doesn't exist yet.

--Martin

p.s. gml:location is deprecated.

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: Thursday, 16 July 2009 10:09 AM
> To: Thomson, Martin; 'Hannes Tschofenig'; [e-mail]
> Subject: RE: [Geopriv] loc-filters additional requirements
> 
> Why?
> 
> > -----Original Message-----
> > From: Thomson, Martin [mailto:[e-mail]]
> > Sent: Wednesday, July 15, 2009 7:42 PM
> > To: Brian Rosen; Hannes Tschofenig; [e-mail]
> > Subject: RE: [Geopriv] loc-filters additional requirements
> >
> > The second is OK, the first doesn't work.
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[e-mail]]
> > > Sent: Wednesday, 15 July 2009 11:38 PM
> > > To: Thomson, Martin; 'Hannes Tschofenig'; [e-mail]
> > > 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:[e-mail]]
> > > > Sent: Tuesday, July 14, 2009 7:35 PM
> > > > To: Brian Rosen; Hannes Tschofenig; [e-mail]
> > > > 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:[e-mail]]
> > > > > Sent: Wednesday, 15 July 2009 7:14 AM
> > > > > To: 'Hannes Tschofenig'; Thomson, Martin; [e-mail]
> > > > > 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: [e-mail] [mailto:geopriv-
> > [e-mail]]
> > > On
> > > > > > Behalf Of Hannes Tschofenig
> > > > > > Sent: Tuesday, July 14, 2009 4:32 PM
> > > > > > To: 'Thomson, Martin'; [e-mail]
> > > > > > 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
> > > > > > >[e-mail]
> > > > > > >https://www.ietf.org/mailman/listinfo/geopriv
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Geopriv mailing list
> > > > > > [e-mail]
> > > > > > 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]
> 

------------------------------------------------------------------------------------------------
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]