HTTP-Enabled Location Delivery (HELD)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, geopriv mailing list <email@example.com>, geopriv chair <firstname.lastname@example.org> Subject: Protocol Action: 'HTTP Enabled Location Delivery (HELD)' to Proposed Standard The IESG has approved the following document: - 'HTTP Enabled Location Delivery (HELD) ' <draft-ietf-geopriv-http-location-delivery-16.txt> as a Proposed Standard This document is the product of the Geographic Location/Privacy Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-16.txt
Technical Summary: A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of session-layer. This document describes the use of Hypertext Transfer Protocol (HTTP) as a transport for the protocol. Working Group Summary: This document represents a very strong consensus position of the GEOPRIV working group. This consensus was unusually difficult to acheive and carries a long history of conflict and compromise. Document Quality: There is at least one existing implementations of the protocol described in this document and strong interest in implementation and deployment. The protocol described here is referenced in ongoing work in the ECRIT working group. Lisa Dusseault has been active as the GEOPRIV working group's technical advisor during the development of this document. Personnel Richard Barnes is the proto document shepherd and Cullen Jennings is the mostly Responsible Area Director. RFC Editor Note Please move [I-D.ietf-ltru-4646bis] to be a Normative reference. At the end of 1st paragraph of Section 5: OLD: Messages are defined as XML documents. NEW: Messages are defined as XML documents which are always encoded in UTF-8. Note that when "application/held+xml" media type is transported in HTTP the charset parameter with value UTF-8 is required. Two changes in Section 11.3: OLD: File extension(s): .xml NEW: File extension(s): .heldxml OLD: Interoperability considerations: This content type provides a basis for a protocol NEW: Interoperability considerations: This content type provides a basis for a protocol. There are multiple interoperable implementations of this protocol.