[sipcore] Location Conveyance -04 submitted, here's the changes
"James M. Polk" <jmpolk@cisco.com> Wed, 27 October 2010 04:30 UTC
Return-Path: <jmpolk@cisco.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 821AE3A68F7 for <sipcore@core3.amsl.com>; Tue, 26 Oct 2010 21:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.543
X-Spam-Level:
X-Spam-Status: No, score=-110.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 poCtZheibgGX for <sipcore@core3.amsl.com>; Tue, 26 Oct 2010 21:30:35 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9BD083A698C for <sipcore@ietf.org>; Tue, 26 Oct 2010 21:30:32 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKZHx0yrR7Hu/2dsb2JhbAChVnGjM5wrgnOCVQSEVw
X-IronPort-AV: E=Sophos;i="4.58,244,1286150400"; d="scan'208";a="276356693"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2010 04:32:21 +0000
Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9R4WLe8013111 for <sipcore@ietf.org>; Wed, 27 Oct 2010 04:32:21 GMT
Message-Id: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 26 Oct 2010 23:32:20 -0500
To: sipcore@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [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 04:30:57 -0000
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] 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