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

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

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.

…