>You raise a very good point, John.
>
>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.
Hannes - "identifying the Device" is something bad, and I agree with you.
But -- that's not what the 'entity=' attribute is for.
The 'entity= attribute' specifically is the presentity's URI (see RFC 4479).
Geopriv doesn't exactly have presentities, we have targets - yet
targets use a present document. So, while the device ID should not be
included in the XML, the entity= has to be.
BTW - the text from [I-D.ietf-geopriv-http-location-delivery] Section
6.6 confuses the two forms of identity, and needs to be changed.
There's device ID -- which RFC 4479 talks about being the MAC address.
There's entity= attribute, which is the presentity's identity, such
as a Layer 7 AOR like URI.
these are completely different.
James
>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
