Location Conveyance for the Session Initiation Protocol
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, sipcore mailing list <firstname.lastname@example.org>, sipcore chair <email@example.com> 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.