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

<hannu.hietalahti@nokia.com> Tue, 02 November 2010 06:49 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 E3BF83A6811 for <sipcore@core3.amsl.com>; Mon, 1 Nov 2010 23:49:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 vPPvJAu4n8+H for <sipcore@core3.amsl.com>; Mon, 1 Nov 2010 23:49:45 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 945233A67E2 for <sipcore@ietf.org>; Mon, 1 Nov 2010 23:49:44 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA26mmCU017775; Tue, 2 Nov 2010 08:48:49 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 08:48:48 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 08:48:47 +0200
Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 2 Nov 2010 07:48:27 +0100
From: <hannu.hietalahti@nokia.com>
To: <keith.drage@alcatel-lucent.com>, <rbarnes@bbn.com>, <jmpolk@cisco.com>
Date: Tue, 2 Nov 2010 07:48:25 +0100
Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes
Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEAATC3FA
Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FDD4CCF@NOK-EUMSG-06.mgdnok.nokia.com>
References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <EDC0A1AE77C57744B664A310A0B23AE219707BC9@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.com> <EDC0A1AE77C57744B664A310A0B23AE21970860F@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE21970860F@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
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: 02 Nov 2010 06:48:47.0979 (UTC) FILETIME=[003C53B0:01CB7A5A]
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: Tue, 02 Nov 2010 06:49:47 -0000

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
 

>-----Original Message-----
>From: ext DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] 
>Sent: 02 November, 2010 01:04
>To: 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
>
>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
>> >> (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
>> >> >>> sipcore@ietf.org
>> >> >>> https://www.ietf.org/mailman/listinfo/sipcore
>> >> >
>> >> > _______________________________________________
>> >> > sipcore mailing list
>> >> > sipcore@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/sipcore
>> >> 
>> >> _______________________________________________
>> >> sipcore mailing list
>> >> sipcore@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/sipcore
>> >> 
>> >_______________________________________________
>> >sipcore mailing list
>> >sipcore@ietf.org
>> >https://www.ietf.org/mailman/listinfo/sipcore
>> >