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

["Peterson, Jon" <[e-mail]>]

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