Re: [Geopriv] loc-filters additional requirements

["Hannes Tschofenig" <[e-mail]>]

We could use RFC 4661 for some things quite nicely. There are, however,
limits. 
Here I agree with Martin that we create funny constructs RFC 4661 and might
still not quite get what we are looking for. At this point we should just
define extensions that are easier to understand and to implement. 

Ciao
Hannes

>-----Original Message-----
>From: Thomson, Martin [mailto:[e-mail]] 
>Sent: 15 July, 2009 02:35
>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:[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]
>