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

["Roger Marshall" <[e-mail]>]

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.

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

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 for 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.