Subject: [sipcore] location-conveyance-03 just submitted

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Jul 2010 18:55:06 -0500

SIPCORE

http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-03.txt

This version is a fairly radical departure from previous versions of 
the (long standing) effort.  This time the doc didn't grow...

We added Jon Peterson as a co-author, and he helped in Anaheim 
propose a significantly less complex way of specifying location 
conveyance for SIP. More than 95% of the doc has been rewritten by 
Jon and I, with a net result of 27 less pages of text (52 to 25 now).

We took out the terms and concepts of following parameters:

- inserter
- inserted-by
- used-for-routing
- host-id
- node-id

as well as limiting the number of locationValues to *ONE*, in a SIP request.

We removed the ability for SIP intermediaries to add location along 
the way unbeknownst to the UAC (with one infrequently used 
exception). In this way, location errors are only end-to-end, so 
there is no need to identify which entity added location to make sure 
the right entity reacted the right way when an error was caused by 
the location they inserted, and not that of another entity's inserted 
location (which is all very confusing).

We added the ability for a SIP intermediary to augment a location 
with what the UAC should send in a subsequent request, and the 
ability to verify this augmentation is present before successfully 
processing that request. This is in line with both RFCs 4479 and 5491.

Comments are appreciated

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 13 Jul 2010 13:55:51 +0800

Firstly, the good:

The simplifications are a great improvement.  The document is more accessible and readable as a result.  The mechanism is fundamentally simpler.

Content indirection has some interesting benefits.  It's a good idea.

I have some comments that includes one major issue.

The major issue:

The limitation to _one_ location value has undeniable benefits.  It also prevents the conveyance of location value and reference together.

draft-ietf-ecrit-rough-loc describes one use case that this affects.  Brian (your other co-author) should be able to apprise you of the consequences this has to the NENA use cases.

Jon's original response to this was to push the composition problem to the PIDF-LO.  That could be done, but it needs more specification.

Reaching some sort of consensus on the solution to this problem before this work is finished is important.

Minor issues:

The structure of the Geolocation-Error header description is a little odd.  It seems that you are trying to describe *classes* of error and specific errors at the same time.  Separating these concerns might make this easier to explain and understand.

The draft doesn’t really justify the existence of the "geolocation" option tag.

Section 4.6 should reference draft-ietf-geopriv-deref-protocol.

Section 5 should show an example use of content indirection for a location URI.

Just a few nits:

Overall, the structure is greatly improved, but when you see references in the form "in section 3 (below Figure 4)", you have a need for more sub-sections.

The examples in Section 5 are not schema-valid - c.f. RFC 4119 errata #1771
  <http://www.rfc-editor.org/errata_search.php?rfc=4119>

This, in the introduction, doesn't read well:

  a non-IP device (a person or a black phone)

"black phone" is a little jargon-y.  More amusing was the idea that your characterisation of a person was as a "non-IP device".

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Tuesday, 13 July 2010 9:55 AM
> To: [email-masked]
> Subject: [sipcore] location-conveyance-03 just submitted
> 
> SIPCORE
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Jul 2010 01:29:45 -0500

Martin

in-line

At 12:55 AM 7/13/2010, Thomson, Martin wrote:
>Firstly, the good:
>
>The simplifications are a great 
>improvement.  The document is more accessible 
>and readable as a result.  The mechanism is fundamentally simpler.

glad you agree

>Content indirection has some interesting benefits.  It's a good idea.

it has always been in Conveyance, but might have been lost in the clutter.

>The limitation to _one_ location value has 
>undeniable benefits.  It also prevents the 
>conveyance of location value and reference together.

I believe we can have a location URI in the 
presence document. But you're right, we don't 
want one locationValue identifying a PIDF-LO and 
another locationValue indicating a location URI.

>draft-ietf-ecrit-rough-loc describes one use 
>case that this affects.  Brian (your other 
>co-author) should be able to apprise you of the 
>consequences this has to the NENA use cases.

ok...

>Jon's original response to this was to push the 
>composition problem to the PIDF-LO.  That could be done,

that is what's done, there is no 'could'. The 
text surrounding Figure 4 states this, and the 
example in 5.2 explains this is the example 
albeit showing two composed values from different sources.

>but it needs more specification.
>
>Reaching some sort of consensus on the solution 
>to this problem before this work is finished is important.

agreed

>Minor issues:
>
>The structure of the Geolocation-Error header 
>description is a little odd.  It seems that you 
>are trying to describe *classes* of error and 
>specific errors at the same time.  Separating 
>these concerns might make this easier to explain and understand.

the errors are in categories, of which, only one 
category has more than one error code(the 3XX category about permissions).

>of the "geolocation" option tag.

what would justify it?

the purpose of an option-tag is the ability to 
indicate support for an extension (whether 
optional or required), and to respond with 
whether or not an extension is supported or 
unsupported. This indication can be quite 
important for communicating SIP elements to 
understand support for (or not). I'm confused...

>Section 4.6 should reference draft-ietf-geopriv-deref-protocol.

how so?

It is already covered by the geopriv-filters 
reference. I do not believe anything more is necessary.

>indirection for a location URI.

I'll talk to my co-authors about this, as they 
are the ones limiting the number of examples  ;-)

>Just a few nits:
>
>Overall, the structure is greatly improved, but 
>when you see references in the form "in section 
>3 (below Figure 4)", you have a need for more sub-sections.

this might be a good point. I'll talk to my 
co-authors about breaking up section 3 into sub-sections (1 per Figure).

>   <http://www.rfc-editor.org/errata_search.php?rfc=4119>

this is quite possible. This was a bit cobbled together.

>"black phone" is a little jargon-y.

it's certainly known inside the voice/telephony world.

>More amusing was the idea that your 
>characterisation of a person was as a "non-IP device".

many readers misunderstand when talking about 
Alice, it's one of her electronic devices that 
SIP communicates with, not her directly.

Thanks for reading this so quickly and providing comments (seriously)

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 13 Jul 2010 14:51:16 +0800

Hi James,

I have similar sentiments to Martin, this is a greatly improved document.

> reference. I do not believe anything more is necessary.

I don't think that your response here answers the question.
Section 4.6 as is written now is saying that only a SIP, SIPS or PRES URI scheme can be carried in the Sip header.

" If a location URI is included in a SIP request, it MUST be a SIP-,
  SIPS- or PRES-URI.  When PRES: is used, as defined in [RFC3856], if
  the resulting resolution resolves to a SIP: or SIPS: URI, this
  section applies.  These schemes MUST be implemented according to
  this document.

   absoluteURI is not mandatory-to-implement, but allowed.

   See [ID-GEO-FILTERS] for more details on dereferencing location."

LOC Filters is all about subscribing for location information using SIP, and makes no reference to the HELD deref draft that Martin has requested reference to. Since we now have a working group item in Geopriv describing how an HTTP URI can be used as a location URI, it is being requested that the SIP conveyance document allow this in its prose, rather than excluding everything but a SIP-related method. I think that this is a reasonable request.

Cheers
James

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Jul 2010 08:09:39 +0800

Hi James,

Looks like we've got most of the big stuff out of the way.

> it has always been in Conveyance, but might have been lost in the

The 4483 reference was less explicit than your new Section 4.5.

James (W) and I have been discussing the implications of this, and there is one note that might need revisiting in light of this.

The mechanism for location by reference requires access to request bodies.  For intermediaries, this is OK, because of the new mechanism that you have developed.  However, the following text in Section 4.1 is probably now out of date:

   A SIP intermediary MAY add a Geolocation header field if one is not
   present - for example, when a user agent does not support the
   Geolocation mechanism but their outbound proxy does and knows their
   Location...
 
> >conveyance of location value and reference together.
...
> albeit showing two composed values from different sources.

The composition scenario is a valid one, but it still has the inherent limitations of location by value - you can't get updates.

The use case is basically: route based on the value, but provide a reference so that a PSAP can get better location information later; that is, updated or more accurate location.  That's not possible if the UAC does the dereference: the location information becomes fixed.

There are multiple ways to address this problem.  One idea - that may be a bad one, I don't know yet - is to add a reference to a Content-Location header in combination with the PIDF-LO value.  The other was to add PIDF extensions for indirection.

> category has more than one error code(the 3XX category about

I understand, my concern was that the description of the classes didn't make it sufficiently clear that each of the 1xx, 2xx and 4xx classes had a single error code in them.  By combining the definition of that single error code with the definition of the class that contained them, it makes it hard to distinguish what description applies to just the code, and what applies to the class as a whole.

> >The draft doesnâ€™t really justify the existence
> >of the "geolocation" option tag.
> 
> what would justify it?
> 

Why is indicating support for (or requirement of) this particular feature important?  If a UAC includes the header, is that not sufficient indication of support?  What reason might a UAC have for requiring that the UAS supports the feature? 

One justification for Supported might be that it is not possible to send 424 without some prior acknowledgement that the code is understood by the UAC.  That might be sufficient.

> are the ones limiting the number of examples  ;-)

Just a request - though it seemed like a fairly major omission.  In comparison (and this might just be my perspective) the composition example seems less significant.
 
> co-authors about breaking up section 3 into sub-sections (1 per

That would help a lot, I think.  Thanks.

> >The examples in Section 5 are not schema-valid
> 

They were almost perfect.  I've corrected the two examples and added them to the bottom of this email.  I've validated these and made sure that they don't have excessively long lines :)

> it's certainly known inside the voice/telephony world.

Sure.  That doesn't make it any less jargon-y though.

> SIP communicates with, not her directly.

That's an important distinction, but not one that I would have inferred from the text.  Perhaps you meant to say: "non-IP device (a personal device such as a black phone)".

> Thanks for reading this so quickly and providing comments (seriously)

Thanks for being responsive in return :)

> >--Martin

Example from 5.1:

  <presence
      xmlns="urn:ietf:params:xml:ns:pidf"
      xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
      xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
      xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
      xmlns:gml="http://www.opengis.net/gml"
      xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
      entity="pres:[email-masked]">
    <dm:device id="target123-1">
      <gp:geopriv>
        <gp:location-info>
          <gml:location>
            <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>32.86726 -97.16054</gml:pos>
            </gml:Point>
          </gml:location>
        </gp:location-info>
        <gp:usage-rules>
          <gbp:retransmission-allowed>false
          </gbp:retransmission-allowed>
          <gbp:retention-expiry>2010-07-30T20:00:00Z
          </gbp:retention-expiry>
        </gp:usage-rules>
        <gp:method>802.11</gp:method>
      </gp:geopriv>
      <dm:deviceID>mac:1234567890ab</dm:deviceID>
      <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp>
    </dm:device>
  </presence>

Example 5.2:

  <presence
      xmlns="urn:ietf:params:xml:ns:pidf"
      xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
      xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
      xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
      xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
      xmlns:gml="http://www.opengis.net/gml"
      entity="pres:[email-masked]">
    <dm:device id="target123-1">
      <gp:geopriv>
        <gp:location-info>
          <gml:location>
            <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
              <gml:pos>32.86726 -97.16054</gml:pos>
            </gml:Point>
          </gml:location>
        </gp:location-info>
        <gp:usage-rules>
          <gbp:retransmission-allowed>false
          </gbp:retransmission-allowed>
          <gbp:retention-expiry>2010-07-30T20:00:00Z
          </gbp:retention-expiry>
        </gp:usage-rules>
        <gp:method>802.11</gp:method>
      </gp:geopriv>
      <dm:deviceID>mac:1234567890ab</dm:deviceID>
      <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp>
    </dm:device>
    <dm:person id="target123">
      <gp:geopriv>
        <gp:location-info>
          <cl:civicAddress>
            <cl:country>US</cl:country>
            <cl:A1>Texas</cl:A1>
            <cl:A3>Colleyville</cl:A3>
            <cl:RD>Treemont</cl:RD>
            <cl:STS>Circle</cl:STS>
            <cl:HNO>3913</cl:HNO>
            <cl:FLR>1</cl:FLR>
            <cl:NAM>Haley's Place</cl:NAM>
            <cl:PC>76034</cl:PC>
          </cl:civicAddress>
        </gp:location-info>
        <gp:usage-rules>
          <gbp:retransmission-allowed>false
          </gbp:retransmission-allowed>
          <gbp:retention-expiry>2010-07-30T20:00:00Z
          </gbp:retention-expiry>
        </gp:usage-rules>
        <gp:method>triangulation</gp:method>
      </gp:geopriv>
      <dm:timestamp>2010-07-28T12:28:04Z</dm:timestamp>
    </dm:person>
  </presence>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 13 Jul 2010 21:01:03 -0500

>Looks like we've got most of the big stuff out of the way.

very cool to hear (err, read)!

>The 4483 reference was less explicit than your new Section 4.5.

fair point

>James (W) and I have been discussing the 
>implications of this, and there is one note that 
>might need revisiting in light of this.
>
>The mechanism for location by reference requires 
>access to request bodies.  For intermediaries, 
>this is OK, because of the new mechanism that 
>you have developed.  However, the following text 
>in Section 4.1 is probably now out of date:
>

This text is actually new, though the meaning was 
present in previous versions. What this means is 
that if a SIP request does not have a Geolocation 
header value, one *MAY* (i.e., more like _can_, 
but not all the way) be added by a SIP 
intermediary (i.e., proxy, b2bua, sbc, 
etc).  This last description is important -- as 
proxies cannot legally (per any RFC) 
add/modify/delete a MIME part (part), a b2bua or 
sbc can.  Many enterprise SIP systems are built 
around b2buas as their call servers - expressly 
for this capability (and for many other reasons 
too). This document isn't advocating or 
recommending intermediaries insert a Geolocation 
header value when one is not present in a 
received SIP request, but this doc makes it possible, that's all.

>The composition scenario is a valid one, but it 
>still has the inherent limitations of location 
>by value - you can't get updates.

correct, not without possessing a location URI of 
the Target. But, that's what the geopriv-filters 
ID is for, defining how to subscribe to a Target 
(or its compositor server) to ask for current location of the Target.

>The use case is basically: route based on the 
>value, but provide a reference so that a PSAP 
>can get better location information later; that 
>is, updated or more accurate location.  That's 
>not possible if the UAC does the dereference: 
>the location information becomes fixed.

"...UAC does the dereference"? Do you mean to 
understand that the UAC inserts location towards 
an intermediary, gets a rejection 424, with the 
intermediary's version of where the UAC is - 
possibly as a location URI, and has to 
dereference that URI to compose the now dual location MIME body?

This is not how we mean for you to have read the section.

We mean to have the intermediary do the 
dereference (if one is needed) and compose in the 
SIP 424 response a MIME body with both the 
server's version or both locations of the Target, 
and for that dual location single presence 
document to be copied into the next SIP request 
from that UAC (towards that same intermediary).

Also, we do a little dance around idea - in text 
- the concept of us not expecting the 
intermediary receiving a 911 or 112 style 
emergency call from ever returning a 424 
rejection. We say we expect, but can't say this 
normatively, that the intermediary will become a 
b2bua for that call setup and compose (or 
overwrite) the location in the SIP request and 
forward that towards a PSAP/emergency call center.

I think this is inconsistent with the phonebcp, which will need to be fixed.

Does this make sense?

>There are multiple ways to address this 
>problem.  One idea - that may be a bad one, I 
>don't know yet - is to add a reference to a 
>Content-Location header in combination with the 
>PIDF-LO value.  The other was to add PIDF extensions for indirection.

I don't know what a "Content-Location" header is, 
but given that Jon created the PIDF-LO, and was 
instrumental in this Conveyance rewrite, he's 
proposing the above be the solution.

>I understand, my concern was that the 
>description of the classes didn't make it 
>sufficiently clear that each of the 1xx, 2xx and 
>4xx classes had a single error code in them.

oh... yeah, I think I agree (even without looking 
back at it). That's been at the back of my mind 
since Jon whacked another section that I wrote in 
an early version of this -03. I was meaning to 
get back to that.  I'll make it clear that each 
are classes, where each x00 error code has a text 
string that's clearly understood (similar to 
what's there in the IANA section now). I'll make 
it clearer that how more error codes can be added to each category too.

>By combining the definition of that single error 
>code with the definition of the class that 
>contained them, it makes it hard to distinguish 
>what description applies to just the code, and 
>what applies to the class as a whole.
>
> > >The draft doesnÃ¢€™t really justify the existence
> > >of the "geolocaocation" option tag.
> >
> > what would justify it?
> >
>Why is indicating support for (or requirement 
>of) this particular feature important?  If a UAC 
>includes the header, is that not sufficient 
>indication of support?  What reason might a UAC 
>have for requiring that the UAS supports the feature?

any other SIP request where understanding that 
the location of the UAC is vitally important to 
properly process the request is another.

for example, 911 is one I believe.

But calling Pizza Hut's national URI, I might 
require that UAS to understand where I am in 
order to take my order, or reject my request.  A 
more likely scenario is for a roadside towing 
service that I don't have a prior relationship 
with. I would want to not call again to those 
that don't understand 'location', and only call those that do in the future.

>One justification for Supported might be that it 
>is not possible to send 424 without some prior 
>acknowledgement that the code is understood by 
>the UAC.  That might be sufficient.

hmm... sounds good to me. I'll add it. Thanks!

>Just a request - though it seemed like a fairly 
>major omission.  In comparison (and this might 
>just be my perspective) the composition example seems less significant.

less significant... I'm not sure how to take that 
(as there is more than one way it might go).

Two of us felt it important that there be an 
example of a composed single MIME body for some 
readers.  Are you suggesting, that you feel the 
composed dual value body is of less value than one value and one reference?

>They were almost perfect.  I've corrected the 
>two examples and added them to the bottom of 
>this email.  I've validated these and made sure 
>that they don't have excessively long lines :)

a BIG thank you for this!!

>Sure.  That doesn't make it any less jargon-y though.

I guess it's also pre-Blackberry, and we don't 
want anyone getting mad... I'll work on it.

>That's an important distinction, but not one 
>that I would have inferred from the 
>text.  Perhaps you meant to say: "non-IP device 
>(a personal device such as a black phone)".

that would work. I'll make the change

>Thanks for being responsive in return :)

Thanks again

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 14 Jul 2010 15:08:24 +0800

Snipping stuff that I think we've resolved.

> received SIP request, but this doc makes it possible, that's all.

That's a good explanation, but I didn't get this from the text.  I think that perhaps all this needs is a little clarification: "A SIP intermediary *that acts as a B2BUA* MAY add a...".  I think that in this case, you would have to explicitly exclude "proxy" from the definition.

> (or its compositor server) to ask for current location of the Target.

Filters isn't really the definitive reference for that.  You might actually consider RFC 3856 to be the definitive reference (maybe referencing RFC 4079).
 
> dereference that URI to compose the now dual location MIME body?

No - I'm saying that my major issue is driven by that use case.  There is (currently) no way for any entity (UAC or intermediary) to insert both location by value and location by reference.  There is a need for that capability.

> from that UAC (towards that same intermediary).

Elegant as it is, this just doesn't work.  The UAS (PSAP, LR, etc...) needs to be the entity that does the dereference.  They need to do this because they know how (and when) to make this request so that they get the information they need.  If the intermediary does the dereference, then location information is set in stone from that point onward.
 
> forward that towards a PSAP/emergency call center.

BTW, I liked that dance.  It's another win for pragmatism over dogmatism.

> I think this is inconsistent with the phonebcp, which will need to be

I'm still reading phone-bcp against previous versions.  I'll await a phone-bcp update and we can discuss how the two interact then.

> proposing the above be the solution.

As I stated, I don't see that there is a solution yet.

> it clearer that how more error codes can be added to each category too.

Great.  But please tell me that you aren't fixing the error text to the error code.

> composed dual value body is of less value than one value and one

That's based on what I know we need - I don't have a strong need for composition right now.  Of course, everyone is allowed to have their own perspective on this sort of thing.

Cheers,
Martin

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Jul 2010 13:08:32 -0400

[snip]

<JFP> I see your point, but I think the difficulty is deeper still than this. The whole use case for an intermediary providing different (or supplementary) location information above and beyond the location provided by the UAC is based on the intermediary inspecting, and disliking, the location present in the request. If that location is constantly changing, what would it mean for the intermediary to dislike it? Maybe it likes it one minute and not the next? Would it -ever- be safe for a picky intermediary to allow a reference to pass it, given that it couldn't control what location the LR would ultimately get from it? Moreover, what if the creator of the reference authorizes the end recipient (the PSAP) but not the intermediary that wants to judge location information? I think we'd need to look further into the motivations here to understand the underlying requirement.

Practically speaking, however, there are a number of potential work-arounds to enable this semantic - I don't necessarily think that once the intermediary performs the dereference, then the location information must be set in stone. If you seriously want to retain the dynamism of location information, it could become the responsibility of the compositor to deliver a similarly dynamic reference, and every time someone dereferences the composed object, the compositor creates a new PIDF-LO document based on freshly dereferencing any dynamic components of the location information. Another possibility would be to specify external references in PIDF, so we could compose location information from dynamic sources by reference in the PIDF object, rather than by value. One composed object could even have a mix of by-value and by-reference location information in that case. The important thing is that we solve this down in the PIDF level, within the parameters of RFC4479, rather than trying to cobble together some relationship between devices, services and users in the Geolocation header.

Anyway, none of this is to suggest that this is adequately specified in the current draft, or something. We'd need to have a more lengthy discussion about some of the issues above before figuring out what we'd add, though.

Jon Peterson
NeuStar, Inc.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 15 Jul 2010 09:33:32 +0800

Hi Jon,

There’s a number of issues here.  I think that we need to disentangle them.  The role of the intermediary in this dealing with this problem is a secondary concern.

There are two primary reasons for having both value and reference: authorization and dynamism.

Dynamism is the easiest one to pin down.  It's obviously very important to the emergency scenario - the ability of a PSAP to acquire updated location information in a timely fashion is central to many of their use cases.

draft-ecrit-rough-loc describes a scenario where the UAC is less authorized than the UAS; intermediaries are authorized differently.  In the canonical example, the UAS gets a rubbish location value and a location reference that they can't use.  The rubbish location is enough to get them to a PSAP.  The PSAP uses the reference because they are authorized.

In either case, it's possible to leave the intermediary out of consideration and concentrate on the information that the UAC provides.  The great thing with the solution that you've proposed is that this is ultimately what happens in any case.  Leaving the b2bua case aside, the UAC is ultimately responsible for what Geolocation is placed in the request.

The interactions with the intermediary add complexity to the scenario, including some privacy model problems, primarily with retransmission.  I'd like to solve the easier problem first.

--Martin

From: Peterson, Jon [mailto:[email-masked]] 
Sent: Thursday, 15 July 2010 3:09 AM
To: Thomson, Martin; James M. Polk; [email-masked]
Subject: Re: [sipcore] location-conveyance-03 just submitted

[snip]

<JFP> I see your point, but I think the difficulty is deeper still than this. The whole use case for an intermediary providing different (or supplementary) location information above and beyond the location provided by the UAC is based on the intermediary inspecting, and disliking, the location present in the request. If that location is constantly changing, what would it mean for the intermediary to dislike it? Maybe it likes it one minute and not the next? Would it –ever- be safe for a picky intermediary to allow a reference to pass it, given that it couldn’t control what location the LR would ultimately get from it? Moreover, what if the creator of the reference authorizes the end recipient (the PSAP) but not the intermediary that wants to judge location information? I think we’d need to look further into the motivations here to understand the underlying requirement.

Practically speaking, however, there are a number of potential work-arounds to enable this semantic – I don’t necessarily think that once the intermediary performs the dereference, then the location information must be set in stone. If you seriously want to retain the dynamism of location information, it could become the responsibility of the compositor to deliver a similarly dynamic reference, and every time someone dereferences the composed object, the compositor creates a new PIDF-LO document based on freshly dereferencing any dynamic components of the location information. Another possibility would be to specify external references in PIDF, so we could compose location information from dynamic sources by reference in the PIDF object, rather than by value. One composed object could even have a mix of by-value and by-reference location information in that case. The important thing is that we solve this down in the PIDF level, within the parameters of RFC4479, rather than trying to cobble together some relationship between devices, services and users in the Geolocation header.

Anyway, none of this is to suggest that this is adequately specified in the current draft, or something. We’d need to have a more lengthy discussion about some of the issues above before figuring out what we’d add, though.

Jon Peterson
NeuStar, Inc.

---

From: Francois Menard <[email-masked]>
Date: Wed, 14 Jul 2010 21:47:59 -0400

I've challenged the Canadian PSAPs to put their NG-911 use cases in writing.

This is being met with fierce resistance at this time.

Has anyone made an IETF draft of NG-9-1-1 PSAP use cases ?

I'm thinking of adding digitally-signed-by-the-PSAP ALI data in ENUM and allowing PSAP access to Carrier ENUM.

Why allowing PSAPs to fetch MSAG-dispatcheable from Carrier ENUM records be a good idea ?

Regards,

F.

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 15 Jul 2010 15:56:20 -0700

All:
My understanding of what this conveyance-03 draft now allows for is support of location in terms of:

LbyV if the geolocation header contains a cid URI which points to a PIDF-LO in the body
Or
LbyR if the geolocation header contains a location URI 
Or 
Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also includes an "associated" Location URI within.  This is what I assume is the composite case.

If this is how it's intended to work, how then would routing be accomplished if the intention was to route on location URI, not LbyV?

The geolocation header parameter value of "routing-allowed" can only be yes or no pointing to the whole PIDF-LO:

[from -03]
   The practical implication is that when the "routing-allowed"
   parameter is set to "no", if a cid:url is present in the SIP
   request, intermediaries MUST NOT view the location (because it is
   not for intermediaries to view), and if a location URI is present,
   intermediaries MUST NOT dereference it.  UAs are allowed to view
   location in the SIP request even when the "routing-allowed"
   parameter is set to "no".  An LR MUST by default consider the
   "routing-allowed" header parameter as set to "no", with no
   exceptions, unless the header field value is set to "yes".

It seems to me that a better way is to allow geolocation URIs in numbers of 0, 1, or 2, so that you could elevate the Location URI up to the geolocation header and avoid all the difficulties of not knowing what location form was routable, plus escape the overhead of embedding it into an otherwise empty PIDF-LO when using LbyR exclusively.

Regards,

-roger marshall.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Wednesday, July 14, 2010 6:34 PM
To: Peterson, Jon; James M. Polk; [email-masked]
Subject: Re: [sipcore] location-conveyance-03 just submitted

Hi Jon,

--Martin

[snip]

Jon Peterson
NeuStar, Inc.

CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 16 Jul 2010 07:39:21 +0800

I support Roger's proposal.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Roger Marshall
> Sent: Friday, 16 July 2010 8:56 AM
> To: Thomson, Martin; Peterson, Jon; James M. Polk; [email-masked]
> Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also
> includes an "associated" Location URI within.  This is what I assume is
> the composite case.
> 
> If this is how it's intended to work, how then would routing be
> accomplished if the intention was to route on location URI, not LbyV?
> 
> It seems to me that a better way is to allow geolocation URIs in numbers
> of 0, 1, or 2, so that you could elevate the Location URI up to the
> geolocation header and avoid all the difficulties of not knowing what
> location form was routable, plus escape the overhead of embedding it into
> an otherwise empty PIDF-LO when using LbyR exclusively.
> 
> Regards,
> 
> -roger marshall.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 16 Jul 2010 02:54:26 -0400

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.

On 7/15/10 3:56 PM, "Roger Marshall" <[email-masked]> wrote:

All:

[from -03]

Regards,

-roger marshall.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Wednesday, July 14, 2010 6:34 PM
To: Peterson, Jon; James M. Polk; [email-masked]
Subject: Re: [sipcore] location-conveyance-03 just submitted

Hi Jon,

There's a number of issues here.  I think that we need to disentangle them.  The role of the intermediary in this dealing with this problem is a secondary concern.

--Martin

[snip]

Jon Peterson
NeuStar, Inc.

---

From: Francois Menard <[email-masked]>
Date: Fri, 16 Jul 2010 08:43:54 -0400

I've been monitoring this thread and I think too much effort is being made to consider 'location negotiation' inside SIP.

Heck we're not even there with SDP for codec negotiation after 15 years of having VoIP in production.

With SDP, the end-point chooses ultimately what to send over RTP.  It receives advice at the SIP level, but insofar as possibly being rogue, an end-point being told to send-in G.729, will possibly send-out G.711 without saying so.

Now, to build on this analogy, if an end-point chooses to package into its SIP invite, several LbyV and an LbyR to accomodate the requirement that the SIP B2BUA behind the proxy of a PSAP gets an LbyR, to perform verification that the LbyV is really what its supposed to be, then such interpretation of the LbyR is done by the far-end B2BUA at the PSAP.  I am not convinced that the job of the proxy at the PSAP will be to replace an LbyR by a LbyV and that the B2BUA at the PSAP will blindly trust what's coming from its first hop proxy over what's coming from the far-end SIP UA at the customer premise.

The requirements for this chain of trust, i.e.

1) end-user SIP UA trusting acquisition of location by say DHCPLOC
2) first hop VoIP service provider trusting PROXY that the SIP UA is conveying the proper location (if its LbyR, then it can't authenticate), is proper
3) last hop B2BUA at the PSAP, if it sees an LbyV added by its first hop proxy, did this LbyV replaced the far-end LbyV learned by the end-user SIP UA from DHCPLOC ?

This does not appear to be super well documented at this time.

This is why I am asking that PSAPs get together in Canada and start ironing out their NG-911 requirements.

And so far, its being met with some resistance.

But we're getting going, making tis new CRTC CISC working group Task on NG-911 PSAP requirements.

Has anyone else documented what we'd like to see done or are we trying to accommodate all possible requirements ?

F.

On 2010-07-16, at 2:54 AM, Peterson, Jon wrote:

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 19 Jul 2010 10:25:37 +0800

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:[email-masked] SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:[email-masked]>
   From: Alice <sips:[email-masked]>;tag=9fxced76sl
   Call-ID: [email-masked]
   Geolocation: <cid:[email-masked]>
     ;routing-allowed=no
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:[email-masked]>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1
   Content-Type: application/sdp

   ...SDP goes here

   --boundary1
   Content-Type: application/pidf+xml
   Content-ID: <[email-masked]>
   Content-Location: pres:[email-masked]?location/XJhbXM6eG1sOm5zOnBpZ

   <?xml version="1.0"?>
   ...PIDF-LO document
   --boundary1--

--Martin

---- Original Message ----
From: Peterson, Jon [mailto:[email-masked]] 
Sent: Friday, 16 July 2010 4:54 PM
To: Roger Marshall; Thomson, Martin; James M. Polk; [email-masked]
Subject: Re: [sipcore] location-conveyance-03 just submitted

Jon Peterson
NeuStar, Inc.

…

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Jul 2010 17:29:19 -0400

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" <[email-masked]> 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.

   --boundary1

   ...SDP goes here

   --boundary1

   <?xml version="1.0"?>
   ...PIDF-LO document
   --boundary1--

--Martin

---- Original Message ----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Friday, 16 July 2010 4:54 PM
To: Roger Marshall; Thomson, Martin; James M. Polk; [email-masked]
Subject: Re: [sipcore] location-conveyance-03 just submitted

Jon Peterson
NeuStar, Inc.

...

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 19 Jul 2010 17:44:06 -0400

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.
>
>
> 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.
>
> 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.
>
> 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.
>
> …
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Jul 2010 19:19:47 -0400

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" <[email-masked]> 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.

 Jon Peterson
 NeuStar, Inc.

Hi Jon,

    --boundary1

    ...SDP goes here

    --boundary1

    <?xml version="1.0"?>
    ...PIDF-LO document
    --boundary1--

 --Martin

 ---- Original Message ----
 From: Peterson, Jon [mailto:[email-masked]]
 Sent: Friday, 16 July 2010 4:54 PM
 To: Roger Marshall; Thomson, Martin; James M. Polk; [email-masked]
 Subject: Re: [sipcore] location-conveyance-03 just submitted

 Jon Peterson
 NeuStar, Inc.

 ...

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 19 Jul 2010 20:04:15 -0400

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.
>
>
> 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).
>
> 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.
>
>
>
>  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.
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:23:07 -0500

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.
>
>
>
>>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" 
>><<[email-masked]>[email-masked]> 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 
>>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 
>>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.
>>
>>    INVITE sips:<[email-masked]>[email-masked] SIP/2.0
>>    To: Bob <sips:<[email-masked]>[email-masked]>
>>    From: Alice 
>> <sips:<[email-masked]>[email-masked]>;tag=9fxced76sl
>>    Call-ID: 
>> <[email-masked]>[email-masked]
>>    Geolocation: 
>> <cid:<[email-masked]>[email-masked]>
>>      ;routing-allowed=no
>>    Supported: geolocation
>>    Contact: <sips:<[email-masked]>[email-masked]>
>>    Content-ID: 
>> <<[email-masked]>[email-masked]>
>>    Content-Location: 
>> pres:<[email-masked]>[email-masked]?location/XJhbXM6eG1sOm5zOnBpZ
>>
>>    <?xml version="1.0"?>
>>    ...PIDF-LO document
>>    --boundary1--
>>
>>
>>--Martin
>>
>>From: Peterson, Jon 
>>[<mailto:[email-masked]>mailto:[email-masked]]
>>To: Roger Marshall; Thomson, Martin; James M. 
>>Polk; <[email-masked]>[email-masked]
>>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 
>>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.
>>
>>…
>>
>><mailto:[email-masked]>[email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:23:07 -0500

Richard

James

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:32:09 -0500

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:
>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 
>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.
>
>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
>
>
>
>
>>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" 
>><<[email-masked]>[email-masked]> wrote:
>>
>>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 
>>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.
>>
>>
>>
>> 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.
>>
>> (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 
>> 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 
>> 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.
>>
>>
>>  At some point, it might be necessary to 
>> swallow any discomfort and recognize that the 
>>  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 
>>  The alternative is to imagine a single 
>> logical resource that represents the location 
>> of the Target.  A location by value is 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 
>>  Now this might be sheer sophistry, but it 
>> might offer a way out.  The composition problems are left out of SIP.
>>
>> how we understand those different locations, 
>> or it is PIDF’s job.  Traditionally, PIDF’s 
>> thinks I am available but my desktop thinks 
>> I’m offline. The presence data model moreover 
>> 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.
>>
>>  …
>>
>>
>>
>>
>><[email-masked]>[email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 19 Jul 2010 21:59:51 -0400

If the answer is "you know what, just throw all these unconnected bodies over the wall at the LR, it will understand what to do," then can you explain to me what this Geolocation header does for us again? We can already do that without any new headers.

As I've been reading through this thread, I've been mentally substituting "SDP" for "location information," and indeed, while we could just say "throw three SDP bodies  - two of which were added by intermediaries - in the same request at the UAS, and it'll have some application-specific way of understanding how to reconcile them," I think that's a bad plan for a number of reasons. Intermediaries who refuse to allow the MIME portion of a SIP request created by the UAC to pass without modification should have the responsibility to make the request comprehensible to the UAS (and they should have to get the buy-in of the UAC in some fashion as well).

Fortunately, I at least believe that intermediaries who want to add LI to requests that already contain previously added LI will be far more rare than intermediaries who want to tinker with SDP in transit. In most normal architecture, I imagine that either the UAC will supply location or an intermediary will - the case where both happens means, necessarily, that an intermediary doesn't like what the UAC has put in, but the intermediary doesn't dislike it enough to enforce its removal from the request. Honestly, how can that be a common case? Why would an intermediary even want to impose that complexity of interpretation on the UAS?

Jon Peterson
NeuStar, Inc.

On 7/19/10 5:04 PM, "Richard L. Barnes" <[email-masked]> 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.

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

 Jon Peterson
 NeuStar, Inc.

  Jon Peterson
  NeuStar, Inc.

Hi Jon,

     --boundary1

     ...SDP goes here

     --boundary1

     <?xml version="1.0"?>
     ...PIDF-LO document
     --boundary1--

  --Martin

  ---- Original Message ----
  From: Peterson, Jon [mailto:[email-masked]]
  Sent: Friday, 16 July 2010 4:54 PM
  To: Roger Marshall; Thomson, Martin; James M. Polk; [email-masked]
  Subject: Re: [sipcore] location-conveyance-03 just submitted

  Jon Peterson
  NeuStar, Inc.

  ...

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Jul 2010 11:24:13 +0800

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:[email-masked]]
Sent: Tuesday, 20 July 2010 10:04 AM
To: Peterson, Jon
Cc: Roger Marshall; [email-masked]; Thomson, Martin
Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted)

--Richard

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.

 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.

Hi Jon,

    --boundary1

    ...SDP goes here

    --boundary1

    <?xml version="1.0"?>
    ...PIDF-LO document
    --boundary1--

 --Martin

 ---- Original Message ----
 From: Peterson, Jon [mailto:[email-masked]]
 Sent: Friday, 16 July 2010 4:54 PM
 To: Roger Marshall; Thomson, Martin; James M. Polk; [email-masked]
 Subject: Re: [sipcore] location-conveyance-03 just submitted

 Jon Peterson
 NeuStar, Inc.

 …

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Jul 2010 14:39:11 +0800

Resolving the semantics of the header is the biggest problem.

My original view was that the intent was to convey the message that the referenced location information is for the entity identified in the From header.  The idea was the SIP request forged a link between the identity and the location in the PIDF-LO document.

I was later convinced that this sort of strong semantic was unnecessary.  The idea of “relevance” is a better way of approaching the problem.

Location can be conveyed in SIP already, so if the header is to have any value, it needs a clearly defined semantic.  How about:

The Geolocation header identifies a PIDF document by value or reference.  A Geolocation header indicates that a) this particular PIDF document contains location information and b) that this location information in particular may be relevant to the processing of the SIP request.

This is intentionally soft, but (I believe) not too vague.  Yes, you can make the leap from this to conclude that the Target and the request originator are one and the same.  A shorter jump would be to say that these entities are at the same location.  These stronger semantics are unnecessary… or at least hard to prove.

--

The reason that I proposed Content-Location is because it does away with the idea that there are multiple sources.  Instead, it identifies a single authority and resource.  That authority might compose multiple sources, but that becomes opaque.  If I think of a single HTTP resource, the idea that the resource might have different representations doesn’t cause (much) consternation.

The bigger problem arises when you allow free reign to different authorities which each have their different views.  Allow the inclusion of static and dynamic, but make it clear that both static and dynamic have to be the same thing/resource.

Once a single authority is isolated, then all you have to worry about is the contents of the PIDF.  We have the means to deal with that with 4479 (in general) and 5491 (for location specifically).

And the UAC makes the decision about which authority to nominate.

--Martin

p.s. Note that the definition wording above would preclude the use of a geo: URI.  I’m open to making the statement fuzzier, if there is consensus that other location formats are acceptable or desirable.

From: Peterson, Jon [mailto:[email-masked]]
Sent: Tuesday, 20 July 2010 7:29 AM
To: Thomson, Martin; Roger Marshall; James M. Polk; [email-masked]
Subject: Re: composition or just indirection (was: location-conveyance-03 just submitted)

Jon Peterson
NeuStar, Inc.

…

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 20 Jul 2010 12:23:33 +0200

Still trying to catch up with the mail thread but a few basic observations: 

1) There is the 'entity' attribute in the <presence> element that points to the Target. 

2) There is RFC 5491 http://datatracker.ietf.org/doc/rfc5491/ that describes how different location chunks (including "compound location") are interpreted. It also describes the meaning of different location objects in a PIDF-LO. 

3) We know that we want to transmit multiple location chunks, and multiple location objects of the same Target. We do not seem to have use cases for transmitting location of >>different<< Targets in the same SIP message. 

So, this should allow us to carry one of multiple MIME bodies with PIDF-LOs in a SIP message (referring to the same Target) in a single SIP message. 

The following items are left for discussions, I believe: 

- How to encode the LbyR (in addition to the LbyV)
- Procedures for how an intermediary attaches a reference to a PIDF-LO 
- Whether there needs to be a relationship between the 'entity' attribute in the <presence> element and the From header of a SIP message.

I am less interested in the used-for-routing optimizations etc. 

Did I correctly capture the challenge? 

Ciao
Hannes

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 13:00:08 +0200

James,

These are questions for clarification at this stage, rather than comments.

The ABNF for the Geolocation header field allows multiple locationValues and multiple routing-params, in any order. The text below seems to limit it to 0 or 1 locationValue and 0 or 1 routing-param, and furthermore it limits it so that the routing-param must be last. It seems this could be expressed much more precisely, and still quite easily, in the ABNF. Of have I misunderstood something?

Although the text "The Geolocation header field has zero or one locationValue, but 
   MUST NOT contain more than one locationValue."
limits the header field to having a maximum of one locationValue, text further down "another 
   instance of the Geolocation header"
suggests that there can be multiple instances of the header field and hence multiple locationValues. So a request can contain multiple locationValues, but not in the same header field instance. Is this really what is intended?

Unrelated to the above, concerning the text:
"Other URI schemas used in the location URI MUST be reviewed against 
   the RFC 3693 [RFC3693] criteria for a Using Protocol"
Who must review? The protocol implementer? How is this testable?

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: 13 July 2010 00:55
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2010 08:51:35 -0400

Thomson, Martin wrote:
>  How about:
> 
> The Geolocation header identifies a PIDF document by value or 
> reference.  A Geolocation header indicates that a) this particular PIDF 
> document contains location information and b) that this location 
> information in particular may be relevant to the processing of the SIP 
> request.
> 
> This is intentionally soft, but (I believe) not too vague. 

IMO this is *too* vague.

For instance, I might want request that a call be routed *to* the phone 
closest to some geolocation. That location is also relevant to the 
processing of the request, but in an entirely different way.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:23:07 -0500

Richard

James

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 13:00:08 +0200

James,

John

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Jul 2010 07:50:48 +0800

> From: Paul Kyzivat [mailto:[email-masked]]:
> Thomson, Martin wrote:
> > information in particular may be relevant to the processing of the
> > SIP request.
> 
> IMO this is *too* vague.
> 

Damn.  You would have to point out my big blind spot.  I've been concentrating on the routing-based-on-caller-location use case too long.

If we also consider that the location needs to be attributed to a particular entity, you can either add syntax that attempts to identify the entity that you are talking about (a "from" or "to" parameter might do this), or you can make the entity constant.  In the interest of simplicity, the latter seems more fashionable:

"
The Geolocation header identifies a source of location information.  This might be a PIDF-LO document that is identified by value or reference, or a geo: URI that includes location information directly.

A Geolocation header indicates that a) that this location information is somehow applicable to the entity that initiated the request and b) that this location information might be relevant to the processing of the SIP request.
"

This is almost the "bold" interpretation that says that this Target’s location should be considered the source of the request.  It does not imply that the Target and source are the same identity.  Nor does it expressly state that the source is actually located anywhere in particular, though we're walking a fairly fine line there.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Jul 2010 08:07:32 +0800

Hi Hannes,

Inline...

> 2) There is RFC 5491 http://datatracker.ietf.org/doc/rfc5491/ that
> describes how different location chunks (including "compound location")
> are interpreted. It also describes the meaning of different location
> objects in a PIDF-LO.

I'd like to rely on 5491.  But we need to get to the point where a recipient only receives a single document.  That's the snarl we're trying to tease out.
 
> 3) We know that we want to transmit multiple location chunks, and
> multiple location objects of the same Target. We do not seem to have
> use cases for transmitting location of >>different<< Targets in the
> same SIP message.

I don't think that this is entirely correct.  Yes, it's trivial to convey multiple pieces, but we're looking for a way to have a single PIDF but reconcile that with by-reference conveyance.

> So, this should allow us to carry one of multiple MIME bodies with
> PIDF-LOs in a SIP message (referring to the same Target) in a single
> SIP message.

> - How to encode the LbyR (in addition to the LbyV)

How that cat is skinned depends on the logical model that we agree upon.  It's easy enough to just throw in another body (or header even), but that doesn't address the concern that a recipient/UAS might be unable to make sense of the information that it receives.

> - Procedures for how an intermediary attaches a reference to a PIDF-LO

I think that this has already been solved.  The intermediary sends a 424 with the reference in it, the UAC attaches the reference if it agrees.  (In an emergency, there are no such niceties: the intermediary steps into a B2BUA role.)  

An intermediary has to comply with any constraints we place on the header: one value or one header, one value and one reference, or whatever conclusion we come to.

> - Whether there needs to be a relationship between the 'entity'
> attribute in the <presence> element and the From header of a SIP
> message.

That comes down to header semantics.  Equality of the entity attribute and From header is both unnecessary and difficult to achieve.  A weaker relationship might be necessary, see my response to Paul.

It's a damned shame that we don't have a good understanding of the semantics we want from the header.  How many years have we been working on this?

> I am less interested in the used-for-routing optimizations etc.

Agreed.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jul 2010 21:33:16 -0400

> Damn.  You would have to point out my big blind spot.  I've been concentrating on the routing-based-on-caller-location use case too long.

You're welcome :-)

> This is almost the "bold" interpretation that says that this Target’s location should be considered the source of the request.  It does not imply that the Target and source are the same identity.…

This sounds plausible to me, but I have not been following this stuff 
closely and so am not familiar with all the sensitivities.

	Thanks,
	Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 20 Jul 2010 14:39:11 +0800

--

--Martin

Jon Peterson
NeuStar, Inc.

…

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Jul 2010 06:00:08 -0500

WARNING: contains banned part

Subject: RE: [sipcore] location-conveyance-03 just submitted
From: "Elwell, John" <[email-masked]>
To: "James Polk (jmpolk)" <[email-masked]>, <[email-masked]>
Date: Tue, 20 Jul 2010 06:00:08 -0500

James,

John

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 19 Jul 2010 20:23:07 -0500

Richard

James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 05:10:55 -0500

>have for requiring that the UAS supports the feature?

if I hasn't answer this point, here are a couple of reasons for this
- a UAS can be responding to an OPTIONS query, 
indicating it supports geolocation too.
- a UAC could include this option tag in a 
OPTIONS request, even though it included no geolocation header value.
- a UAS could need this to indicate it doesn't 
support an extension in SIP. Sending this option 
tag in an Unsupported header value is important in this case

>the UAC.  That might be sufficient.

I don't believe an Unsupported header value can 
contain an option tag it didn't support that 
wasn't in the SIP request it is responding to.

James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 05:26:02 -0500

At 02:08 AM 7/14/2010, Thomson, Martin wrote:
>No - I'm saying that my major issue is driven by that use 
>case.  There is (currently) no way for any entity (UAC or 
>intermediary) to insert both location by value and location by 
>reference.  There is a need for that capability.
>
>Elegant as it is, this just doesn't work.  The UAS (PSAP, LR, 
>etc...) needs to be the entity that does the dereference.  They need 
>to do this because they know how (and when) to make this request so 
>that they get the information they need.  If the intermediary does 
>the dereference, then location information is set in stone from that 
>point onward.

specifically to this last part, if the intermediary does the 
composition - it in fact does know how to do this, but does not do it 
exactly when you may want, and you're right, this is then "in stone" 
without a subscription back to the UAC (geo-filters style) for any 
updates it needs.  I'm not sure you're gonna be able to get away from 
this whenever a PSAP gets a value BTW. It can never be 100% certain 
your getting a reachable location URI for that Target, and the PSAP 
is in the best position to do this "get/update" function.

James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 05:37:38 -0500

At 08:33 PM 7/14/2010, Thomson, Martin wrote:
>Hi Jon,
>
>Thereâ€™s a number of issues here.  I think that 
>we need to disentangle them.  The role of the 
>intermediary in this dealing with this problem is a secondary concern.
>
>There are two primary reasons for having both 
>value and reference: authorization and dynamism.
>
>Dynamism is the easiest one to pin down.  It's 
>obviously very important to the emergency 
>scenario - the ability of a PSAP to acquire 
>updated location information in a timely fashion 
>is central to many of their use cases.

Martin - how long are you expecting this initial 
INVITE to go from the UAC to the PSAP?

You're giving the impression that a second or two 
matters or the UAC will be in a completely 
different location, meaning the wrong PSAP will be contacted.

Is that really probable here?

If it's an infrequent case of a corner-case 
(calling 911/112 in the first place)...

>draft-ecrit-rough-loc describes a scenario where 
>the UAC is less authorized than the UAS; 
>intermediaries are authorized differently.  In 
>the canonical example, the UAS gets a rubbish 
>location value and a location reference that 
>they can't use.  The rubbish location is enough 
>to get them to a PSAP.  The PSAP uses the 
>reference because they are authorized.
>
>In either case, it's possible to leave the 
>intermediary out of consideration and 
>concentrate on the information that the UAC provides.

but what about environments (or networks) that 
don't trust the UE (or UAC) at all. I'd argue 
that's much more probable -- because that's how 3GPP treats their phones.

>The great thing with the solution that you've 
>proposed is that this is ultimately what happens 
>in any case.  Leaving the b2bua case aside, the 
>UAC is ultimately responsible for what Geolocation is placed in the request.

not true for 3GPP, which in theory, will be a 
fair number of endpoints (as in more than 50% of many countries, right?

How will what you're describing fit their network architecture?

>The interactions with the intermediary add 
>complexity to the scenario, including some 
>privacy model problems, primarily with retransmission.

meaning UDP vs TCP?

James

>  I'd like to solve the easier problem first.
>
>--Martin
>
>
>Elegant as it is, this just doesn't work. Â The 
>UAS (PSAP, LR, etc...) needs to be the entity 
>that does the dereference. Â They need to do 
>this because they know how (and when) to make 
>this request so that they get the information 
>they need. Â If the intermediary does the 
>dereference, then location information is set in stone from that point onward.
>
><JFP> I see your point, but I think the 
>difficulty is deeper still than this. The whole 
>use case for an intermediary providing different 
>(or supplementary) location information above 
>and beyond the location provided by the UAC is 
>based on the intermediary inspecting, and 
>disliking, the location present in the request. 
>If that location is constantly changing, what 
>would it mean for the intermediary to dislike 
>it? Maybe it likes it one minute and not the 
>next? Would it ever- be safe for a picky 
>inttermediary to allow a reference to pass it, 
>given that it couldnâ€™t control what location 
>the LR would ultimately get from it? Moreover, 
>what if the creator of the reference authorizes 
>the end recipient (the PSAP) but not the 
>intermediary that wants to judge location 
>information? I think weâ€™d need to look further 
>into the motivations here to understand the underlying requirement.
>
>Practically speaking, however, there are a 
>number of potential work-arounds to enable this 
>semantic  I donâ€™t necessarilyy think that 
>once the intermediary performs the dereference, 
>then the location information must be set in 
>stone. If you seriously want to retain the 
>dynamism of location information, it could 
>become the responsibility of the compositor to 
>deliver a similarly dynamic reference, and every 
>time someone dereferences the composed object, 
>the compositor creates a new PIDF-LO document 
>based on freshly dereferencing any dynamic 
>components of the location information. Another 
>possibility would be to specify external 
>references in PIDF, so we could compose location 
>information from dynamic sources by reference in 
>the PIDF object, rather than by value. One 
>composed object could even have a mix of 
>by-value and by-reference location information 
>in that case. The important thing is that we 
>solve this down in the PIDF level, within the 
>parameters of RFC4479, rather than trying to 
>cobble together some relationship between 
>devices, services and users in the Geolocation header.
>
>Anyway, none of this is to suggest that this is 
>adequately specified in the current draft, or 
>something. Weâ€™d need to have a more lengthy 
>discussion about some of the issues above before 
>figuring out what weâ€™d add, though.
>
>Jon Peterson
>NeuStar, Inc.

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 05:46:16 -0500

At 05:56 PM 7/15/2010, Roger Marshall wrote:
>All:
>My understanding of what this conveyance-03 
>draft now allows for is support of location in terms of:
>
>LbyV if the geolocation header contains a cid 
>URI which points to a PIDF-LO in the body
>Or
>Both LbyV & LbyR _only_ if the PIDF-LO that the 
>cid URI points to also includes an "associated" 
>Location URI within.  This is what I assume is the composite case.

you can also have a composed value from two or 
more entities proposing they know where the Target is.

>If this is how it's intended to work, how then 
>would routing be accomplished if the intention 
>was to route on location URI, not LbyV?

The intermediary would dereference the location 
URI and receive a PIDF-LO to route the original 
SIP request upon. The "routing-allowed" parameter 
would need to be set to "yes" or the intermediary 
would return a 424 with a Geolocation-Error 
header value 302 "Permission to Route based on 
Location Information". The UAC would then choose 
whether or not to give permission (in a subsequent request).

>The geolocation header parameter value of 
>"routing-allowed" can only be yes or no pointing to the whole PIDF-LO:
>
>[from -03]
>It seems to me that a better way is to allow 
>geolocation URIs in numbers of 0, 1, or 2, so 
>that you could elevate the Location URI up to 
>the geolocation header and avoid all the 
>difficulties of not knowing what location form 
>was routable, plus escape the overhead of 
>embedding it into an otherwise empty PIDF-LO when using LbyR exclusively.

if there is no cid-URL (meaning no PIDF-LO), the 
one locationValue can be a location URI. This 
also solves what your concerns are above, don't they?

James

>[mailto:[email-masked]] On Behalf Of Thomson, Martin
>concentrate on the information that the UAC 
>provides.  The great thing with the solution 
>that you've proposed is that this is ultimately 
>what happens in any case.  Leaving the b2bua 
>case aside, the UAC is ultimately responsible 
>for what Geolocation is placed in the request.
>
>privacy model problems, primarily with 
>retransmission.  I'd like to solve the easier problem first.
>
>--Martin
>
>
>next? Would it ever- be safe foor a picky 
>intermediary to allow a reference to pass it, 
>semantic  I donâ€™™t necessarily think that 
>CONFIDENTIALITY NOTICE: The information 
>contained in this message may be privileged 
>and/or confidential. If you are not the intended 
>recipient, or responsible for delivering this 
>message to the intended recipient, any review, 
>forwarding, dissemination, distribution or 
>copying of this communication or any 
>attachment(s) is strictly prohibited. If you 
>have received this message in error, please 
>notify the sender immediately, and delete it and 
>all attachments from your computer and network.

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 05:47:40 -0500

The problem with 2 locationValues is they can both be values or 
location URIs, which gets us back into the problems of the bloated 
text and all it had to account for in previous versions.

James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 07:02:13 -0500

At 06:00 AM 7/20/2010, Elwell, John wrote:
>The ABNF for the Geolocation header field allows multiple 
>locationValues and multiple routing-params, in any order. The text 
>below seems to limit it to 0 or 1 locationValue and 0 or 1 
>routing-param, and furthermore it limits it so that the 
>routing-param must be last. It seems this could be expressed much 
>more precisely, and still quite easily, in the ABNF. Of have I 
>misunderstood something?

good catch! At this time (in -03) there is only one Geolocation 
header, so there is no need to look further for a "no".

>suggests that there can be multiple instances of the header field 
>and hence multiple locationValues.

this is the same catch as above - and there is only one locationValue 
currently.

>So a request can contain multiple locationValues, but not in the 
>same header field instance. Is this really what is intended?
>

The Geopriv "Using Protocol" is from the original requirements doc 
from SIPPING, which is now the appendix here. It comes from RFC 3693, 
which Geopriv is going to revise eventually with their Geopriv Arch 
ID, that removes the use of this term.  Geopriv Arch is only an 
update to 3693, and not a replacement, meaning 3693 will remain 
actively appropriate, so I'm kinda caught with which to align with.

James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 25 Jul 2010 07:04:54 -0500

At 06:50 PM 7/20/2010, Thomson, Martin wrote:
>Damn.  You would have to point out my big blind 
>spot.  I've been concentrating on the 
>routing-based-on-caller-location use case too long.
>
>If we also consider that the location needs to 
>be attributed to a particular entity, you can 
>either add syntax that attempts to identify the 
>entity that you are talking about (a "from" or 
>"to" parameter might do this), or you can make 
>the entity constant.  In the interest of 
>simplicity, the latter seems more fashionable:
>
>"
>The Geolocation header identifies a source of 
>location information.  This might be a PIDF-LO 
>document that is identified by value or 
>reference, or a geo: URI that includes location information directly.
>
>A Geolocation header indicates that a) that this 
>location information is somehow applicable to 
>the entity that initiated the request and b) 
>that this location information might be relevant 
>to the processing of the SIP request.
>"

I'm reading this believing someone here believes 
part of -03 needs to replace text with the above, 
but I'm not sure which text needs replacing from 
this discussion. Can someone point to the paragraph in question?

James

>This is almost the "bold" interpretation that 
>says that this Target’s location should be 
>considered the source of the request.  It does 
>not imply that the Target and source are the 
>same identity.  Nor does it expressly state that 
>the source is actually located anywhere in 
>particular, though we're walking a fairly fine line there.
>
>--Martin

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 25 Jul 2010 16:07:31 +0200

> actively appropriate, so I'm kinda caught with which to align with.
[JRE] Notwithstanding the question of whether we make use of the term "Using Protocol" or some other term, this doesn't address my concern. The present text uses the passive voice, and therefore doesn't make it clear who must review.

John

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 25 Jul 2010 22:13:44 +0800

> text and all it had to account for in previous versions.

Saying "don't do that" works.  It's about as effective as any of the other specification-type tools we have.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 25 Jul 2010 22:18:01 +0800

I feel like some of this is old ground, but I chalk that up to you doing all these replies while you were offline.

 (I'll note that some of your recent responses are in response to emails that you have already responded to.)

> different location, meaning the wrong PSAP will be contacted.

It's not the transit time that is the problem, it’s the uses of location after that.  The call can certainly last longer than a few seconds.

> that's much more probable -- because that's how 3GPP treats their

Then they have some reconsidering to do in how they deploy this spec.  There are methods for dealing with this that might be more practical in those environments, but less so on the wider Internet.  Digital signatures, for example.

... 
> >privacy model problems, primarily with retransmission.
 
Meaning <retransmission-allowed>.  I would hope that people know how to use UDP and TCP by now.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 25 Jul 2010 22:40:24 +0800

> this discussion. Can someone point to the paragraph in question?

Let's discuss this tomorrow.  However, I think that this might be added to the very start of Section 4, which currently has almost no text.

---

From: Brian Rosen <[email-masked]>
Date: Sun, 25 Jul 2010 14:53:23 -0400

I was hoping this would settle out the right way, but alas....

First of all, I don't think value + reference from the same source is really all that important.  It can be accomplished with a reference that returns what the value would have been to unauthenticated dereferencers.  It's more efficient to use value+reference, but not by much.

However. in the end, I think (despite my being a coauthor), the mechanism in -03 is insufficient.  If you want to treat emergency call as a corner case, that is okay, but it's an important one.

I don't think intermediaries will 424 and ask the UAC to compose something they like.  I think they will drop the existing header and replace it with what they want it to be.  

I think the requirement is either two PIDFs in one geolocation header, or or two parameters in one header.  That get us into "used for routing", but assuming the intermediary will 424 rather than replace is, in my opinion, fantasy.

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 26 Jul 2010 10:00:14 +0200

In addition, the proper reference is RFC 5808, which specifies  
requirements for location dereference mechanisms.

On Jul 25, 2010, at 4:07 PM, Elwell, John wrote:

> [JRE] Notwithstanding the question of whether we make use of the  
> term "Using Protocol" or some other term, this doesn't address my  
> concern. The present text uses the passive voice, and therefore  
> doesn't make it clear who must review.
>
> John
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Jul 2010 19:43:51 +0800

> > >to the processing of the SIP request.

To this, it has been suggested that we expand on this to the following effect:

The subject of a PIDF document is identified in the "entity" attribute of the document element.  If this is identical to the identity provided by the UAC in the From header of the request, then the PIDF-LO describes the location of the UAC.

--Martin