Re: [sipcore] Location Conveyance -04 submitted, here's the changes
<hannu.hietalahti@nokia.com> Mon, 08 November 2010 05:06 UTC
Return-Path: <hannu.hietalahti@nokia.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104DE3A697A for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 21:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.724
X-Spam-Level:
X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCwVbY5zpIp7 for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 21:06:17 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A5CB63A6980 for <sipcore@ietf.org>; Sun, 7 Nov 2010 21:06:16 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA856G79010171; Mon, 8 Nov 2010 07:06:21 +0200
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:06:12 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:06:07 +0200
Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 8 Nov 2010 06:06:07 +0100
From: hannu.hietalahti@nokia.com
To: john.elwell@siemens-enterprise.com, jon.peterson@neustar.biz, keith.drage@alcatel-lucent.com, rbarnes@bbn.com, jmpolk@cisco.com
Date: Mon, 08 Nov 2010 06:06:04 +0100
Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes
Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3LAAJ3WTAABNZXQA==
Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FEF8CAD@NOK-EUMSG-06.mgdnok.nokia.com>
References: <A444A0F8084434499206E78C106220CA02357AD02C@MCHP058A.global-ad.net> <C8FD749C.47D22%jon.peterson@neustar.biz> <A444A0F8084434499206E78C106220CA02357AD53B@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA02357AD53B@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 08 Nov 2010 05:06:07.0841 (UTC) FILETIME=[A6FC5D10:01CB7F02]
X-Nokia-AV: Clean
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Nov 2010 05:06:22 -0000
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 >-----Original Message----- >From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com] >Sent: 08 November, 2010 06:55 >To: Peterson, Jon; DRAGE, Keith (Keith); Hietalahti Hannu >(Nokia-CIC/Oulu); rbarnes@bbn.com; jmpolk@cisco.com >Cc: sipcore@ietf.org >Subject: RE: [sipcore] Location Conveyance -04 submitted, >here's the changes > >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 > >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >> Sent: 08 November 2010 01:34 >> To: Elwell, John; DRAGE, Keith (Keith); >> hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Location Conveyance -04 submitted, >> here's the changes >> >> >> 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" >> <john.elwell@siemens-enterprise.com> 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 >> 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 >> >> > -----Original Message----- >> > From: DRAGE, Keith (Keith) >> [mailto:keith.drage@alcatel-lucent.com] >> > Sent: 05 November 2010 04:37 >> > To: Elwell, John; hannu.hietalahti@nokia.com; >> > rbarnes@bbn.com; jmpolk@cisco.com >> > Cc: sipcore@ietf.org >> > Subject: RE: [sipcore] Location Conveyance -04 submitted, >> > here's the changes >> > >> > 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 >> > >> > > -----Original Message----- >> > > From: Elwell, John >> [mailto:john.elwell@siemens-enterprise.com] >> > > Sent: Thursday, November 04, 2010 5:48 PM >> > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; >> > > rbarnes@bbn.com; jmpolk@cisco.com >> > > Cc: sipcore@ietf.org >> > > Subject: RE: [sipcore] Location Conveyance -04 submitted, >> > > here's the changes >> > > >> > > 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 >> > > >> > > > -----Original Message----- >> > > > From: sipcore-bounces@ietf.org >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, >> > Keith (Keith) >> > > > Sent: 01 November 2010 23:04 >> > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; >> jmpolk@cisco.com >> > > > Cc: sipcore@ietf.org >> > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, >> > > here's the >> > > > changes >> > > > >> > > > 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 >> > > > >> > > > > -----Original Message----- >> > > > > From: hannu.hietalahti@nokia.com >> > > > [mailto:hannu.hietalahti@nokia.com] >> > > > > Sent: Monday, November 01, 2010 11:46 AM >> > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; >> jmpolk@cisco.com >> > > > > Cc: sipcore@ietf.org >> > > > > 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. >> > > > > >> > > > > 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: sipcore-bounces@ietf.org >> > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of >> ext DRAGE, >> > > > > Keith (Keith) >> > > > > >Sent: 28 October, 2010 16:01 >> > > > > >To: Richard L. Barnes; James M. Polk >> > > > > >Cc: sipcore@ietf.org >> > > > > >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: sipcore-bounces@ietf.org >> > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Richard >> > > L. Barnes >> > > > > >> Sent: Thursday, October 28, 2010 1:19 PM >> > > > > >> To: James M. Polk >> > > > > >> Cc: sipcore@ietf.org >> > > > > >> 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 >> > > > > >> (inv >> >> >>
- [sipcore] Location Conveyance -04 submitted, here… James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … Richard L. Barnes
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John
- Re: [sipcore] Location Conveyance -04 submitted, … James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John
- Re: [sipcore] Location Conveyance -04 submitted, … James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John
- Re: [sipcore] Location Conveyance -04 submitted, … Richard L. Barnes
- Re: [sipcore] Location Conveyance -04 submitted, … DRAGE, Keith (Keith)
- Re: [sipcore] Location Conveyance -04 submitted, … Peterson, Jon
- Re: [sipcore] Location Conveyance -04 submitted, … Thomson, Martin
- Re: [sipcore] Location Conveyance -04 submitted, … James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … James M. Polk
- Re: [sipcore] Location Conveyance -04 submitted, … hannu.hietalahti
- Re: [sipcore] Location Conveyance -04 submitted, … DRAGE, Keith (Keith)
- Re: [sipcore] Location Conveyance -04 submitted, … hannu.hietalahti
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John
- Re: [sipcore] Location Conveyance -04 submitted, … DRAGE, Keith (Keith)
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John
- Re: [sipcore] Location Conveyance -04 submitted, … Peterson, Jon
- Re: [sipcore] Location Conveyance -04 submitted, … Richard L. Barnes
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John
- Re: [sipcore] Location Conveyance -04 submitted, … hannu.hietalahti
- Re: [sipcore] Location Conveyance -04 submitted, … hannu.hietalahti
- Re: [sipcore] Location Conveyance -04 submitted, … Elwell, John