[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req
At 09:30 AM 5/29/2008, Liess, Laura wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_001_01C8C198.9BFCB0AB"
>
>Here is my personal hum and the hum of my company in favour of the
>"location hiding requirements" documenting effort.
>
>An additional comment:
>James Polk also raised a very good point: users or end devices
>providing false location. But, as Brian pointed out, "a user or a
>device can always lie." In my opinion, if we choose the right
>solution(s), location hiding can improve this situation and minimize
>the risk that users lie about the location (and make the PSAPs life easier).
>I don't want to discuss location hiding solutions, just try to an
>example where, in my opinion, the location information received by
>the PSAPs is more reliable with location hiding than without
>it. Example: if an end device finds out the ESRP (LOST query) based
>on a coarse location and sends in the INVITE to the ESRP instead of
>the precise location a location URI, the ESRP gets the precise
>location from the LIS based on the location URI. The ESRP then sends
>the precise location directly to the PSAP. Both the ESRP and the
>LIS are local and trusted by the local PSAP.
Laura - you are assuming location is always provided by-reference,
and not by-value (as demonstrated in your example by the PSAP
retrieving more precise location from the LIS through another
transaction). What if the UA's location is GPS derived, or otherwise
given to the UA by-value?
>
>Laura
>
>
>
>----------
>Von: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] Im
>Auftrag von hannes.tschofenig at nsn.com
>Gesendet: Dienstag, 13. Mai 2008 09:10
>An: ecrit at ietf.org
>Betreff: [Ecrit] Hum: draft-schulzrinne-ecrit-location-hiding-req
>
>
>Hi all,
>
>Henning gave a presentation about this draft at previous IETF
>meetings. Although this is a controversal topic we believe it is
>important to capture the problem statement and the requirements.
>This document is NOT meant to capture solutions -- this is something
>for future work. We would therefore like to confirm the hum on the
>mailing list. If you have not stated your opinion or if you object
>please let us know.
>
>Deadline for your response: 30 May 2008
>
>Ciao
>Hannes & Marc
>_______________________________________________
>Ecrit mailing list
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit