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
