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

["James M. Polk" <[e-mail]>]

Richard

Let's not forget the cost of having more than one 
document in terms of additive bytes in the 
request. Adding another <geopriv> or <device> 
element is not that much more data, whereas 
adding a second or third PIDF would be a lot more.

James

At 04:44 PM 7/19/2010, Richard L. Barnes wrote:
>While it's correct to say that one presence 
>document describes a single entity, it's not 
>necessarily true that multiple presence 
>documents describe multiple 
>entities.  Regardless of how we define the 
>entity in the session that is the target (IIRC, 
>earlier versions said something like "the UAC 
>that initiated the dialogue"), it seems 
>plausible that different entities processing a 
>SIP message might have different ideas as to the 
>location of the target.  In this case, it would 
>seem plausible to have multiple location objects 
>in a single message, all of which have the 
>semantic that they're describing the location of 
>the target (however the target is coupled to the session).
>
>Speaking more practically, if we accept the 
>assertion that multiple location values will be 
>necessary (whether in a single document or not), 
>then it seems much cleaner to have them in 
>separate presence documents, with separate CID 
>URIs.  I don't really see any reason for any of 
>this to call for more than one Geolocation 
>header, since you can just add more URIs.
>
>
>
>On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote:
>
>>
>>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]>[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]>[e-mail] SIP/2.0
>>    Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
>>    Max-Forwards: 70
>>    To: Bob <sips:<[e-mail]>[e-mail]>
>>    From: Alice 
>> <sips:<[e-mail]>[e-mail]>;tag=9fxced76sl
>>    Call-ID: 
>> <[e-mail]>[e-mail]
>>    Geolocation: 
>> <cid:<[e-mail]>[e-mail]>
>>      ;routing-allowed=no
>>    Supported: geolocation
>>    Accept: application/sdp, application/pidf+xml
>>    CSeq: 31862 INVITE
>>    Contact: <sips:<[e-mail]>[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]>[e-mail]>
>>    Content-Location: 
>> pres:<[e-mail]>[e-mail]?location/XJhbXM6eG1sOm5zOnBpZ
>>
>>    <?xml version="1.0"?>
>>    ...PIDF-LO document
>>    --boundary1--
>>
>>
>>--Martin
>>
>>---- Original Message ----
>>From: Peterson, Jon 
>>[<mailto:[e-mail]>mailto:[e-mail]]
>>Sent: Friday, 16 July 2010 4:54 PM
>>To: Roger Marshall; Thomson, Martin; James M. 
>>Polk; <[e-mail]>[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.
>>
>>…
>>
>>_______________________________________________
>>sipcore mailing list
>><mailto:[e-mail]>[e-mail]
>>https://www.ietf.org/mailman/listinfo/sipcore