My response would be that the answer to your question about what the
location actually refers to is given in the 'entity' attribute of the
<presence> element. The problem is only that we say in other places that
the info put into this field should be obfuscated:
As noted in the "HTTP Enabled Location Delivery (HELD)"
[I-D.ietf-geopriv-http-location-delivery] Section 6.6:
The LIS MUST NOT include any means of identifying the Device in
the PIDF-LO unless it is able to verify that the identifier is
correct and inclusion of identity is expressly permitted by a Rule
Maker. Therefore, PIDF parameters that contain identity are
either omitted or contain unlinked pseudonyms [RFC3693]. A
unique, unlinked presentity URI SHOULD be generated by the LIS for
the mandatory presence "entity" attribute of the PIDF document.
Optional parameters such as the "contact" element and the
"deviceID" element [RFC4479] are not used.
Ciao
Hannes
PS: I also did a review some time back
http://www.ietf.org/mail-archive/web/geopriv/current/msg06955.html
I am not sure all my comments got addressed already :-)
>-----Original Message-----
>From: sipcore-bounces@ietf.org
>[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Elwell, John
>Sent: 14 July, 2009 09:40
>To: James M. Polk; sipcore@ietf.org; Brian Rosen
>Subject: [sipcore] Confusion over target inSIP
>location-conveyance - and impact on ECRIT phonebcp
>
>In 4.2 it states:
>"The UAC can use whatever means it knows of to verify/refresh its
> location information before attempting a new request that includes
> location."
>"its location information" suggests that the UAC is the target.
>
>In 4.3.3 it states:
>"This document gives no guidance how this is accomplished, given the
> number of ways a UAC can learn its location"
>which suggests similar.
>
>Similarly in 6.1:
>"If a UAC does not learn and store its location locally (a GPS chip)
> or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR
> URI (from DHCP for example)."
>Which suggests that a UAC inserts its location, not some other
>location.
>
>And later in 6.1:
>"If a UAC has already conveyed location in the original request of a
> transaction, and wants to update its location information ..."
>
>In 6.2:
>"If the LbyR URI is
> sip:, sips: or pres:, and the UAS wants to learn the UAC's
>location,"
>
>In 6.2.1:
>"This
> means the SIP server is including its version of where it thinks the
> UAC is, geographically."
>
>In 8:
>"Conveyance of physical location of a UAC raises privacy concerns"
>
>and:
>"In cases where a session set-up is
> retargeted based on the location of the UAC initiating the call or
> SIP MESSAGE,"
>
>All these many examples illustrate an implication that the
>location target is the UAC. I am sure there are other places too.
>
>I found a couple of places that contradict this. In 6.2 it states:
>"If there
> is more than one PIDF-LO with different Target identifiers, then
> the UAC is merely telling the UAS where more than one Target is, and
> there should not be any conflict."
>
>I think there are other places that mention locations of
>multiple targets in a request, implying they cannot all be the
>location of the UAC.
>
>And in 6.2.1 it states:
>"The Location Target identified in
> the PIDF-LO may or may not be the location inserter, or the
> generator of the request (the UAC or SIP server)."
>
>So we have inconsistency as to whether a conveyed location is
>that of they UAC or not.
>
>One document that relies on location-conveyance is ECRIT's
>phonebcp. In there, I cannot find any reference to a routing
>entity looking to see whether a conveyed location has the
>caller as target or not. It just assumes that this is the
>case. So if we were to agree that a conveyed location is not
>necessarily the location of the UAC, this will have impact on phonebcp.
>
>John
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
