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

From: "Elwell, John" <[email-masked]>
Date: Tue, 14 Jul 2009 07:40:19 +0100

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

---

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:
>All these many examples illustrate an implication that the 
>location target is the UAC. I am sure there are other places too.
>
>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:
>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: "Brian Rosen" <[email-masked]>
Date: Tue, 14 Jul 2009 16:10:25 -0400

I have raised this very issue with James, and verified it with Jon Peterson
and Robert Sparks, and the intention is that the Geolocation header can
carry the location of any target, the specific target being that identified
in the PIDF, and subject to the privacy requirements of that target.

It turns out to be useful to do this in a couple of cases I've run across,
although I'm somewhat surprised that everyone agreed it is okay to do so.

While I guess I could improve phonebcp by making an explicit statement that,
when sent to the PSAP, the location in the header must be that of the
caller, I do think it's clear enough that it is.

I'll do that in the next rev, although I don't want to hold up sending the
current version to the IESG over that tidbit.

Brian

> From: Elwell, John [mailto:[email-masked]]
> Sent: Tuesday, July 14, 2009 2:40 AM
> Subject: Confusion over target inSIP location-conveyance - and impact
> on ECRIT phonebcp
> 
> In 4.2 it states:

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Jul 2009 19:48:30 -0500

I still haven't seen an explanation on how to resolve the identity binding problem when location is provided by reference.  That's a small thing for phone-bcp, but not for location-conveyance.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian Rosen
> Sent: Wednesday, 15 July 2009 6:10 AM
> To: 'Elwell, John'; 'James M. Polk'; [email-masked]
> Subject: Re: [sipcore] Confusion over target inSIP location-conveyance
> - andimpact on ECRIT phonebcp
> 

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 00:27:38 -0500

Hi Jon,

Here's the problem:
I am sip:[email-masked].  I use HELD or DHCP to request a location URI.  This is what is put in my SIP INVITE.  A proxy dereferences this to determine where to route the call.  They encounter pres:[email-masked] in the resulting PIDF-LO.  The location information is ignored; it's not applicable to the requester.

The server that provides the location information has no basis to determine that the entity making a request and sip:[email-masked] are one and the same.  Thus, it cannot make this assertion.  HELD recommends the creation of a pseudonym for this reason.

How do we resolve this?

We could define a mechanism for asserting sip identity in other domains, such that HELD could use it.  Sounds a bit heavyweight to me.

Providing a linkage between the two in SIP might work, but it sounds like you don't want to do that.  Shame, because that's the easiest.  One simple way would be to add a ';me' parameter to the geolocation header, which links the UAC (identified in From:) to the location object, irrespective of the identified presentity.

--Martin

p.s. On a similar thread, I think I remember reading that sip:[email-masked] is the same as pres:[email-masked].  Is this guaranteed truth, or just highly likely?

> From: Jon Peterson [mailto:[email-masked]]
> Sent: Wednesday, 15 July 2009 3:11 PM
> To: Thomson, Martin
> Cc: Brian Rosen; Elwell, John; James M. Polk; [email-masked]
> There must be something I'm missing in this discussion, but I've found
> this issue with identity binding a bit elusive. PIDF documents (let
> alone PIDF-LO documents) necessarily contain a field designating the
> entity that the document is supposed to represent - the "entity"
> attribute of <presence>. Given that this attribute contains a URI, it
> can be as specific or opaque as is necessary for the application in
> question. It appears regardless of how the PIDF document is acquired
> (by
> reference or by value). In what way is this element insufficient
> exactly?
> 
> I would certainly be skeptical of any SIP-layer mechanism that is
> intended to provide a separate account of how a PIDF document is
> "bound"
> to the entity it represents.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> Thomson, Martin wrote:
> > I still haven't seen an explanation on how to resolve the identity
> binding problem when location is provided by reference.  That's a small
> thing for phone-bcp, but not for location-conveyance.
> >
> >
> >> although I'm somewhat surprised that everyone agreed it is okay to
> do
> >> so.
> >>
> >> While I guess I could improve phonebcp by making an explicit
> statement
> >> that,
> >> I'll do that in the next rev, although I don't want to hold up
> sending
> >> the
> >>>    means the SIP server is including its version of where it thinks
> >>>
> >> the
> >>
> >>>    UAC is, geographically."
> >>>
> >>> In 8:
> >>>    the UAC is merely telling the UAS where more than one Target is,
> >>>
> >> and
> >>
> phonebcp.
> >> In

---

From: Jon Peterson <[email-masked]>
Date: Tue, 14 Jul 2009 22:11:00 -0700

There must be something I'm missing in this discussion, but I've found 
this issue with identity binding a bit elusive. PIDF documents (let 
alone PIDF-LO documents) necessarily contain a field designating the 
entity that the document is supposed to represent - the "entity" 
attribute of <presence>. Given that this attribute contains a URI, it 
can be as specific or opaque as is necessary for the application in 
question. It appears regardless of how the PIDF document is acquired (by 
reference or by value). In what way is this element insufficient exactly?

I would certainly be skeptical of any SIP-layer mechanism that is 
intended to provide a separate account of how a PIDF document is "bound" 
to the entity it represents.

Jon Peterson
NeuStar, Inc.

Thomson, Martin wrote:
>>> One document that relies on location-conveyance is ECRIT's phonebcp.
>>>       
>> In
>>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 15 Jul 2009 07:19:37 +0100

So this is where we stand, from my point of view. We can pursue one of
several directions:

1) We decide that the identifier in the PIDF document is sufficient to
identify the target and, where it is important that the target be the
SIP requester (e.g., for SIP request routing), that this can easily be
determined by comparing the SIP From or PAI with the PIDF target
identifier. In this case, we would at least need to change the many
places in location-conveyance that imply that the location target is the
UAC. We would also need to add something to phonebcp (at its next
update) to point this out.

2) We decide that we need something explicit at the SIP level, such as
the ";me" parameter to the Geolocation header field that Martin
suggested, that says that the location target is indeed the UAC.

3) We decide that the location target MUST be the UAC. Brian tells me
there are use cases where greater flexibility would be desirable,
however (I don't know what these are).

John

> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: 15 July 2009 06:28
> To: Jon Peterson
> Subject: RE: [sipcore] Confusion over target inSIP 
> location-conveyance - andimpact on ECRIT phonebcp
> 
> Hi Jon,
> 
> Here's the problem:
> I am sip:[email-masked].  I use HELD or DHCP to request a 
> location URI.  This is what is put in my SIP INVITE.  A proxy 
> dereferences this to determine where to route the call.  They 
> encounter pres:[email-masked] in the 
> resulting PIDF-LO.  The location information is ignored; it's 
> not applicable to the requester.
> 
> The server that provides the location information has no 
> basis to determine that the entity making a request and 
> sip:[email-masked] are one and the same.  Thus, it cannot make 
> this assertion.  HELD recommends the creation of a pseudonym 
> for this reason.
> 
> How do we resolve this?
> 
> We could define a mechanism for asserting sip identity in 
> other domains, such that HELD could use it.  Sounds a bit 
> heavyweight to me.
> 
> Providing a linkage between the two in SIP might work, but it 
> sounds like you don't want to do that.  Shame, because that's 
> the easiest.  One simple way would be to add a ';me' 
> parameter to the geolocation header, which links the UAC 
> (identified in From:) to the location object, irrespective of 
> the identified presentity.
> 
> --Martin
> 
> p.s. On a similar thread, I think I remember reading that 
> sip:[email-masked] is the same as pres:[email-masked].  Is this 
> guaranteed truth, or just highly likely?
> 
> [mailto:[email-masked]] On
> > >> Behalf Of Brian Rosen
> > >> I have raised this very issue with James, and verified 
> it with Jon
> > >> Peterson
> > >> and Robert Sparks, and the intention is that the 
> Geolocation header
> > can
> > >> It turns out to be useful to do this in a couple of 
> cases I've run
> > >> across,
> > >>> "If a UAC has already conveyed location in the original 
> request of
> > a
> > >>>    retargeted based on the location of the UAC 
> initiating the call
> > or
> > >>>    SIP MESSAGE,"
> > >>>
> > >>> targets in a request, implying they cannot all be the 
> location of
> > the
> > >>> UAC.
> > >>>
> > >>> And in 6.2.1 it states:
> > >>> So we have inconsistency as to whether a conveyed 
> location is that
> > of
> > >>> they UAC or not.
> > >>>
> > >>> there, I cannot find any reference to a routing entity 
> looking to
> > see

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 01:38:33 -0500

That's a good characterisation of the choice.  I'll note that the cleanup from 1 also applies to 2.

As I stated, as I don't think that 1 is feasible for the aforementioned reasons.  Either of 2 or 3 are workable.

--Martin

> Sent: Wednesday, 15 July 2009 4:20 PM
> To: Thomson, Martin; Jon Peterson
> Cc: Brian Rosen; James M. Polk; [email-masked]
> Subject: RE: [sipcore] Confusion over target inSIP location-conveyance
> -andimpact on ECRIT phonebcp
> 
...

---

From: Jon Peterson <[email-masked]>
Date: Wed, 15 Jul 2009 00:54:54 -0700

My own interest in this discussion has largely been to prevent the 
conflation of the UAC with the geopriv target. I've argued that the UAC 
and the entity in the From header field value are not necessarily 
equivalent for the purposes of geopriv, thanks to aggregator UAs serving 
many users, such as IP PBXs, gateways and so forth. I've therefore 
resisted the proposal that the implicit semantics of the Geolocation 
header be "this is the location of the UAC." I feel less strongly about 
semantics of "this is the location of the entity in the From header 
field", be they implicit or explicit semantics. I can certainly imagine 
a version of the ";me" parameter as an explicit indication of these 
semantics that would not fall afoul of this conflation.

I do wonder, though, if the semantics of "routing-allowed" overlap with 
the intention behind ";me". Ultimately, a proxy server decides whether 
or not it will use the location in the SIP request for routing purposes. 
Your use case below assumes that the proxy server decision to route 
based on location is dependent on the PIDF referenced in the SIP request 
indicating the same target as the SIP layer identity. While ";me" is 
helpful in that case, I'm not sure that this should be the deciding 
criteria in all cases. "routing-allowed" communicates a less specific 
indication of "hey, I think you can use this to route the request", 
something that could be true even if, for whatever reason, the location 
in the SIP request doesn't represent the target of my SIP-layer 
identity, because due to some unusual circumstances the From header 
field of my request can't have a value that represents "me" at the 
moment - maybe it's an anonymous URI, for example.

My point here is that I think agreement on the sorts of policies that 
proxy servers should enforce has to inform the sorts of indications we 
feed into that policy. If we need a way to tell the proxy server that a 
referenced location is appropriate for routing, we might want something 
more explicit than ";me".

To your postscript, I'd have to say no, there's no necessary equivalence 
between the resources indicated by those two schemes, only convention 
links them.

Jon Peterson
NeuStar, Inc.

Thomson, Martin wrote:
>>>> Subject: Re: [sipcore] Confusion over target inSIP location-
>>>>         
>> conveyance
>>     
>>>> and Robert Sparks, and the intention is that the Geolocation header
>>>>         
>> can
>>     
>>>> when sent to the PSAP, the location in the header must be that of
>>>>         
>> the
>>     
>>>>> Subject: Confusion over target inSIP location-conveyance - and
>>>>>           
>> impact
>>     
>>>>> on ECRIT phonebcp
>>>>>
>>>>> In 4.2 it states:
>>>>>    location information before attempting a new request that
>>>>>           
>> includes
>>     
>>>>>    location."
>>>>> "This document gives no guidance how this is accomplished, given
>>>>>           
>> the
>>     
>>>>> "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
>>     
>>>>> "If a UAC has already conveyed location in the original request of
>>>>>           
>> a
>>     
>>>>>    retargeted based on the location of the UAC initiating the call
>>>>>           
>> or
>>     
>>>>>    SIP MESSAGE,"
>>>>>
>>>>> targets in a request, implying they cannot all be the location of
>>>>>           
>> the
>>     
>>>>> UAC.
>>>>>
>>>>> And in 6.2.1 it states:
>>>>> So we have inconsistency as to whether a conveyed location is that
>>>>>           
>> of
>>     
>>>>> they UAC or not.
>>>>>
>>>>> 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
>>     
>>> ---------------------------------------------------------------------
>>>       
>> ---------------------------
>>     
>>> ---------------------------------------------------------------------
>>>       
>> ---------------------------
>>     
>>> [mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 16:34:18 -0500

At 12:27 AM 7/15/2009, Thomson, Martin wrote:
>Hi Jon,
>
>Here's the problem:
>I am sip:[email-masked].  I use HELD or DHCP to request a location 
>URI.  This is what is put in my SIP INVITE.  A proxy dereferences 
>this to determine where to route the call.  They encounter 
>pres:[email-masked] in the resulting PIDF-LO.  The 
>location information is ignored; it's not applicable to the requester.

I'm having problems parsing this paragraph - and I believe you are 
conflating two issues that aren't the same.

In the above example, you same you are entity=sip:[email-masked] for 
any prsence document.

DHCP or HELD hands you a location URI that you don't show us in your example.

In the presence document, what element or attribute is the 
pres:[email-masked] found?

Is this in the entity= attribute?

If so, it's unlinkable -- unless the receiver understands the link between

         [email-masked]
and
         [email-masked]

However, how I'm reading the pres:[email-masked] 
URI, this looks an awful lot like a location URI (because of the 
'...@lis...' ). The entity= pres: URI shouldn't be something that's 
on a LIS in the way you use that term in the Geopriv Architecture.

The entity= attribute is more like an AOR that identifies you - 
Martin - as what the presence document is about (unless you want your 
presence document to be unlinkable except for your buddies).

>The server that provides the location information has no basis to 
>determine that the entity making a request and sip:[email-masked] are 
>one and the same.  Thus, it cannot make this assertion.  HELD 
>recommends the creation of a pseudonym for this reason.
>
>How do we resolve this?
>
>We could define a mechanism for asserting sip identity in other 
>domains, such that HELD could use it.  Sounds a bit heavyweight to me.

I don't get this connection - to how the LIS will somehow understand 
the layer 7 identity of a client it sends it's location URI to. How's 
that gonna work exactly?

More importantly, how's that *not* going to violate the understanding 
that LCPs never link identity with LCI?

>Providing a linkage between the two in SIP might work, but it sounds 
>like you don't want to do that.  Shame, because that's the 
>easiest.  One simple way would be to add a ';me' parameter to the 
>geolocation header, which links the UAC (identified in From:) to the 
>location object, irrespective of the identified presentity.

this totally blows up the idea of unkinkable pseudonyms that are a 
requirement from RFC 3693 - and I'm not going there unless everyone 
in both WGs agree, since that's an established security mechanism.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 16:49:29 -0500

>places in location-conveyance that imply that the location target is the

Linking the SIP signaling identity to the presence document entity 
mandates that there be zero possibility of "unlinkable pseudonyms" as 
stated in RFC 3693.

Further, this prevents a SIP request from having more than one 
PIDF-LO from difference targets in the same message.

As an alternative, we can advise that when a UAC knows a particular 
request will have to be routed based on the provided location, that 
the entity= attribute match the From header. This means only a change 
in phoneBCP, since there is a unique Geolocation-Error header value 
for this linkable to be present, though it doesn't suggest the From 
and entity= be the same (which could be added).

>We would also need to add something to phonebcp (at its next

this kills the capabilities for unlinkable pseudonyms that are 
required because of RFC 3693.

Martin's example problem doesn't make sense to me yet, because it 
appears that he claims the proxy will get a location URI *in* the 
PIDF-LO (where there is no place for one now).

>however (I don't know what these are).

see my earlier email for one good one that the younger generation 
wants already; there are others too.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 16:51:43 -0500

2 & 3 fly in the face of existing requirements from existing and 
relevant RFCs within Geopriv.'

1 already covered, and can be made more explicit with very minor additions.

James

At 01:38 AM 7/15/2009, Thomson, Martin wrote:
>As I stated, as I don't think that 1 is feasible for the 
>aforementioned reasons.  Either of 2 or 3 are workable.
>
>--Martin
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 17:08:45 -0500

I'm concerned that, as Jon says, the UAC might not have knowledge it 
is sending a SIP request that a proxy somewhere downstream decides it 
needs that location to use for routing.

We have the routing-allowed=no to prevent this from occurring, 
regardless of the ":me" header parameter.

I'm also concerned how a downstream proxy inserter of a target's 
location will understand if the target doesn't want to be linkable to 
the presence document?

What Conveyance -01 has now:

We have the Geolocation-Error code 400 that informs a location 
inserter that the routing-allowed needs to be 'yes' to properly 
process this SIP request.

We have the Geolocation-Error code 201 that informs a location 
inserter that the entity= attribute is unlinkable, and needs to be 
rectified. I didn't add that it ought to match the From header, but I 
have no issues adding that text. That's easy and would be clean if 
the WG thinks that's a good way forward.

The phoneBCP can articulate their particular use-case better.

James

At 02:54 AM 7/15/2009, Jon Peterson wrote:

>conflation of the UAC with the geopriv target. I've argued that the 
>UAC and the entity in the From header field value are not 
>necessarily equivalent for the purposes of geopriv, thanks to 
>aggregator UAs serving many users, such as IP PBXs, gateways and so 
>forth. I've therefore resisted the proposal that the implicit 
>semantics of the Geolocation header be "this is the location of the 
>UAC." I feel less strongly about semantics of "this is the location 
>of the entity in the From header field", be they implicit or 
>explicit semantics. I can certainly imagine a version of the ";me" 
>parameter as an explicit indication of these semantics that would 
>not fall afoul of this conflation.
>
>I do wonder, though, if the semantics of "routing-allowed" overlap 
>with the intention behind ";me". Ultimately, a proxy server decides 
>whether or not it will use the location in the SIP request for 
>routing purposes. Your use case below assumes that the proxy server 
>decision to route based on location is dependent on the PIDF 
>referenced in the SIP request indicating the same target as the SIP 
>layer identity. While ";me" is helpful in that case, I'm not sure 
>that this should be the deciding criteria in all cases. 
>"routing-allowed" communicates a less specific indication of "hey, I 
>think you can use this to route the request", something that could 
>be true even if, for whatever reason, the location in the SIP 
>request doesn't represent the target of my SIP-layer identity, 
>because due to some unusual circumstances the From header field of 
>my request can't have a value that represents "me" at the moment - 
>maybe it's an anonymous URI, for example.
>
>My point here is that I think agreement on the sorts of policies 
>that proxy servers should enforce has to inform the sorts of 
>indications we feed into that policy. If we need a way to tell the 
>proxy server that a referenced location is appropriate for routing, 
>we might want something more explicit than ";me".
>
>To your postscript, I'd have to say no, there's no necessary 
>equivalence between the resources indicated by those two schemes, 
>only convention links them.
>
>Jon Peterson
>NeuStar, Inc.
>
>Thomson, Martin wrote:
>>Hi Jon,
>>
>>Here's the problem:
>>determine that the entity making a request and sip:[email-masked] 
>>are one and the same.  Thus, it cannot make this assertion.  HELD 
>>sounds like you don't want to do that.  Shame, because that's the 
>>geolocation header, which links the UAC (identified in From:) to 
>>the location object, irrespective of the identified presentity.
>>
>>--Martin
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Jul 2009 18:10:10 -0500

Thanks Jon, that's really helpful.  I hadn't thought about the UAC/From disconnect in that way.

The explicit indication is very much what I'm looking for.  This can either link the identity in the From with the presentity; or - as I prefer - link the identity in the From to the location in the PIDF-LO.  The current version of conveyance only offers errors in this case.  It would be much better to ensure that the call succeeds, especially since the UAC likely has no means to correct this sort of error in many circumstances.

With a correction to its semantics to either of the above, routing-allowed could work.  However, it might be better then to remove the following constraint:

   The "routing-allowed" header field parameter is a global parameter
   over any (and all/each) locationValues...

With respect to my question on pres/sip/sips, that makes this binding even more important.  Even the examples assume that sip:[email-masked] == pres:[email-masked].

--Martin

> Sent: Wednesday, 15 July 2009 5:55 PM
> To: Thomson, Martin
> equivalence
> URI.  This is what is put in my SIP INVITE.  A proxy dereferences this
> to determine where to route the call.  They encounter
> like you don't want to do that.  Shame, because that's the easiest.
> One simple way would be to add a ';me' parameter to the geolocation
> header, which links the UAC (identified in From:) to the location
> object, irrespective of the identified presentity.
> >
> > --Martin
> >
> location
> that

---

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.