Location Conveyance for the Session Initiation Protocol
RFC 6442

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    sipcore mailing list <sipcore@ietf.org>,
    sipcore chair <sipcore-chairs@tools.ietf.org>
Subject: Protocol Action: 'Location Conveyance for the Session Initiation Protocol' to Proposed Standard (draft-ietf-sipcore-location-conveyance-09.txt)

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.