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

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

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.

I can write up a more detailed strawman, but for now, I'll just include an example:

   INVITE sips:[e-mail] SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:[e-mail]>
   From: Alice <sips:[e-mail]>;tag=9fxced76sl
   Call-ID: [e-mail]
   Geolocation: <cid:[e-mail]>
     ;routing-allowed=no
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:[e-mail]>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1
   Content-Type: application/sdp

   ...SDP goes here

   --boundary1
   Content-Type: application/pidf+xml
   Content-ID: <[e-mail]>
   Content-Location: pres:[e-mail]?location/XJhbXM6eG1sOm5zOnBpZ

   <?xml version="1.0"?>
   ...PIDF-LO document
   --boundary1--


--Martin

---- Original Message ----
From: Peterson, Jon [mailto:[e-mail]]
Sent: Friday, 16 July 2010 4:54 PM
To: Roger Marshall; Thomson, Martin; James M. Polk; [e-mail]
Subject: Re: [sipcore] location-conveyance-03 just submitted


In the corner case (and I do think it is a corner case) where multiple entities are contributing different location information to a single SIP request, I think we face a fundamental architecture choice in this mechanism: either it is SIP's job to sort out how we understand those different locations, or it is PIDF's job.  Traditionally, PIDF's understanding of different sources of presence that provide potentially contradictory information relies on the presence data model (RFC4479), which is designed to reconcile conditions like the one where my mobile phone thinks I am available but my desktop thinks I'm offline. The presence data model moreover differentiates between users, services and devices in a way that is useful and apparently applicable to location information. I am not eager to try to replicate this in SIP headers, including by inserting multiple such headers, putting in markup that tries to explain the "source" of location information in SIP headers, and so on. SIP's job should be to convey the location object - fundamentally, the further we diverge from "conveyance" and enter into the realm of "integration," the less comfortable I get.

I understand that the subsequent use case where there are different sources of location information, some of which are LbrV and some of which are LbyR, looks like a  hairy one. This is, however, a corner case of a corner case. I really do not feel comfortable justifying the allowance of multiple location headers in SIP pointing to different presence objects (as opposed to following the presence data model) to carry the 0, 1 or 2 different locations due to a corner case of a corner case. As I said in my previous mail to Martin, I'm not really sure I even understand the requirements for an intermediary to evaluate and reject LbyR, nor what the best way is for presence from these dynamic sources to be composed. If we were to investigate the right way for presence from those source to be composed, it might very well be that it is the responsibility of the compositor to insert an LbyR into the SIP request (into the Geolocation header), and to poll and compose a coherent PIDF document from its dynamic and static sources - that is probably the approach that most closely parallels the traditional approaches to presence. But we haven't even begun to explore this yet. No one insisting that there will be "empty" PIDF documents just containing references to external PIDF documents or something. Something along those lines is one approach of many that we would consider if we tried to figure out how to address this in PIDF. The question we need to decide, as I said above, is the architecture one - is SIP's job to convey PIDF documents, or to compose them?

Jon Peterson
NeuStar, Inc.

...