Skip to main content

Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
draft-ietf-geopriv-local-civic-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    geopriv mailing list <geopriv@ietf.org>,
    geopriv chair <geopriv-chairs@tools.ietf.org>
Subject: Protocol Action: 'Specifying Civic Address Extensions in PIDF-LO' to Proposed Standard (draft-ietf-geopriv-local-civic-10.txt)

The IESG has approved the following document:
- 'Specifying Civic Address Extensions in PIDF-LO'
  (draft-ietf-geopriv-local-civic-10.txt) as Proposed Standard

This document is the product of the Geographic Location/Privacy 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-geopriv-local-civic/


Ballot Text

Technical Summary:

This document provides a number of updates to existing IETF civic addressing standards.  A
backwardly-compatible mechanism for adding civic address elements to the Geopriv civic address
format is described.  A formal mechanism for handling unsupported extensions when translating
between XML and DHCP civic address forms is defined for entities that need to perform this
translation.  Intial extensions for some new elements are also defined.  The LoST (RFC5222) protocol
mechanism that returns civic address element names used for validation of location information is
clarified and is normatively updated to require a qualifying namespace identifier on each civic address
element returned as part of the validation process.

Working Group Summary:

There was a great deal of WG energy spent on the question of how to balance extensibility of civic
addressing (including extensions for local use only) with the need for backwards compatability with
existing implementations. In the end we arrived at a solution that the key interested parties are
satisfied with.

Document Quality:

The National Emergency Number Association (NENA) has a technical standard dependent on this
work, and several implementations of it are in progress or exist already. There were not any special
reviews of this document, although it received substantial attention throughout the process from many
core working group members.

Personnel:

Alissa Cooper is the document shepherd. Robert Sparks in the responsible area director. 

RFC Editor Note:

Section 3.2 Under figure 3:
OLD:
Length is the number of octets used to represent the namespace URI, local name and value.

NEW:
Length is the number of octets used to represent the namespace URI, local name and value. The length includes the space between the namespace URI and local name and the space between the local name and value fields.

RFC Editor Note