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

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

I tend to agree with James (P) about this - you seem to be advocating an increase in the number of “points of articulation”.

What I think Jon is pursuing is fewer such complications…without preventing any necessary flexibility.  This can be taken too far in either direction.

--Martin

From: Richard L. Barnes [mailto:[e-mail]]
Sent: Tuesday, 20 July 2010 10:04 AM
To: Peterson, Jon
Cc: Roger Marshall; [e-mail]; Thomson, Martin
Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted)

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]> 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]> 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

_______________________________________________
sipcore mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sipcore