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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
