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

["Richard L. Barnes" <[e-mail]>]

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]>  
> 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.
>
> …
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore