Protocol Action: 'Location Conveyance for the Session Initiation Protocol' to Proposed Standard (draft-ietf-sipcore-location-conveyance-09.txt)
The IESG <iesg-secretary@ietf.org> Mon, 12 September 2011 15:02 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1BE21F8BBC; Mon, 12 Sep 2011 08:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level:
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOx8cYwsLeKC; Mon, 12 Sep 2011 08:02:59 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DBC21F8BB7; Mon, 12 Sep 2011 08:02:58 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Location Conveyance for the Session Initiation Protocol' to Proposed Standard (draft-ietf-sipcore-location-conveyance-09.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110912150258.1148.26349.idtracker@ietfa.amsl.com>
Date: Mon, 12 Sep 2011 08:02:58 -0700
Cc: sipcore mailing list <sipcore@ietf.org>, sipcore chair <sipcore-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Sep 2011 15:03:00 -0000
The IESG has approved the following document: - 'Location Conveyance for the Session Initiation Protocol' (draft-ietf-sipcore-location-conveyance-09.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/ Technical Summary This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. Working Group Summary This work began in the (now concluded) SIPPING working group back in 2003, and progressed through the (also concluded) SIP working group before being finalized in the SIPCORE working group. The protocol mechanism underwent significant simplification in early 2010 to reflect a better understanding of the core requirements underpinning the work. Although this simplification was initially controversial, the working group did manage to achieve a rather strong consensus around the new mechanism after some additional changes. Document Quality This protocol mechanism is described in the 3GPP document 24.229 as a component of certain emergency calling scenarios in IMS-based networks. It was developed in the SIP and SIPCORE working groups with input from GEOPRIV working group participants. RFC Editor Note: (updated to apply to -09) 1) In Section 4.4 OLD There is no guidance given in this document as to which locationValue, when more than one was present in the SIP request, is related to the Geolocation-Error code; meaning that, somehow not defined here, the LR just picks one to error. NEW When more than one locationValue is present in a SIP request, this mechanism provides no indication which one the Geolocation- Error code corresponds to. If multiple errors are present, the LR applies local policy to select one. 2) Section 4.6, fourth paragraph, first sentence: OLD location information via an HTTP NEW location information via HTTP 3) Section 8.3, registration of geolocation-http: OLD via an HTTP NEW via HTTP 4) Please change the current inclusion of TLP 3.0 section 6.b to use the TLP 4.0 section 6.b.