>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.
Good to hear that.
(A small correction: It is more about SIP loc filters and HTTP deref as
mechanisms to retrieve location rather than SIP and HELD.)
>
>I think you could easily force a civic by requiring country
>code field, with something similar for the geo.
I don't think that this would work. Maybe I misunderstand the functionality
of RFC 4661 but you cannot require certain fields to be present.
>
>I suspect, but haven't thought out how to do something similar
>to force a particular shape
I also see challenges here.
>
>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.
The quality parameters that are described in HELD do not require any
extensions to PIDF.
The quality parameters Martin has been working on provide more functionality
and I would not want to include them into this document to keep it simpler.
I will try to compile a version to give folks a chance to see how it looks
like.
Ciao
Hannes
>
>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
