Re: [sipcore] location-conveyance-03 just submitted

["James M. Polk" <[e-mail]>]

At 05:56 PM 7/15/2010, Roger Marshall wrote:
>All:
>My understanding of what this conveyance-03 
>draft now allows for is support of location in terms of:
>
>LbyV if the geolocation header contains a cid 
>URI which points to a PIDF-LO in the body
>Or
>LbyR if the geolocation header contains a location URI
>Or
>Both LbyV & LbyR _only_ if the PIDF-LO that the 
>cid URI points to also includes an "associated" 
>Location URI within.  This is what I assume is the composite case.

you can also have a composed value from two or 
more entities proposing they know where the Target is.


>If this is how it's intended to work, how then 
>would routing be accomplished if the intention 
>was to route on location URI, not LbyV?

The intermediary would dereference the location 
URI and receive a PIDF-LO to route the original 
SIP request upon. The "routing-allowed" parameter 
would need to be set to "yes" or the intermediary 
would return a 424 with a Geolocation-Error 
header value 302 "Permission to Route based on 
Location Information". The UAC would then choose 
whether or not to give permission (in a subsequent request).



>The geolocation header parameter value of 
>"routing-allowed" can only be yes or no pointing to the whole PIDF-LO:
>
>[from -03]
>    The practical implication is that when the "routing-allowed"
>    parameter is set to "no", if a cid:url is present in the SIP
>    request, intermediaries MUST NOT view the location (because it is
>    not for intermediaries to view), and if a location URI is present,
>    intermediaries MUST NOT dereference it.  UAs are allowed to view
>    location in the SIP request even when the "routing-allowed"
>    parameter is set to "no".  An LR MUST by default consider the
>    "routing-allowed" header parameter as set to "no", with no
>    exceptions, unless the header field value is set to "yes".
>
>It seems to me that a better way is to allow 
>geolocation URIs in numbers of 0, 1, or 2, so 
>that you could elevate the Location URI up to 
>the geolocation header and avoid all the 
>difficulties of not knowing what location form 
>was routable, plus escape the overhead of 
>embedding it into an otherwise empty PIDF-LO when using LbyR exclusively.

if there is no cid-URL (meaning no PIDF-LO), the 
one locationValue can be a location URI. This 
also solves what your concerns are above, don't they?

James


>Regards,
>
>-roger marshall.
>
>
>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Thomson, Martin
>Sent: Wednesday, July 14, 2010 6:34 PM
>To: Peterson, Jon; James M. Polk; [e-mail]
>Subject: Re: [sipcore] location-conveyance-03 just submitted
>
>Hi Jon,
>
>There’s a number of issues here.  I think that 
>we need to disentangle them.  The role of the 
>intermediary in this dealing with this problem is a secondary concern.
>
>There are two primary reasons for having both 
>value and reference: authorization and dynamism.
>
>Dynamism is the easiest one to pin down.  It's 
>obviously very important to the emergency 
>scenario - the ability of a PSAP to acquire 
>updated location information in a timely fashion 
>is central to many of their use cases.
>
>draft-ecrit-rough-loc describes a scenario where 
>the UAC is less authorized than the UAS; 
>intermediaries are authorized differently.  In 
>the canonical example, the UAS gets a rubbish 
>location value and a location reference that 
>they can't use.  The rubbish location is enough 
>to get them to a PSAP.  The PSAP uses the 
>reference because they are authorized.
>
>In either case, it's possible to leave the 
>intermediary out of consideration and 
>concentrate on the information that the UAC 
>provides.  The great thing with the solution 
>that you've proposed is that this is ultimately 
>what happens in any case.  Leaving the b2bua 
>case aside, the UAC is ultimately responsible 
>for what Geolocation is placed in the request.
>
>The interactions with the intermediary add 
>complexity to the scenario, including some 
>privacy model problems, primarily with 
>retransmission.  I'd like to solve the easier problem first.
>
>--Martin
>
>
>From: Peterson, Jon [mailto:[e-mail]]
>Sent: Thursday, 15 July 2010 3:09 AM
>To: Thomson, Martin; James M. Polk; [e-mail]
>Subject: Re: [sipcore] location-conveyance-03 just submitted
>
>
>[snip]
> > We mean to have the intermediary do the
> > dereference (if one is needed) and compose in the
> > SIP 424 response a MIME body with both the
> > server's version or both locations of the Target,
> > and for that dual location single presence
> > document to be copied into the next SIP request
> > from that UAC (towards that same intermediary).
>
>Elegant as it is, this just doesn't work. Â The 
>UAS (PSAP, LR, etc...) needs to be the entity 
>that does the dereference. Â They need to do 
>this because they know how (and when) to make 
>this request so that they get the information 
>they need. Â If the intermediary does the 
>dereference, then location information is set in stone from that point onward.
>
><JFP> I see your point, but I think the 
>difficulty is deeper still than this. The whole 
>use case for an intermediary providing different 
>(or supplementary) location information above 
>and beyond the location provided by the UAC is 
>based on the intermediary inspecting, and 
>disliking, the location present in the request. 
>If that location is constantly changing, what 
>would it mean for the intermediary to dislike 
>it? Maybe it likes it one minute and not the 
>next? Would it ­ever- be safe foor a picky 
>intermediary to allow a reference to pass it, 
>given that it couldn’t control what location 
>the LR would ultimately get from it? Moreover, 
>what if the creator of the reference authorizes 
>the end recipient (the PSAP) but not the 
>intermediary that wants to judge location 
>information? I think we’d need to look further 
>into the motivations here to understand the underlying requirement.
>
>Practically speaking, however, there are a 
>number of potential work-arounds to enable this 
>semantic ­ I don’™t necessarily think that 
>once the intermediary performs the dereference, 
>then the location information must be set in 
>stone. If you seriously want to retain the 
>dynamism of location information, it could 
>become the responsibility of the compositor to 
>deliver a similarly dynamic reference, and every 
>time someone dereferences the composed object, 
>the compositor creates a new PIDF-LO document 
>based on freshly dereferencing any dynamic 
>components of the location information. Another 
>possibility would be to specify external 
>references in PIDF, so we could compose location 
>information from dynamic sources by reference in 
>the PIDF object, rather than by value. One 
>composed object could even have a mix of 
>by-value and by-reference location information 
>in that case. The important thing is that we 
>solve this down in the PIDF level, within the 
>parameters of RFC4479, rather than trying to 
>cobble together some relationship between 
>devices, services and users in the Geolocation header.
>
>Anyway, none of this is to suggest that this is 
>adequately specified in the current draft, or 
>something. We’d need to have a more lengthy 
>discussion about some of the issues above before 
>figuring out what we’d add, though.
>
>Jon Peterson
>NeuStar, Inc.
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore
>
>CONFIDENTIALITY NOTICE: The information 
>contained in this message may be privileged 
>and/or confidential. If you are not the intended 
>recipient, or responsible for delivering this 
>message to the intended recipient, any review, 
>forwarding, dissemination, distribution or 
>copying of this communication or any 
>attachment(s) is strictly prohibited. If you 
>have received this message in error, please 
>notify the sender immediately, and delete it and 
>all attachments from your computer and network.