Subject: [sipcore] rebooting location-conveyance

From: Jon Peterson <[email-masked]>
Date: Thu, 25 Mar 2010 14:27:55 -0700

James Polk and I sat down this week and took a hard look at the current sipcore-location-conveyance draft, and we believe that there's an opportunity to simplify (and shorten) the document.

The simplification derives mostly from a single change to the operation of the mechanism. Today, the location-conveyance draft has a good deal of machinery to support the case where a proxy wants to replace existing location information in a request with more accurate or preferred location information. The current approach replaces the URI in the Geolocation header (which probably points to a MIME body) with a URI desired by the proxy, presumably of an Internet resource containing the desired PIDF-LO body. This solution isn't optimal for several reasons - most notably, since the MIME body is not removed by said proxy, it will still be delivered to the eventual location recipient, even if the URI in the Geolocation header does not point to said body. In order to handle this case, the current draft employs a disambiguation mechanism (relying on the "used-for-routing" and "inserted-by" parameters, as well as the "inserter") to inform the location recipient about the source of this location information. Moreover, since this change is effected unilaterally, the originating user agent has no idea that the location it supplied has been altered in transit, and may thus receive a surprising response to its request.

While this use case is an important one, we believe it can be addressed with a lighter mechanism. The basic idea is that a proxy server that wants to replace the location information provided by a user agent would reject a request with the 424 Bad Location response code, optionally enclosing in the body the location information that it would like the user agent to incorporate.  The UA can insert the LI from the 424 in its subsequent reissuance of the request; if no LI is supplied in the 424, then the user agent resends the request without LI. This brings the location-conveyance mechanism back to one its original constraints: that only one PIDF-LO body is associated with a particular SIP request. This allows us to remove the "used-for-routing" parameter as well as the "inserted-by"/"inserter" mechanism.

In a related clean-up, several of the error codes can probably be consolidated or replaced with SIP response codes (for example, the Retry-After semantics of the 200/300 error codes).

If no one objects, we'd therefore like to try to come back with a new version that has fewer moving parts and fewer pages.

Thoughts?

Jon Peterson
NeuStar, Inc.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 25 Mar 2010 22:54:44 +0100

So, I believe the current solution allows a scenario where the originating UA inserts a location, and various proxies along the path could insert a location, in addition to the existing one, providing they all represent their view of the state of the user.

By making this proposal, are you eliminating this scenario, or allowing it to continue to exist.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jon Peterson
> Sent: Thursday, March 25, 2010 9:28 PM
> To: [email-masked]
> Subject: [sipcore] rebooting location-conveyance
> 
> James Polk and I sat down this week and took a hard look at 
> the current sipcore-location-conveyance draft, and we believe 
> that there's an opportunity to simplify (and shorten) the document.
> 
> The simplification derives mostly from a single change to the 
> operation of the mechanism. Today, the location-conveyance 
> draft has a good deal of machinery to support the case where 
> a proxy wants to replace existing location information in a 
> request with more accurate or preferred location information. 
> The current approach replaces the URI in the Geolocation 
> header (which probably points to a MIME body) with a URI 
> desired by the proxy, presumably of an Internet resource 
> containing the desired PIDF-LO body. This solution isn't 
> optimal for several reasons - most notably, since the MIME 
> body is not removed by said proxy, it will still be delivered 
> to the eventual location recipient, even if the URI in the 
> Geolocation header does not point to said body. In order to 
> handle this case, the current draft employs a disambiguation 
> mechanism (relying on the "used-for-routing" and 
> "inserted-by" parameters, as well as the "inserter") to 
> inform the location recipient about the source of th  is 
> location information. Moreover, since this change is effected 
> unilaterally, the originating user agent has no idea that the 
> location it supplied has been altered in transit, and may 
> thus receive a surprising response to its request.
> 
> While this use case is an important one, we believe it can be 
> addressed with a lighter mechanism. The basic idea is that a 
> proxy server that wants to replace the location information 
> provided by a user agent would reject a request with the 424 
> Bad Location response code, optionally enclosing in the body 
> the location information that it would like the user agent to 
> incorporate.  The UA can insert the LI from the 424 in its 
> subsequent reissuance of the request; if no LI is supplied in 
> the 424, then the user agent resends the request without LI. 
> This brings the location-conveyance mechanism back to one its 
> original constraints: that only one PIDF-LO body is 
> associated with a particular SIP request. This allows us to 
> remove the "used-for-routing" parameter as well as the 
> "inserted-by"/"inserter" mechanism.
> 
> In a related clean-up, several of the error codes can 
> probably be consolidated or replaced with SIP response codes 
> (for example, the Retry-After semantics of the 200/300 error codes).
> 
> If no one objects, we'd therefore like to try to come back 
> with a new version that has fewer moving parts and fewer pages.
> 
> Thoughts?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 26 Mar 2010 07:42:59 +0800

Hi Jon,

I'd welcome any attempt to make this document simpler.  Over time, it's built up a fair amount of baggage as it's made it's way through four (?) working groups.  This sounds like a reasonable cut.

The use case that is a victim of this is the one where a host has two locations: by value and by reference that they want to include.  This might be the "now" and "for later" use case, or it could be the location hiding use case where the value is poor quality and the reference might be used to get the really good stuff.  As long as we are able to address that use case, then I'm happy.

I don't think that we need to re-build all that stuff that you are stripping out, but we currently don't have a good story for that.

--Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jon Peterson
> Sent: Thursday, 25 March 2010 2:28 PM
> To: [email-masked]
> James Polk and I sat down this week and took a hard look at the current
> sipcore-location-conveyance draft, and we believe that there's an
> opportunity to simplify (and shorten) the document.
> 
> The simplification derives mostly from a single change to the operation
> of the mechanism. Today, the location-conveyance draft has a good deal
> of machinery to support the case where a proxy wants to replace
> existing location information in a request with more accurate or
> preferred location information. The current approach replaces the URI
> in the Geolocation header (which probably points to a MIME body) with a
> URI desired by the proxy, presumably of an Internet resource containing
> the desired PIDF-LO body. This solution isn't optimal for several
> reasons - most notably, since the MIME body is not removed by said
> proxy, it will still be delivered to the eventual location recipient,
> even if the URI in the Geolocation header does not point to said body.
> In order to handle this case, the current draft employs a
> disambiguation mechanism (relying on the "used-for-routing" and
> "inserted-by" parameters, as well as the "inserter") to inform the
> location recipient about the source of th
>  is location information. Moreover, since this change is effected
> unilaterally, the originating user agent has no idea that the location
> it supplied has been altered in transit, and may thus receive a
> surprising response to its request.
> 
> While this use case is an important one, we believe it can be addressed
> with a lighter mechanism. The basic idea is that a proxy server that
> wants to replace the location information provided by a user agent
> would reject a request with the 424 Bad Location response code,
> optionally enclosing in the body the location information that it would
> like the user agent to incorporate.  The UA can insert the LI from the
> 424 in its subsequent reissuance of the request; if no LI is supplied
> in the 424, then the user agent resends the request without LI. This
> brings the location-conveyance mechanism back to one its original
> constraints: that only one PIDF-LO body is associated with a particular
> SIP request. This allows us to remove the "used-for-routing" parameter
> as well as the "inserted-by"/"inserter" mechanism.
> 
> In a related clean-up, several of the error codes can probably be
> consolidated or replaced with SIP response codes (for example, the
> Retry-After semantics of the 200/300 error codes).
> 
> If no one objects, we'd therefore like to try to come back with a new
> version that has fewer moving parts and fewer pages.
> 
> Thoughts?
> 
> Jon Peterson
> NeuStar, Inc.
> 
>

---

From: Jon Peterson <[email-masked]>
Date: Thu, 25 Mar 2010 17:09:11 -0700

Semantically, a single SIP request can contain multiple locations within 
the constraints of the presence data model - PIDF-LO is after all PIDF, 
and like any presence document it can make fairly complicated statements 
about the relationship of location information to users or devices, 
including enumerating multiple locations. However, the intention of the 
revision is to return this to an old design constraint where a SIP 
request may contain only a single Geolocation header field with one URI 
pointing to location information.

Jon Peterson
NeuStar, Inc.

---

From: Jon Peterson <[email-masked]>
Date: Thu, 25 Mar 2010 17:23:44 -0700

Broadly, any use case where you want to deliver two different locations 
to the same recipient is one that can be expressed semantically in 
PIDF-LO. I think that trying to implement this sort of semantics in the 
SIP layer has to be the wrong approach - it is far less brittle to 
extend PIDF than to add this to SIP. Ultimately, a by value PIDF-LO MIME 
body in a SIP request could, for example, contain a URI where someone 
could go to get location by reference in the future. That sounds like it 
could cover your use case at a high level, though of course we'd have to 
explore that in more detail.

Jon Peterson
NeuStar, Inc.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 26 Mar 2010 02:19:33 +0100

So on the basis that your answer appears to be NO to my question, I believe I cannot support the change you are proposing.

regards

Keith 

> From: Jon Peterson [mailto:[email-masked]] 
> Sent: Friday, March 26, 2010 12:09 AM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [sipcore] rebooting location-conveyance
> 
> 
> Semantically, a single SIP request can contain multiple 
> locations within the constraints of the presence data model - 
> PIDF-LO is after all PIDF, and like any presence document it 
> can make fairly complicated statements about the relationship 
> of location information to users or devices, including 
> enumerating multiple locations. However, the intention of the 
> revision is to return this to an old design constraint where 
> a SIP request may contain only a single Geolocation header 
> field with one URI pointing to location information.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > So, I believe the current solution allows a scenario where 
> the originating UA inserts a location, and various proxies 
> along the path could insert a location, in addition to the 
> existing one, providing they all represent their view of the 
> state of the user.
> >
> >> James Polk and I sat down this week and took a hard look at the 
> >> current sipcore-location-conveyance draft, and we believe that 
> >> there's an opportunity to simplify (and shorten) the document.
> >>
> draft has 
> >> a good deal of machinery to support the case where a proxy 
> wants to 
> >> replace existing location information in a request with 
> more accurate 
> >> or preferred location information.
> >> The current approach replaces the URI in the Geolocation header 
> >> (which probably points to a MIME body) with a URI desired by the 
> >> proxy, presumably of an Internet resource containing the desired 
> >> PIDF-LO body. This solution isn't optimal for several 
> reasons - most 
> >> notably, since the MIME body is not removed by said proxy, it will 
> >> still be delivered to the eventual location recipient, even if the 
> >> URI in the Geolocation header does not point to said body. 
> In order 
> >> to handle this case, the current draft employs a disambiguation 
> >> mechanism (relying on the "used-for-routing" and "inserted-by" 
> >> parameters, as well as the "inserter") to inform the location 
> >> recipient about the source of th  is location information. 
> Moreover, 
> >> since this change is effected unilaterally, the originating user 
> >> agent has no idea that the location it supplied has been 
> altered in 
> >> transit, and may thus receive a surprising response to its request.
> >>
> >> addressed with a lighter mechanism. The basic idea is that a proxy 
> >> server that wants to replace the location information 
> provided by a 
> >> user agent would reject a request with the 424 Bad 
> Location response 
> >> code, optionally enclosing in the body the location 
> information that 
> >> it would like the user agent to incorporate.  The UA can 
> insert the 
> >> LI from the 424 in its subsequent reissuance of the 
> request; if no LI 
> >> is supplied in the 424, then the user agent resends the request 
> >> without LI.
> associated with a 
> >> particular SIP request. This allows us to remove the 
> >> "used-for-routing" parameter as well as the 
> "inserted-by"/"inserter" 
> >> mechanism.
> >>
> with a new

---

From: "Francois D. Menard" <[email-masked]>
Date: Thu, 25 Mar 2010 22:09:27 -0400

I am concerned that this change may impact the ability for end-to-end location conveyance to work.

Am I wrong?

F.

On 2010-03-25, at 8:09 PM, Jon Peterson wrote:

> 
> Semantically, a single SIP request can contain multiple locations within the constraints of the presence data model - PIDF-LO is after all PIDF, and like any presence document it can make fairly complicated statements about the relationship of location information to users or devices, including enumerating multiple locations. However, the intention of the revision is to return this to an old design constraint where a SIP request may contain only a single Geolocation header field with one URI pointing to location information.
> 
> Jon Peterson
> NeuStar, Inc.
> 
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Peterson
>>> The simplification derives mostly from a single change to the operation of the mechanism. Today, the location-conveyance draft has a good deal of machinery to support the case where a proxy wants to replace existing location information in a request with more accurate or preferred location information. The current approach replaces the URI in the Geolocation header (which probably points to a MIME body) with a URI desired by the proxy, presumably of an Internet resource containing the desired PIDF-LO body. This solution isn't optimal for several reasons - most notably, since the MIME body is not removed by said proxy, it will still be delivered to the eventual location recipient, even if the URI in the Geolocation header does not point to said body. In order to handle this case, the current draft employs a disambiguation mechanism (relying on the "used-for-routing" and "inserted-by" parameters, as well as the "inserter") to inform the location recipient about the source of th  is location information. Moreover, since this change is effected unilaterally, the originating user agent has no idea that the location it supplied has been altered in transit, and may thus receive a surprising response to its request.
>>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 26 Mar 2010 17:52:20 +0800

Yes.  Or at least I think so.

> Behalf Of Francois D. Menard
> Sent: Thursday, 25 March 2010 7:09 PM
> To: Jon Peterson
> Cc: DRAGE, Keith (Keith); [email-masked]
> > Semantically, a single SIP request can contain multiple locations
> within the constraints of the presence data model - PIDF-LO is after
> all PIDF, and like any presence document it can make fairly complicated
> statements about the relationship of location information to users or
> devices, including enumerating multiple locations. However, the
> intention of the revision is to return this to an old design constraint
> where a SIP request may contain only a single Geolocation header field
> with one URI pointing to location information.
> >
> > Jon Peterson
> > NeuStar, Inc.
> >
> >> So, I believe the current solution allows a scenario where the
> originating UA inserts a location, and various proxies along the path
> could insert a location, in addition to the existing one, providing
> they all represent their view of the state of the user.
> >>
> current sipcore-location-conveyance draft, and we believe that there's
> an opportunity to simplify (and shorten) the document.
> >>>
> operation of the mechanism. Today, the location-conveyance draft has a
> good deal of machinery to support the case where a proxy wants to
> replace existing location information in a request with more accurate
> or preferred location information. The current approach replaces the
> URI in the Geolocation header (which probably points to a MIME body)
> with a URI desired by the proxy, presumably of an Internet resource
> containing the desired PIDF-LO body. This solution isn't optimal for
> several reasons - most notably, since the MIME body is not removed by
> said proxy, it will still be delivered to the eventual location
> recipient, even if the URI in the Geolocation header does not point to
> said body. In order to handle this case, the current draft employs a
> location recipient about the source o
>  f th  is location information. Moreover, since this change is effected
> server that wants to replace the location information provided by a
> user agent would reject a request with the 424 Bad Location response
> code, optionally enclosing in the body the location information that it
> would like the user agent to incorporate.  The UA can insert the LI
> from the 424 in its subsequent reissuance of the request; if no LI is
> supplied in the 424, then the user agent resends the request without
> LI. This brings the location-conveyance mechanism back to one its
> original constraints: that only one PIDF-LO body is associated with a
> particular SIP request. This allows us to remove the "used-for-routing"
> parameter as well as the "inserted-by"/"inserter" mechanism.
> >>>
> >>> If no one objects, we'd therefore like to try to come back with a
> new version that has fewer moving parts and fewer pages.
> >>>
> >>> Thoughts?
> >>>
> >>> Jon Peterson
> >>> NeuStar, Inc.
> >>>
> >>>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Mar 2010 15:45:54 +0100

What do the emergency call people think about having to retry, with a possible impact on call establishment times?

John 

> Sent: 25 March 2010 14:28
> To: [email-masked]
> inform the location recipient about the source of th
>  is location information. Moreover, since this change is 
> effected unilaterally, the originating user agent has no idea 
> that the location it supplied has been altered in transit, 
> and may thus receive a surprising response to its request.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Mar 2010 10:50:28 -0400

I can't imagine it could - in fact, I think it makes end-to-end work better - but if you can elaborate on your concern we could explore that further.

Jon Peterson
NeuStar, Inc.

On 3/25/10 7:09 PM, "Francois D. Menard" <[email-masked]> wrote:

Am I wrong?

F.

---

From: Jon Peterson <[email-masked]>
Date: Fri, 26 Mar 2010 08:09:35 -0700

In the emergency services case, I would not imagine intermediaries would 
confine themselves to the role of proxy servers - if they don't like the 
location attached to a message, I'm sure they'd just remove it, insert 
their own and forward the request. Why would we expect them to do otherwise?

The way the location-conveyance mechanism works now - where, in that 
case, the intermediary removes the cid pointer to the MIME body it 
doesn't like, but leaves the MIME body in the request and provides a new 
URL to the preferred location information - seems like it is an even 
worse way of accomplishing the aims of an emergency services 
intermediary, and one that surely would be supplanted in deployments by 
some kind of special-purpose intermediary that doesn't conform to the 
standard.

In the emergency services case, we need to do several things we wouldn't 
do otherwise, such as ignoring some classes of security violations 
because the consequences of not processing a call are so dire that we 
need to be generous in what we accept. The real question is if the 
steadily-growing set of parameters that have been defined in the draft 
to this point actually serve the practical requirements for emergency 
services or other use cases.

Jon Peterson
NeuStar, Inc.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 26 Mar 2010 16:54:48 +0100

1)	At least on the emergency calls I've been looking at, we've been doing our best to make sure intermediaries are proxies. Insertions could well be location by reference, rather than location by value as a result. B2BUAs break transparency - remember?

2)	From day 1) on emergency calls, the ethos has been - Do not make judgements on the value of information to the PSAP. Therefore in the work I've been involved in, we never remove information from an emergency call. Everything is passed to the PSAP in some form. This makes it impossible to fulfil that.

regards

Keith 

> Sent: Friday, March 26, 2010 3:10 PM
> To: Elwell, John
> Cc: [email-masked]
> In the emergency services case, I would not imagine 
> intermediaries would confine themselves to the role of proxy 
> servers - if they don't like the location attached to a 
> message, I'm sure they'd just remove it, insert their own and 
> forward the request. Why would we expect them to do otherwise?
> 
> The way the location-conveyance mechanism works now - where, 
> in that case, the intermediary removes the cid pointer to the 
> MIME body it doesn't like, but leaves the MIME body in the 
> request and provides a new URL to the preferred location 
> information - seems like it is an even worse way of 
> accomplishing the aims of an emergency services intermediary, 
> and one that surely would be supplanted in deployments by 
> some kind of special-purpose intermediary that doesn't 
> conform to the standard.
> 
> In the emergency services case, we need to do several things 
> we wouldn't do otherwise, such as ignoring some classes of 
> security violations because the consequences of not 
> processing a call are so dire that we need to be generous in 
> what we accept. The real question is if the steadily-growing 
> set of parameters that have been defined in the draft to this 
> point actually serve the practical requirements for emergency 
> > What do the emergency call people think about having to 
> retry, with a possible impact on call establishment times?
> >
> > John
> >
> >

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Mar 2010 09:38:02 -0700

[as participant]

Actually, I read his response as a qualified "yes." If we go to base 
requirements and ask whether proxies on the path can take action to 
cause their own view of the user's location to be added to the request, 
then the requirement -- by my understanding -- is satisfied by the 
proposed mechanism.

/a

On 3/25/10 6:19 PM, DRAGE, Keith (Keith) wrote:
>>> By making this proposal, are you eliminating this scenario,
>>>        
>> or allowing it to continue to exist.
>>      
>>> regards
>>>
>>> Keith
>>>
>>>
>>>
>>>
>>>        
>> "inserted-by"/"inserter"
>>>> mechanism.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Mar 2010 13:07:02 -0400

Taxonomy aside, the core architectural question is how much support is needed for carrying multiple locations in a single  SIP request, and whether that support should be staged at the SIP layer or the body (PIDF) layer. Parameters like "inserted-by" cause immediate suspicion precisely because they straddle that boundary - it is the job of PIDF to explain who generated this location information and what data model element is coupled to the location information. Merely pointing from the SIP layer to different PIDF bodies describing different locations does not clarify the relationship of these elements to one another in data model terms.

While one can argue that you couldn't sort that out in a timeframe expedient enough for the emergency services case, I continue to maintain that we should expect exceptional behavior from intermediaries tailored to help emergency services calls along their path. The job of the network in this case is to deliver quickly the best information it can to the right service - the argument that you "never remove information from an emergency call" does not entail "encourage the accumulation of a bewildering variety of different locations without describing their relationship to one another." At the end of the day, of course, the result of placing an emergency services call will probably be the delivery of location information to someone who is still required to ask the caller personally for their location, and this only further illustrates why we treat this as a special case. For the common case, we want an architecturally clean way to associate a SIP request with location information.

Jon Peterson
NeuStar, Inc.

On 3/26/10 8:54 AM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 26 Mar 2010 18:41:22 +0100

And I read it as no, as essentially only one location goes forward.

The original predicate from Jon was that we have multiple locations because an intermediate devices wants to replace the existing location.

My view is that this never was a use case. The use case was that an intermediate entity had location information relating to the sender of the message, for which it did not know whether it was better or worse that that created by other location inserters. Therefore the solution sends all the locations to the location recipient, and the recipient then makes its own value discussion. 

There was also a use case where there was no location from the original sender at all, but I read that as not being impacted by Jon's input.

For information the relevant requirement for this part of the work was:

"   Proxy-1  Proxy servers must be capable of adding a Location header 
            field during processing of SIP requests.

   Motivation:  Provide network assertion of location
            when UACs are unable to do so, or when network assertion is
            more reliable than UAC assertion of location

   Note: Because UACs connected to SIP signaling networks may have 
         widely varying access network arrangements, including VPN 
         tunnels and roaming mechanisms, it may be difficult for a 
         network to reliably know the location of the endpoint.  Proxy 
         assertion of location is NOT RECOMMENDED unless the SIP 
         signaling network has reliable knowledge of the actual 
         location of the Targets.
"

However it probably does not help advance the argument from either side.

regards

Keith

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Friday, March 26, 2010 4:38 PM
> To: DRAGE, Keith (Keith)
> Cc: Jon Peterson; [email-masked]
> Actually, I read his response as a qualified "yes." If we go 
> to base requirements and ask whether proxies on the path can 
> take action to cause their own view of the user's location to 
> be added to the request, then the requirement -- by my 
> understanding -- is satisfied by the proposed mechanism.
> 
> /a
> 
> > So on the basis that your answer appears to be NO to my 
> question, I believe I cannot support the change you are proposing.
> >
> > regards
> >
> > Keith
> >
> >    
> >> all PIDF, and like any presence document it can make fairly 
> >> complicated statements about the relationship of location 
> information 
> >> to users or devices, including enumerating multiple locations. 
> >> However, the intention of the revision is to return this to an old 
> >> design constraint where a SIP request may contain only a single 
> >> Geolocation header field with one URI pointing to location 
> >> information.
> >>
> >> Jon Peterson
> >> NeuStar, Inc.
> >>
> along the 
> >> path could insert a location, in addition to the existing one, 
> >> providing they all represent their view of the state of the user.
> >>      
> probably be

---

From: "Thomson, Martin" <[email-masked]>
Date: Sat, 27 Mar 2010 03:38:39 +0800

This, to me is the best trade-off.  The complexity costs that would be incurred from the current specification are not justifiable when considered against what is only idealistic advantage.  This is especially true when, as Jon points out, the use case we are discussing allows for extraordinary actions that have more serious ramifications than the mere loss of transparency.

--Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peterson, Jon
Sent: Friday, 26 March 2010 10:07 AM
To: DRAGE, Keith (Keith); Elwell, John
Cc: [email-masked]
Subject: Re: [sipcore] rebooting location-conveyance

Taxonomy aside, the core architectural question is how much support is needed for carrying multiple locations in a single  SIP request, and whether that support should be staged at the SIP layer or the body (PIDF) layer. Parameters like “inserted-by” cause immediate suspicion precisely because they straddle that boundary – it is the job of PIDF to explain who generated this location information and what data model element is coupled to the location information. Merely pointing from the SIP layer to different PIDF bodies describing different locations does not clarify the relationship of these elements to one another in data model terms.

While one can argue that you couldn’t sort that out in a timeframe expedient enough for the emergency services case, I continue to maintain that we should expect exceptional behavior from intermediaries tailored to help emergency services calls along their path. The job of the network in this case is to deliver quickly the best information it can to the right service - the argument that you “never remove information from an emergency call” does not entail “encourage the accumulation of a bewildering variety of different locations without describing their relationship to one another.” At the end of the day, of course, the result of placing an emergency services call will probably be the delivery of location information to someone who is still required to ask the caller personally for their location, and this only further illustrates why we treat this as a special case. For the common case, we want an architecturally clean way to associate a SIP request with location information.

Jon Peterson
NeuStar, Inc.

regards

Keith

> services or other use cases.
…