Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes

From: <[email-masked]>
Date: Mon, 1 Nov 2010 12:46:02 +0100

Hi Keith,

yes, I remember you made this comment at Maastricht already, and I agree with you that from 3GPP viewpoint we need encoding that allows *more than one* piece of location information.

In 3GPP case those would be typically the one obtained from the terminal and the one added by the serving network if it thinks it knows better. 

But my imagination runs out after these two. Are you saying we need more than 2?

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext DRAGE, Keith (Keith)
>Sent: 28 October, 2010 16:01
>To: Richard L. Barnes; James M. Polk
>Cc: [email-masked]
>Subject: Re: [sipcore] Location Conveyance -04 submitted, 
>here's the changes
>
>To be more specific - we had a document that allowed multiple 
>locations. It was reduced to one without any decision in that 
>direction being made by the working group. It needs to go back 
>to multiple values.
>
>In my view there are clear use cases where multiple values are 
>required.
>
>regards
>
>Keith 
>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Richard L. Barnes
>> Sent: Thursday, October 28, 2010 1:19 PM
>> To: James M. Polk
>> Cc: [email-masked]
>> Subject: Re: [sipcore] Location Conveyance -04 submitted, 
>> here's the changes
>> 
>> >> I'm pretty comfortable with the document at this point, 
>> but have just 
>> >> one minor question: Why are you still limiting the number 
>> of location 
>> >> values?  Why are three values harmful, but not two?  This 
>> still seems 
>> >> like pointless ABNF legislation.
>> >
>> > we only added the ability to have a second locationValue 
>because of 
>> > your rough-loc ID. Before that, we were firm in not 
>> allowing more than 
>> > one.  Given that choice, which do you like?
>> >
>> > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it 
>> > seemed everyone and their brother was agreeable with, so ...
>> 
>> 
>> As I recall, the proposal was to just remove the limit on 
>the number  
>> of locations values, not to bump it up by one.  From the minutes:
>> 
>> "Restore Geolocation header that has multiple URIs, even though we  
>> would not recommend it. Entities inserting persence are responsbile  
>> for any resulting errors. The header parameters distinguishing URIs  
>> would not be added back in."
>> 
>> At least in my mind, multiple != 2.
>> 
>> --Richard
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > james
>> >
>> >
>> >> --Richard
>> >>
>> >>
>> >>
>> >>
>> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote:
>> >>
>> >>> SIPCORE
>> >>>
>> >>> I've submitted the next version of Location Conveyance (-04)
>> >>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
>> n-conveyance-04.txt
>> >>> and I believe this version has addressed each open item from the
>> >>> mailing list, as well as what was discussed and agreed to in the
>> >>> Maastricht meeting.
>> >>>
>> >>> I have attempted to identify each open issue with the specific
>> >>> resolution here (in no particular order):
>> >>>
>> >>> - Martin wanted Section 3 to be broken up into subsections, each
>> >>> revolving around each of the 4 diagrams. I have done this.
>> >>>
>> >>> - allowed a maximum of two (up from one) locationValues to be
>> >>> present in the Geolocation header value. The text however 
>> recommends
>> >>> against inserting a second value. This was agreed to in 
>> Maastricht.
>> >>>
>> >>> - Because we're allowing a max of two locationValues, 
>> they can be in
>> >>> separate Geolocation headers in the SIP request. This scenario
>> >>> necessitates bring a previous version's paragraph in 
>> stating that a
>> >>> 'SIP intermediary MUST inspect all instances of each Geolocation
>> >>> header before considering the routing-allowed parameter to be
>> >>> considered =yes', to ensure there isn't a conflict in the 'other'
>> >>> Geolocation header that states the policy is =no.
>> >>>
>> >>> - with the ability to add a second locationValue, it is 
>> necessary to
>> >>> warn against doing this (confusion at the LRs).
>> >>>
>> >>> - Added the "you break it you bought it" philosophy to SIP
>> >>> intermediaries that choose to insert a second location where one
>> >>> already existed, especially for inserting a location URI in the
>> >>> downstream SIP request.
>> >>>
>> >>> - Fixed the ABNF to handle zero, one or two (but no more)
>> >>> locationValues according to the agreement in Maastricht.  
>> There is a
>> >>> one-off use case which won't be in play very often, but 
>> is a WG item
>> >>> in ECRIT that several wanted to allow the possibility for 
>> (involving
>> >>> allowing one coarse and one highly accurate location in 
>> the same SIP
>> >>> request).
>> >>>
>> >>> - Paul K. wanted the use-case in which a SIP intermediary 
>> inserts a
>> >>> locationValue where one didn't exist previously, and 
>> received a 424
>> >>> (Bad Location Information) to that inserted location, from having
>> >>> the 424 propagate towards the UAC (as the UAC might not 
>> know what to
>> >>> do with a 424). This is now covered in Section 4.3.
>> >>>
>> >>> - changed existing text to "MUST NOT" from "does not" about a 424
>> >>> not terminating an existing dialog (just increased the 
>strength of
>> >>> this.
>> >>>
>> >>> - I added the 424 to the table 2 entry in which the Geolocation
>> >>> header can be in only this response.
>> >>>
>> >>> - I added text stating the conditions for adding a Geolocation
>> >>> header value to the 424, to make it clear what is and what isn't
>> >>> allowed for this.
>> >>>
>> >>> - Martin wanted me to add back in the top level Geolocation-Error
>> >>> codes 100, 200, 300 and 400, which I did in section 4.3.
>> >>>
>> >>> - rejected the idea that the geolocation option-tag hasn't been
>> >>> justified.
>> >>>
>> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the 
>> references section
>> >>> because I added the ability to include HTTP: and HTTPS: URIs, and
>> >>> stated if received, they should be dereferenced according to the
>> >>> HELD Deref doc.
>> >>>
>> >>> - changed the Section 5 examples how Martin wanted them.
>> >>>
>> >>> - Stated that GEO-URIs are not appropriate for the SIP 
>Geolocation
>> >>> header, according to the discussion during the Maastricht Geopriv
>> >>> meeting.
>> >>>
>> >>> - we changed the privacy section, and included a ref to 
>> the Geopriv
>> >>> Arch doc, according to the agreement in Geopriv at Maastricht.
>> >>>
>> >>>
>> >>> Comments are encouraged
>> >>>
>> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting 
>> in Beijing
>> >>> (to give folks a sense of our plans).
>> >>>
>> >>> James/Brian/Jon
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> sipcore mailing list
>> >>> [email-masked]
>> >>> https://www.ietf.org/mailman/listinfo/sipcore
>> >
>> > _______________________________________________
>> > sipcore mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/sipcore
>> 
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 2 Nov 2010 00:03:33 +0100

If in 3GPP we look at subscription based business trunking arrangement.

The end terminal includes one location.

The enterprise network supporting the UE adds its own view of where the UE is.

The public network adds its own view of the location.

That makes three.

regards

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, November 01, 2010 11:46 AM
> To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [sipcore] Location Conveyance -04 submitted, 
> here's the changes
> 
> Hi Keith,
> 
> yes, I remember you made this comment at Maastricht already, 
> and I agree with you that from 3GPP viewpoint we need 
> encoding that allows *more than one* piece of location information.
> 
> In 3GPP case those would be typically the one obtained from 
> the terminal and the one added by the serving network if it 
> thinks it knows better. 
> 
> >Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the 
> >changes
> >
> >locations. It was reduced to one without any decision in 
> that direction 
> >being made by the working group. It needs to go back to multiple 
> >values.
> >
> here's the 
> >> changes

---

From: <[email-masked]>
Date: Tue, 2 Nov 2010 07:48:25 +0100

Thanks, Keith,

I was not sure why the public network would add its idea of the user location if it has received one from the corporate network already, but I can't see why it would not be allowed to do so either.

So it seems your are right.

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

>From: ext DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 02 November, 2010 01:04
>To: Hietalahti Hannu (Nokia-CIC/Oulu); [email-masked]; 
>[email-masked]
>Cc: [email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Nov 2010 18:48:21 +0100

Keith,

Be very careful with this sort of approach. The trend is towards fewer SIP-PBXs and fewer "SIP trunks" serving an enterprise, with often a single SIP-PBX and a single entry into the SIP Service Provider for a whole country or even multiple countries. Even for the single country case, the service provider network is unlikely to have a clue as to where, in the country, the caller might be located (or even where the PBX is located if there are two geographically separate servers). Caller ID isn't likely to help either, since users can move around within the enterprise network.

John

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: 01 November 2010 23:04
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Nov 2010 05:36:41 +0100

Exactly, that is why I am saying you need multiples.

Otherwise the scenario is that the PBX puts one in, and the public network then replaces it because it says the regulator tells the network to always provide a location. At least with my approach, all the locations are there, and the PSAP then sorts it out.

Keith

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, November 04, 2010 5:48 PM
> To: DRAGE, Keith (Keith); [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Be very careful with this sort of approach. The trend is 
> towards fewer SIP-PBXs and fewer "SIP trunks" serving an 
> enterprise, with often a single SIP-PBX and a single entry 
> into the SIP Service Provider for a whole country or even 
> multiple countries. Even for the single country case, the 
> service provider network is unlikely to have a clue as to 
> where, in the country, the caller might be located (or even 
> where the PBX is located if there are two geographically 
> separate servers). Caller ID isn't likely to help either, 
> since users can move around within the enterprise network.
> 
> John
> 
> > > yes, I remember you made this comment at Maastricht 
> already, and I 
> > > agree with you that from 3GPP viewpoint we need encoding 
> that allows 
> > > *more than one* piece of location information.
> > > 
> > > In 3GPP case those would be typically the one obtained from the 
> > > terminal and the one added by the serving network if it thinks it 
> > > knows better.
> > > 
> > > But my imagination runs out after these two. Are you 
> saying we need 
> > > more than 2?
> > > 
> > > BR,
> > > Hannu Hietalahti
> > > 3GPP TSG CT Chairman
> > > tel: +358 40 5021724
> > >  
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Nov 2010 08:22:48 +0100

Yes, I agree that replacing an enterprise-provided location is very bad. The problem with adding locations to locations already present is how the PSAP chooses between 2 or even 3 locations. From my reading of the draft, we don't have any normative statement on the order in which locations are placed in the header. If we had a rule that the first locationValue within a single or multiple Geolocation header fields is nearest to the source of the request, and so on, it might help. Then it would be clear that the service provider-provided location would be the least reliable, but it would still be there, e.g., for use if the other locations are bogus.

John

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: 05 November 2010 04:37
> To: Elwell, John; [email-masked]; 
> Otherwise the scenario is that the PBX puts one in, and the 
> public network then replaces it because it says the regulator 
> tells the network to always provide a location. At least with 
> my approach, all the locations are there, and the PSAP then 
> sorts it out.
> 
> Keith
> 
> > > The enterprise network supporting the UE adds its own 
> view of where 
> > > the UE is.
> > >

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 7 Nov 2010 20:34:20 -0500

I don't think the draft can do anything more helpful than say you shouldn't include multiple location objects because they are confusing, and if you do permit multiple location objects, do so only in an environment where the inserter and recipient share some agreement about their meaning and interpretation (a slight expansion of "you break it you bought it," there). I don't think it will be a useful or successful exercise for us to try to concretize that in a standard.

Jon Peterson
NeuStar, Inc.

On 11/5/10 12:22 AM, "Elwell, John" <[email-masked]> wrote:

John

> > > > >> (inv

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 08 Nov 2010 09:37:46 +0800

+1

What's called for here is cautionary text, not anything normative.
--Richard

On 11/8/10 9:34 AM, Peterson, Jon wrote:
>
> I don’t think the draft can do anything more helpful than say you
> shouldn’t include multiple location objects because they are confusing,
> and if you do permit multiple location objects, do so only in an
> environment where the inserter and recipient share some agreement about
> their meaning and interpretation (a slight expansion of “you break it
> you bought it,” there). I don’t think it will be a useful or successful
> exercise for us to try to concretize that in a standard.
>
> Jon Peterson
> NeuStar, Inc.
>
>
>     Yes, I agree that replacing an enterprise-provided location is very
>     bad. The problem with adding locations to locations already present
>     is how the PSAP chooses between 2 or even 3 locations. From my
>     reading of the draft, we don't have any normative statement on the
>     order in which locations are placed in the header. If we had a rule
>     that the first locationValue within a single or multiple Geolocation
>     header fields is nearest to the source of the request, and so on, it
>     might help. Then it would be clear that the service
>     provider-provided location would be the least reliable, but it would
>     still be there, e.g., for use if the other locations are bogus.
>
>     John
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Nov 2010 05:55:11 +0100

The only normative thing I was suggesting we add was to do with ordering, so that if there is >1 location present, the first is the one from nearest the source of the request. I don't see what harm that would do, and it could help in some circumstances.

John 

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: 08 November 2010 01:34
> To: Elwell, John; DRAGE, Keith (Keith); 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> I don't think the draft can do anything more helpful than say 
> you shouldn't include multiple location objects because they 
> are confusing, and if you do permit multiple location 
> objects, do so only in an environment where the inserter and 
> recipient share some agreement about their meaning and 
> interpretation (a slight expansion of "you break it you 
> bought it," there). I don't think it will be a useful or 
> successful exercise for us to try to concretize that in a standard.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> 
> On 11/5/10 12:22 AM, "Elwell, John" 
> <[email-masked]> wrote:
> 
> 
> 
> 	Yes, I agree that replacing an enterprise-provided 
> location is very bad. The problem with adding locations to 
> locations already present is how the PSAP chooses between 2 
> or even 3 locations. From my reading of the draft, we don't 
> have any normative statement on the order in which locations 
> are placed in the header. If we had a rule that the first 
> locationValue within a single or multiple Geolocation header 
> fields is nearest to the source of the request, and so on, it 
> provider-provided location would be the least reliable, but 
> it would still be there, e.g., for use if the other locations 
> are bogus.
> 	
> 	John
> 	
> 	> > From: Elwell, John 
> [mailto:[email-masked]]
> 	> > > > >[mailto:[email-masked]] On Behalf Of 
> ext DRAGE,
> 	> > > > Keith (Keith)
> 	> > > > >> [mailto:[email-masked]] On Behalf 
> Of Richard
> 	> > L. Barnes
> 	> > > > >> > Remember, this was Jon's proposal in 
> SIPCORE in Anaheim,
> 	> > > > which it
> 	> > > > >> "Restore Geolocation header that has 
> multiple URIs, even
> 	> > > though we
> 	> > > > >> would not recommend it. Entities inserting 
> persence are
> 	> > > > responsbile
> 	> > > > >> >>> and I believe this version has addressed 
> each open
> 	> > > > item from the
> 	> > > > >> >>> mailing list, as well as what was 
> discussed and agreed
> 	> > > > to in the
> 	> > > > >> >>> Maastricht meeting.
> 	> > > > >> >>>
> 	> > > > >> >>> 'SIP intermediary MUST inspect all 
> instances of each
> 	> > > > Geolocation
> 	> > > > >> >>> considered =yes', to ensure there isn't 
> a conflict in
> 	> > > > the 'other'
> 	> > > > >> >>> intermediaries that choose to insert a 
> second location
> 	> > > > where one
> 	> > > > >> >>> already existed, especially for 
> inserting a location
> 	> > > > URI in the
> 	> > > > >> >>> downstream SIP request.
> 	> > > > >> >>>

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 06:01:44 +0100

Dear all,

under the open sky the satellite navigator of the terminal probably does give the most accurate location information. But the location obtained by the network via base station in a motorway / train tunnel in is probably much better than the one from the UE at the same time. And we need to serve the terminals without GPS also.

So therefore I tend to agree with Jon that as long as it is possible to encode multiple location objects (which we unfortunately need to allow), the application level logic how to use those locations at the receiving end is outside of the scope of this document. In this draft we should not define any preference or indication which one of them is best.

Having said that, do you see any problem to just mandate it or to build the syntax in such a way that additional instances of location object are always appended after the existing ones, withouth giving the reason or otherwise ranking them into any other order than purely chronological? While I can't guarantee that the terminal provided location is always the most accurate, this way it would be at least possible to identify which one was closest to the origin of the message (and even that does not guarantee it came all the way from the terminal since the 3GPP UE is required to provide its location only is if knows its location).

This way it would be at least possible to find the location that was inserted first...or last, if that is preferred.

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

________________________________
From: ext Peterson, Jon [mailto:[email-masked]]
Sent: 08 November, 2010 03:34
To: Elwell, John; DRAGE, Keith (Keith); Hietalahti Hannu (Nokia-CIC/Oulu); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes

Jon Peterson
NeuStar, Inc.

John

---

From: <[email-masked]>
Date: Mon, 8 Nov 2010 06:06:04 +0100

John,

I agree, but I am curious to what kind of application you have in mind to use the first/last/middle location object, please?

BR,
Hannu Hietalahti
3GPP TSG CT Chairman
tel: +358 40 5021724

>From: ext Elwell, John [mailto:[email-masked]] 
>Sent: 08 November, 2010 06:55
>To: Peterson, Jon; DRAGE, Keith (Keith); Hietalahti Hannu 
>(Nokia-CIC/Oulu); [email-masked]; [email-masked]
>Cc: [email-masked]
>The only normative thing I was suggesting we add was to do 
>with ordering, so that if there is >1 location present, the 
>first is the one from nearest the source of the request. I 
>don't see what harm that would do, and it could help in some 
>circumstances.
>
>John 
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 8 Nov 2010 07:03:53 +0100

Hannu,

It may just be a case of displaying the locations in a specific order to the call taker, rather than any automated application.

John 

> Sent: 08 November 2010 05:06
> To: Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> I agree, but I am curious to what kind of application you 
> have in mind to use the first/last/middle location object, please?
> 
> BR,
> Hannu Hietalahti
> 3GPP TSG CT Chairman
> tel: +358 40 5021724
>  
>