Subject: [sipcore] FW: Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp

From: Marc Linsner <[email-masked]>
Date: Fri, 17 Jul 2009 09:15:39 -0400

Jon, Martin,

In reviewing RFC4479, I'm struggling with the premise that one can convey a
location value via SIP in a document that has no Person component in the
Presentity.  My interpretation of RFC4479 is that a Presence document MUST
contain Person data within the Presentity data model, it's the top of the
hierarchy.  Therefore lack of Person data renders the document not valid.
I've always viewed the locationResponse sent from a HELD server as Location
Configuration Information (LCI), equivalent to LCI returned by DHCP (or
LLDPMED).  (Of course, this is contrary to the implication in the HELD draft
and might need to be addressed before publication.)  Hence, the LCI data is
not a valid Presence document until the UA completes/changes the Presentity
attributes.

I'm not sure overriding the Person data (or lack thereof) in the Presentity
by simply appending ";me" is correct, nor should it be allowed.  This runs
contrary to the premise that the two documents should stand alone without
dependencies on one another.

What am I missing?

-Marc-

>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:
>>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?
>>
>>
>>>-----Original Message-----
>>>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]
>>>Subject: Re: [sipcore] Confusion over target inSIP location-conveyance
>>>- andimpact on ECRIT phonebcp
>>>
>>>
>>>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.
>>>
>>>>
>>>>>-----Original Message-----
>>>>>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
>>>>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Elwell, John [mailto:[email-masked]]
>>>>>>Sent: Tuesday, July 14, 2009 2:40 AM
>>>>>>To: James M. Polk; [email-masked]; Brian Rosen
>>>>>>Subject: 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
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>
>>>---------------------------
>>>
>>>>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]
>>>>_______________________________________________
>>>>sipcore mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/sipcore
>>>>
>>>>
>>
>>------------------------------------------------------------------------------
------------------
>>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: Jon Peterson <[email-masked]>
Date: Fri, 17 Jul 2009 10:42:40 -0700

I don't think it's fair to say that a URI generated by the HELD server 
is this case cannot designate a "Person" per the data model. It merely 
doesn't designate a person with an address-of-record style name (like 
the Presentity URI, which is what I gather you'd prefer to see in the 
entity attribute). A person can be the resource identified by any number 
of URIs, and there's no requirement that they all display human-readable 
niceties. At a high level, I think you can cast this problem as linking 
that pseudonym with a well-known URI of the user.

Moreover, considering the applicability of geopriv broadly, I would 
hesitate to assert that presence documents must be about people, perhaps 
especially for the case where presence documents contain location 
information. We've talked many times about tracking inanimate objects 
like palettes with geopriv, for example. RFC4479 is certainly written 
from the perspective that presence is about people, and although there 
are people involved in the location of palettes (notably the 
owner/shipper of the palette, who probably would act as a Rule Maker and 
thus exert the "person"-level controls per the data model), it is not 
the location of those people we are tracking, but the location of a 
separate target.

Finally, I do think there is a distinction architecturally between this 
usage of HELD and of LCP, since effectively the HELD server here acts as 
an LG, not as a LIS. While we can argue the wisdom of this approach, I 
think the role it instantiates in the architecture is not especially 
ambiguous.

Jon Peterson
NeuStar, Inc.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 17 Jul 2009 16:03:13 -0500

Jon

Specific to your last paragraph below, I think Marc is arguing that 
this HELD server doesn't form a RFC 4479 (or is it 3863?) compliant 
PIDF in the first place.

James

BTW - I don't believe he is arguing that Geopriv MUST treat 
everything like it's a person (we all know Geopriv covers much more 
than people), but if it *is* a person (that's the target), that 
person should be treated according to 4479, not as a palette.   ;-)

At 12:42 PM 7/17/2009, Jon Peterson wrote:

>I don't think it's fair to say that a URI generated by the HELD 
>server is this case cannot designate a "Person" per the data model. 
>It merely doesn't designate a person with an address-of-record style 
>name (like the Presentity URI, which is what I gather you'd prefer 
>to see in the entity attribute). A person can be the resource 
>identified by any number of URIs, and there's no requirement that 
>they all display human-readable niceties. At a high level, I think 
>you can cast this problem as linking that pseudonym with a 
>well-known URI of the user.
>
>hesitate to assert that presence documents must be about people, 
>perhaps especially for the case where presence documents contain 
>location information. We've talked many times about tracking 
>inanimate objects like palettes with geopriv, for example. RFC4479 
>is certainly written from the perspective that presence is about 
>people, and although there are people involved in the location of 
>palettes (notably the owner/shipper of the palette, who probably 
>would act as a Rule Maker and thus exert the "person"-level controls 
>per the data model), it is not the location of those people we are 
>tracking, but the location of a separate target.
>
>Finally, I do think there is a distinction architecturally between 
>this usage of HELD and of LCP, since effectively the HELD server 
>here acts as an LG, not as a LIS. While we can argue the wisdom of 
>this approach, I think the role it instantiates in the architecture 
>is not especially ambiguous.
>
>Jon Peterson
>NeuStar, Inc.
>
>Marc Linsner wrote:
>>Jon, Martin,
>>