Subject: Re: [Geopriv] [sipcore] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 14 Jul 2009 15:29:34 +0300

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.

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: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Elwell, John
>Sent: 14 July, 2009 09:40
>To: James M. Polk; [email-masked]; 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 23:01:48 -0500

>       "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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Jul 2009 00:06:22 -0700

> targets use a presence document. So, while the device ID should not be 

Therein lies the rub.  The presentity and target have different identities. They're not even at the same layer.  
And both may differ from the identity in the From: field. 

> 6.6 confuses the two forms of identity, and needs to be changed.

I'm not sure it confuses them, but the guidance may not be sound.  In particular, there are security consequences.