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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 01 November 2010 23:03 UTC

Return-Path: <keith.drage@alcatel-lucent.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 5CB123A6A04 for <sipcore@core3.amsl.com>; Mon, 1 Nov 2010 16:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 t3bzn6KPzUey for <sipcore@core3.amsl.com>; Mon, 1 Nov 2010 16:03:41 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 3C35D3A69C9 for <sipcore@ietf.org>; Mon, 1 Nov 2010 16:03:39 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA1N3XpU004683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Nov 2010 00:03:33 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 2 Nov 2010 00:03:33 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "hannu.hietalahti@nokia.com" <hannu.hietalahti@nokia.com>, "rbarnes@bbn.com" <rbarnes@bbn.com>, "jmpolk@cisco.com" <jmpolk@cisco.com>
Date: Tue, 02 Nov 2010 00:03:33 +0100
Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes
Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEA==
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE21970860F@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.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>
In-Reply-To: <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.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-Scanned-By: MIMEDefang 2.64 on 155.132.188.13
Cc: "sipcore@ietf.org" <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, 01 Nov 2010 23:03:42 -0000

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