Re: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted)

["Thomson, Martin" <[e-mail]>]

Resolving the semantics of the header is the biggest problem.

My original view was that the intent was to convey the message that the referenced location information is for the entity identified in the From header.  The idea was the SIP request forged a link between the identity and the location in the PIDF-LO document.

I was later convinced that this sort of strong semantic was unnecessary.  The idea of “relevance” is a better way of approaching the problem.

Location can be conveyed in SIP already, so if the header is to have any value, it needs a clearly defined semantic.  How about:

The Geolocation header identifies a PIDF document by value or reference.  A Geolocation header indicates that a) this particular PIDF document contains location information and b) that this location information in particular may be relevant to the processing of the SIP request.

This is intentionally soft, but (I believe) not too vague.  Yes, you can make the leap from this to conclude that the Target and the request originator are one and the same.  A shorter jump would be to say that these entities are at the same location.  These stronger semantics are unnecessary… or at least hard to prove.

--

The reason that I proposed Content-Location is because it does away with the idea that there are multiple sources.  Instead, it identifies a single authority and resource.  That authority might compose multiple sources, but that becomes opaque.  If I think of a single HTTP resource, the idea that the resource might have different representations doesn’t cause (much) consternation.

The bigger problem arises when you allow free reign to different authorities which each have their different views.  Allow the inclusion of static and dynamic, but make it clear that both static and dynamic have to be the same thing/resource.

Once a single authority is isolated, then all you have to worry about is the contents of the PIDF.  We have the means to deal with that with 4479 (in general) and 5491 (for location specifically).

And the UAC makes the decision about which authority to nominate.

--Martin

p.s. Note that the definition wording above would preclude the use of a geo: URI.  I’m open to making the statement fuzzier, if there is consensus that other location formats are acceptable or desirable.

From: Peterson, Jon [mailto:[e-mail]]
Sent: Tuesday, 20 July 2010 7:29 AM
To: Thomson, Martin; Roger Marshall; James M. Polk; [e-mail]
Subject: Re: composition or just indirection (was: location-conveyance-03 just submitted)


I’m sure we’re all going to have to discuss this a bit in Maastricht, but there are a couple basic points here I think we need to tee up. I certainly didn’t mean to suggest that a request can only include a single location (i.e., that any contributing piece of location information designates the same place, just with varying degrees of accuracy or timeliness or something). Rather, I believe a presence document describes a single entity – multiple locations come about because various devices and services associated with that single entity may attribute various locations to the entity.

Getting back to fundamentals, we don’t need a Geolocation header in order to carry location in SIP. There are MIME bodies for that (including Content-Indirection bodies for LbyR, or perhaps Content-Location as you suggest), and we can include seventeen different location objects if we want to, regardless of whether there are zero or one or fifteen Geolocation headers. We don’t need a location conveyance specification or a Geolocation header to enable that, SIP has always been able to do it, and you’ll still be able to add random MIME bodies that contain location information even if there is a Geolocation header which does not point to them. So what does the Geolocation header and location conveyance specification buy us?

I’ve always naively thought that the Geolocation header provides a coupling between this particular SIP session and an entity whose location is designated by a PIDF document. The entity is the geopriv Target, and is probably (though not necessarily) related to the party identified by the classic From header field of the SIP request. The Geolocation header tells us that for the purposes of the SIP session being negotiated, the location of this Target is somehow relevant... the boldest interpretation would be that this Target’s location should be considered the source of the request. Just attaching location-aware MIME bodies without the Geolocation header to SIP requests doesn’t convey the same semantics – those bodies could mean anything, and presumably the receiving application would sort through them at its discretion.

Where I get confused is when I start trying to understand what it would mean semantically for a SIP session to be coupled with more than one Target. Again, I can imagine hypothetically a SIP request containing unsorted MIME bodies that talk about different Targets to assist some specific application that knows how to reconcile them, but here I mean using the Geolocation header to couple a SIP request with location information about different Targets. Is there actually a use case/requirement for that? If not, and we only want to couple a SIP request with one Target, then I fail to see why composing location information about the same Target into a single PIDF body would be a problem. Having location information about the same entity fail to be organized in one body through RFC4479 wouldn’t make sense, anyway.

I think if we understand the semantics by which the Geolocation header “couples” PIDF with a SIP session, then we’ll better understand all of this. If the Geolocation header only exists to notify lazy intermediaries that there are location-sensitive bodies in the request or somewhere out on the net, without implying anything about the Target or the relationship of those locations to the SIP request, then this whole specification is probably more trouble than it’s worth – it really wouldn’t provide much incremental value above the basic ability of SIP to carry all sorts of bodies, including location bodies. If there are, however, more binding semantics here, then we probably won’t be able to agree on the need for solitary or multiple Geolocation headers until we agree on what those semantics are.

Jon Peterson
NeuStar, Inc.


On 7/18/10 7:25 PM, "Thomson, Martin" <[e-mail]> wrote:
Hi Jon,

I admit a fair degree of sympathy for Roger’s suggestion.  After all, the ability to include multiple location “values” in the same SIP request is a feature that has existed for many years.  A number of implementations have come to rely on this mechanism; people are building and have built solutions based on earlier draft, fully aware of the risks in implementing an internet draft.

At some point, it might be necessary to swallow any discomfort and recognize that the consequences of an imperfect solution are less than the consequences of a change of the nature you suggest.

Altering perspective might offer a solution.

The idea that there are multiple items that are composited might be counterproductive.  In this world-view, you have to reconcile a number of perspectives.  In this, you are absolutely correct: doing that at two layers is bad.  Composition is a hard problem already.  Moving it into SIP only complicates it further.

The alternative is to imagine a single logical resource that represents the location of the Target.  A location by value is a representation of this resource: a snapshot.  Location by reference offers a means for any entity to identify and acquire a view of the resource, independent of that snapshot.  The authority for the resource might offer the same representation, or it could offer one better suited to the recipient.  The representation might be updated, it might be altered based on an authorization policy, or something else (language preferences).  Regardless of how it is represented, it is still the same resource.

In simple terms, you state that the request can only include a single _location_.  When a location value and reference are both included, they represent the _same_ location.

This is why I suggested that Content-Location be borrowed.  In HTTP, Content-Location says - if you want to know where this resource really lives, here is where you can find it.

Now this might be sheer sophistry, but it might offer a way out.  The composition problems are left out of SIP.

…