Begin forwarded message:
> From: The IESG <iesg-secretary@ietf.org>
> Date: September 12, 2011 11:02:58 AM EDT
> To: IETF-Announce <ietf-announce@ietf.org>
> Cc: sipcore mailing list <sipcore@ietf.org>, sipcore chair <sipcore-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.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.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
