Last Call: <draft-ietf-geopriv-local-civic-06.txt> (Specifying Civic Address Extensions in PIDF-LO) to Proposed Standard

The IESG <> Thu, 20 September 2012 22:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2308421E80A9; Thu, 20 Sep 2012 15:23:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.531
X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zOnjdxHboA8r; Thu, 20 Sep 2012 15:23:43 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 52E2D21F856F; Thu, 20 Sep 2012 15:23:43 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Last Call: <draft-ietf-geopriv-local-civic-06.txt> (Specifying Civic Address Extensions in PIDF-LO) to Proposed Standard
X-Test-IDTracker: no
X-IETF-IDTracker: 4.34
Message-ID: <>
Date: Thu, 20 Sep 2012 15:23:43 -0700
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Sep 2012 22:23:44 -0000

The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Specifying Civic Address Extensions in PIDF-LO'
  <draft-ietf-geopriv-local-civic-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the mailing lists by 2012-10-04. Exceptionally, comments may be
sent to instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.


   New fields are occasionally added to civic addresses.  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.

The file can be obtained via

IESG discussion can be tracked via

The following IPR Declarations may be related to this I-D: