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

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

All

If we go back to identifying who inserted a 
location, we have to go back to the "inserter=" 
and "inserted-by=" parameters, which bring back 
the "node-id", "host-id" and probably the 
"used-for-routing" paramters... this certainly 
makes things easier for phonebcp, but no one 
else  ;-)   because it'll probably increase the 
page count of this ID by ~10 pages.

Why are we suggesting not having the UAC send the 
composed location information?

That's just increasing complexity several fold.

James

At 07:04 PM 7/19/2010, Richard L. Barnes wrote:
>Certainly agree that there is one Target, so the 
>question is simply how to represent multiple 
>estimates of that target's location.
>
>Your analysis is correct that carrying separate 
>location objects effectively gives the LR the 
>responsibility for compositing, but I'm not sure 
>that's a bad thing.  The LR has an idea of what 
>application it's using the location information 
>for -- something an intermediary probably lacks 
>-- which can inform how it chooses or combines location values.
>
>The question then becomes how to provide the LR 
>with sufficient information to make these 
>decisions.  Beyond information in the location 
>object itself (e.g., accuracy or privacy 
>settings), it seems like the main data of interest would be:
>-- How the location information was determined, and possibly
>-- Who inserted the location object
>Along these dimensions, there's really no 
>difference between the one-object and 
>multiple-object cases.  In both cases, the 
>determination method will be in a <method> tag 
>inside the  <geopriv> element.  Neither option 
>provides much good information about who inserts 
>a location object -- the primary mechanism in 
>RFC 4479 is the <device> element (which isn't 
>really all that helpful), leaving you basically 
>with preference-ordering in either case (see RFC 5491).
>
>There are probably also scenarios where the 
>intermediary knows best, but allowing for 
>multiple location values would seem to allow for 
>either possibility: If an intermediary wants to 
>composite, it can, or it can just tack on what it has.
>
>So I think the question comes down to two things:
>1. Whether you want to allow entities *not* to composite
>2. Where you want your preference ordering (URI list or XML)
>3. How easy you want it to be to add objects
>
>Especially given the tidiness of the layering in 
>the multi-object model (w.r.t. 3), it seems like 
>allowing multiple objects wins on counts 1 and 
>3.  And on balance, probably point 2 as well, 
>since you can read the ordering without parsing any XML first.
>
>--Richard
>
>
>
>
>On Jul 19, 2010, at 7:19 PM, Peterson, Jon wrote:
>
>>
>>It sounds like you agree that there is one 
>>Target, at least. I’m not disagreeing that 
>>different entities might have different ideas 
>>about the location of the target; I just don’t 
>>see why that entails anything whether they 
>>should be in different presence documents or 
>>the same one. Again, this is just a question of 
>>whether a bald list in a header field value has 
>>enough syntactic richness to describe the 
>>relationship between those presence documents, 
>>or whether we should let RFC4479 do that job. 
>>All of those crufty parameters that had crept 
>>into the Geolocation header were symptoms of 
>>the lack of syntactic richness in that neck of 
>>the woods, as was the bloat in error codes related to their upkeep.
>>
>>As to composition, any presence architecture 
>>that has multiple sources of presence has to 
>>provide composition somewhere. If (as the 
>>previous location-conveyance document tacitly 
>>assumed) we deliver a bunch of separate 
>>presence documents from different sources all 
>>talking about the same presentity/Target to a 
>>watcher (an LR, in geopriv parlance), then the 
>>responsibility devolves to the LR/watcher to 
>>effectively perform composition – to try to 
>>understand the documents and how they relate to 
>>one another in order to derive a useful picture 
>>of the presentity’s presence. The problem is, 
>>the watcher is the least likely entity in the 
>>architecture to understand how all these bits of information fit together.
>>
>>Jon Peterson
>>NeuStar, Inc.
>>
>>
>>On 7/19/10 2:44 PM, "Richard L. Barnes" 
>><<[e-mail]>[e-mail]> 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
>><[e-mail]>[e-mail]
>>https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>>
>>_______________________________________________
>>sipcore mailing list
>><mailto:[e-mail]>[e-mail]
>>https://www.ietf.org/mailman/listinfo/sipcore
>
>_______________________________________________
>sipcore mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/sipcore