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

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 27 October 2010 11:59 UTC

Return-Path: <rbarnes@bbn.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 611153A6882 for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 04:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, 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 k2rcPI94wfhP for <sipcore@core3.amsl.com>; Wed, 27 Oct 2010 04:59:40 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A53233A67CF for <sipcore@ietf.org>; Wed, 27 Oct 2010 04:59:40 -0700 (PDT)
Received: from [128.89.253.125] (port=52636 helo=[192.168.1.15]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PB4h7-00053q-Mw; Wed, 27 Oct 2010 08:01:30 -0400
Message-Id: <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: James M. Polk <jmpolk@cisco.com>
In-Reply-To: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 27 Oct 2010 08:01:27 -0400
References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com>
X-Mailer: Apple Mail (2.936)
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: Wed, 27 Oct 2010 11:59:42 -0000

Thanks a lot for revising this document.

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.

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