Skip to main content

Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition
draft-ietf-geopriv-civic-address-recommendations-03

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5774.
Authors Alexander Mayrhofer , Karl Wolf
Last updated 2015-10-14 (Latest revision 2009-07-09)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Best Current Practice
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5774 (Best Current Practice)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Cullen Fluffy Jennings
Send notices to (None)
draft-ietf-geopriv-civic-address-recommendations-03
GEOPRIV                                                          K. Wolf
Internet-Draft                                              A. Mayrhofer
Updates: 4776 (if approved)                                       nic.at
Intended status: BCP                                        July 9, 2009
Expires: January 10, 2010

  Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA
                          Registry Definition
          draft-ietf-geopriv-civic-address-recommendations-03

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document provides a guideline for creating civic address

Wolf & Mayrhofer        Expires January 10, 2010                [Page 1]
Internet-Draft        Civic Address Considerations             July 2009

   consideration documents for individual countries, as required by RFC
   4776.  Furthermore, this document also creates an IANA Registry
   referring to such address consideration documents and registers such
   an address consideration for Austria.

Wolf & Mayrhofer        Expires January 10, 2010                [Page 2]
Internet-Draft        Civic Address Considerations             July 2009

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6

   4.  Specifying PIDF-LO Element Usage . . . . . . . . . . . . . . .  7
     4.1.  General Considerations and Workflow  . . . . . . . . . . .  7
     4.2.  Guidelines for Individual Elements . . . . . . . . . . . .  8
       4.2.1.  Country  . . . . . . . . . . . . . . . . . . . . . . .  9
       4.2.2.  Country Subdivisions A1-A6 . . . . . . . . . . . . . .  9
       4.2.3.  Road and Street Names  . . . . . . . . . . . . . . . .  9
       4.2.4.  House Numbers  . . . . . . . . . . . . . . . . . . . . 10
       4.2.5.  Local Names  . . . . . . . . . . . . . . . . . . . . . 11
       4.2.6.  Floors . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.7.  Address Codes  . . . . . . . . . . . . . . . . . . . . 12
       4.2.8.  Other Elements . . . . . . . . . . . . . . . . . . . . 13

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  PIDF-LO Civic Address Consideration Registry . . . . . . . 14
       6.1.1.  Structure  . . . . . . . . . . . . . . . . . . . . . . 14
       6.1.2.  Registration Template  . . . . . . . . . . . . . . . . 15
       6.1.3.  Registry Location  . . . . . . . . . . . . . . . . . . 16
       6.1.4.  Registration Procedure . . . . . . . . . . . . . . . . 16
     6.2.  Registration Request for Austria . . . . . . . . . . . . . 16
     6.3.  Registration of the considerations in RFC 4776 as
           obsolete . . . . . . . . . . . . . . . . . . . . . . . . . 16

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19

   Appendix A.  Civic Address Considerations Registration for the
                Austrian building and habitation registry . . . . . . 19
     A.1.  Civic Address Format in Austria  . . . . . . . . . . . . . 20
     A.2.  Sample Addresses . . . . . . . . . . . . . . . . . . . . . 24
     A.3.  Address Codes in Austria . . . . . . . . . . . . . . . . . 25
     A.4.  Austrian Addresses in PIDF-LO  . . . . . . . . . . . . . . 25
       A.4.1.  Country  . . . . . . . . . . . . . . . . . . . . . . . 25
       A.4.2.  Country Subdivisions A1-A6 . . . . . . . . . . . . . . 25
       A.4.3.  Road and Street Names  . . . . . . . . . . . . . . . . 28
       A.4.4.  House Numbers  . . . . . . . . . . . . . . . . . . . . 29
       A.4.5.  Local Names  . . . . . . . . . . . . . . . . . . . . . 29
       A.4.6.  Floors . . . . . . . . . . . . . . . . . . . . . . . . 29
       A.4.7.  Additional Code Element  . . . . . . . . . . . . . . . 30
       A.4.8.  Other Elements . . . . . . . . . . . . . . . . . . . . 30

Wolf & Mayrhofer        Expires January 10, 2010                [Page 3]
Internet-Draft        Civic Address Considerations             July 2009

       A.4.9.  Elements not to be used  . . . . . . . . . . . . . . . 30
     A.5.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 31
     A.6.  IANA Registration Record . . . . . . . . . . . . . . . . . 32

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 33
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 34

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35

Wolf & Mayrhofer        Expires January 10, 2010                [Page 4]
Internet-Draft        Civic Address Considerations             July 2009

1.  Introduction

   The "Presence Information Data Format Location Object" (PIDF-LO)
   [RFC4119] is an object format for carrying geographical information
   on the Internet.  PIDF-LO can contain civic address information, and
   supports a range of "civic address types" (CATypes) to hold
   individual attributes of such addresses (see Section 2.2.1 of
   [RFC4119] and Section 3.1 of [RFC5139]).

   In many use cases, PIDF-LOs are populated with data from long-
   established sources, like postal or governmental building registers,
   line information databases and yellow / white pages of infrastructure
   providers, or official residents registers.  The structure and format
   of data from such sources is almost always different from PIDF-LO's
   CAtypes definition - additionally, structure and format of those
   sources differs from country to country.

   To make use of such existing data sources, transposing that data into
   PIDF-LO format is required.  With no guidelines available on how to
   map source Fields into CAtype Elements, different creators of PIDF-LO
   documents might end up with different results, even when using the
   same data source - which reduces interoperability and increases the
   risk of misinterpretation by receivers.

   Therefore, civic address considerations are necessary to ensure
   uniform usage of PIDF-LO Elements for such data sources.  [RFC4776]
   explicitly requests such documents to be provided, but does neither
   define their structure nor a way to publish them.  This memo provides
   documentation on how to create such civic address considerations, and
   requests the creation of an IANA Registry to store references to such
   documents.  Furthermore, a civic address consideration for Austria is
   provided in Appendix A to be registered in the IANA Registry.

   Section 3.4 of [RFC4776] contains some example considerations
   regarding the use of administrative sub-division elements for Canada,
   Germany, Japan, Korea and the United States.  This document IANA
   registers these examples as "obsolete" (see Section 6.3).

   Section 3.4 of [RFC4776] also contains instructions on the creation
   of Civic Address Consideration documents on page 8.  This document
   updates this section, and replaces said instructions with Section 4
   and 5 of this memo.

   The guidelines in this document have been created with a focus on
   formal application of PIDF-LO (such as conveying location during an
   emergency call).  It is not intended to forbid other, more informal
   uses of PIDF-LO that may not follow any formal mapping
   specifications.  An example usecase of such informal usage may be the

Wolf & Mayrhofer        Expires January 10, 2010                [Page 5]
Internet-Draft        Civic Address Considerations             July 2009

   transmission of PIDF-LO documents during an instant messaging session
   between humans.  Such use may, however, imply some drawbacks like
   prohibiting automatic processing of civic addresses from such a
   PIDF-LO.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   In addition, this document uses "Field" to refer to a field of a
   civic address data source, and "Element" to refer to a CAType element
   of a PIDF-LO.

3.  Requirements

   The following requirements apply to defining civic address mapping
   considerations:

   o  The considerations document MUST identify the data source to which
      the definitions apply.  A brief description of its structure
      SHOULD be provided as well.

   o  For any data source, just one active mapping definition should
      exist in order to reduce the risk of ambiguous interpretation.

   o  The document MUST include instructions for any Field that occurs
      in the data.  For any of the Fields, the document MUST describe
      whether the Field is required, optional, or must not be used in
      the mapping procedure.

   o  Instructions MUST be included for any CAtype Element that is
      registered by the time the document is created.  Those
      instructions MUST include information whether an Element is
      required, optional, or must not be used in that mapping.  In case
      the set of CAtypes is revised by the IETF, the address
      consideration document SHOULD be updated.  Until an update is
      approved, the existing mapping procedure MUST be used.

   o  Address mapping procedures SHOULD be reversible, so that location
      recipients can identify the corresponding record in the original
      data source (given they have access to that source).

Wolf & Mayrhofer        Expires January 10, 2010                [Page 6]
Internet-Draft        Civic Address Considerations             July 2009

   o  For any source data Field that is required or optional, at least
      one example mapping MUST be provided.

   o  In many cases, data sources used in the mapping process might be
      subject to access restrictions.  Such restrictions (as imposed on
      the original data) MUST also be imposed on the resulting PIDF-LO
      documents.  The considerations document SHOULD note such
      restrictions in its Security Considerations section.

   Although the mapping is defined in a national way and the actual
   meaning of several PIDF-LO Elements may not be clear to an outsider,
   at least the country element tells in what context this PIDF-LO was
   created.  In case of emergency calls, a PIDF-LO would just be passed
   to a PSAP in the same country as the location generator anyway.
   However, in a border region there might be exceptions and the PIDF-LO
   could be sent to a neighboring country.  The PIDF-LO can still be
   passed on to a PSAP in the right country (based on the country
   element), or the PSAP might be aware of the mapping scheme used in
   the neighboring country.

   A consistent mapping is also very important for checking if two
   PIDF-LO documents describe the same location.  When civic address
   Fields are put into different PIDF-LO Elements, it may be difficult
   to identify whether or not two PIDF-LOs describe identical addresses.

4.  Specifying PIDF-LO Element Usage

   The purpose of the civic address considerations for an individual
   data source is to create interoperability by specifying a common list
   of PIDF-LO Elements to be used, and by defining the mapping between
   these Elements and the Fields of the respective data source.

4.1.  General Considerations and Workflow

   The workflow for creating an address considerations document is as
   follows:

   1.  Describe the data source to which the address considerations
       document applies.
   2.  Identify all Fields from the data source, and decide for each of
       the Fields whether or not it is to be used for the purpose of
       creating PIDF-LO documents.  In the considerations document, all
       Fields must be listed (or at least state which Fields are
       considered in the mapping and clearly state that the other Fields
       MUST NOT be used).

Wolf & Mayrhofer        Expires January 10, 2010                [Page 7]
Internet-Draft        Civic Address Considerations             July 2009

   3.  For each of the Fields that is required or optional, specify a
       clear mapping instruction according to the guidelines below.
   4.  Provide a list of all CAtypes registered, and describe their
       level of usage in this mapping (or combine it with the list of
       Fields above and clearly list which Elements are not used for the
       mapping procedure).  For Elements that are not described in
       detail state whether they MUST NOT be used at all or they may be
       used without further restriction.
   5.  Provide examples of source data and mapping results

   Civic address fields are designed to be generic containers.  In some
   cases, Fields clearly correspond to such a container; however, in
   some other cases, identifying the correct container might require
   some approximation.  For example, in some countries the RD (road)
   Element might also be appropriate for other thoroughfares, like
   waterways or tunnels.

   Fields that are identified to have the same meaning as one of the
   CAtypes SHOULD be directly mapped to that CAtype Element.

   Where CAtype usage diverges from the original specification, the
   mapping definition of Fields that are mapped to that Element SHOULD
   include a discussion of the differences.

   Fields that do not fit into an existing CAtype: Even though the list
   of CAtypes could be extended, it is not feasible to add new elements
   for every new Field in every data source in every country.
   Therefore, unless new generic CAtypes are specified by the IETF, only
   existing elements can be used, which leaves the following options:

   1.  Concatenate several civic address fields into a single PIDF-LO
       element (define delimiters if applicable and make sure the
       separate civic address parts can be retrieved again)
   2.  Use a PIDF-LO element that is unused so far

   Note: Obviously, the first option is required if the number of Fields
   that are used in the mapping procedure is greater than the number of
   existing CAtype Elements.

   Note that the xml:lang attribute should be present in PIDF-LO XML
   documents according to RFC 5139.

4.2.  Guidelines for Individual Elements

   The following sections discuss individual PIDF-LO Elements and
   describe what to consider for each Element when defining civic
   address considerations.  It is RECOMMENDED to follow a similar
   structure for considerations documents.

Wolf & Mayrhofer        Expires January 10, 2010                [Page 8]
Internet-Draft        Civic Address Considerations             July 2009

4.2.1.  Country

   The country element must hold the alpha-2 codes from ISO 3166-1
   [refs.ISO3166-1] in upper case characters as clarified in Section 3.3
   of RFC 5139 [RFC5139].

   This element cannot be redefined on a national basis since it
   identifies the country itself.  This element is used to identify
   which national mapping for civic addresses has been used in a
   specific PIDF-LO.

   Example for Austria: <country>AT</country>

4.2.2.  Country Subdivisions A1-A6

   The elements A1 to A6 are used to hold national subdivision
   identifiers, with A1 holding the top-level subdivision identifier.
   A1 may either contain the second part of ISO 3166-2 [refs.ISO3166-2]
   (see section 3.4 of RFC 5139 [RFC5139]), or values as described in
   the address consideration document.  Elements "A2" to "A6" may
   contain additional levels of subdivisions (see section 2.2.1 of RFC
   4119).

   For A1, an address consideration document MUST state whether ISO
   3166-2 codes are to be used exclusively; alternatively it should
   define a list of values to be used (for example, subdivision names).
   In either case, A1 MUST NOT be redefined for any other use than
   describing top level subdivisions.

   For each of the A2 - A6 Elements that is required or optional, the
   document SHOULD define the set of allowed values, either by listing
   them, or by referring to such a list.

   Example for Austria:

   A1 province (Bundesland)
   A2 political district (politischer Bezirk) name or identifier
   A3 commune (Gemeinde) name or identifier
   A4 village (Ortschaft) name or identifier
   A5 cadastral municipality (Katastralgemeinde) name or identifier

   A6 must not be used.  For more details see the example in
   Appendix A.4.2.

4.2.3.  Road and Street Names

   PIDF-LO contains the following Elements related to road names: RD,
   RDSEC, RDBR, RDSUBADDR, PRM, POM (section 3.1 and 3.2 of RFC 5139

Wolf & Mayrhofer        Expires January 10, 2010                [Page 9]
Internet-Draft        Civic Address Considerations             July 2009

   [RFC5139]) and PRD, POD, STS (section 3.4 of [RFC4776]).  Note: The
   use of the A6 Element for street names is not valid any more (Section
   3.2 of RFC 5139 [RFC5139]).

   Besides the basic specification of which of those Elements are
   required, optional or not to be used, an address considerations
   document may also describe more complicated dependencies (for
   example, "RD is optional, but required if any other road name Element
   is used").

   For any required or optional element, the relation of those Elements
   to Fields of the data source used MUST be described, as well as
   special considerations (like concatenation of Fields into an Element)
   if they apply.  The usage of the Element STS (street suffix) SHOULD
   be consistent.  In case no suffixes are known in a data source, or it
   is common to write the street name and the suffix together, the STS
   Element SHOULD be left out completely.  If suffixes may be
   abbreviated the common abbreviations SHOULD be defined.

   Example for Austria:

   RD: street name

   All other road Elements must not be used.  Street suffixes are
   already included in the "street name" Field, and must not be
   abbreviated.

4.2.4.  House Numbers

   PIDF-LO specifies two Elements related to house numbers: HNO ("house
   number", numeric part only) and HNS ("house number suffix") (see
   section 3.4 of RFC 4776).  However, in many countries house numbers
   have a more complex format.  In any case, a clear definition is
   REQUIRED to minimize confusion potential.

   An address considerations document should provide the following
   information with regards to house numbers: If the structure of house
   numbers fits the HNO/HNS structure, the document MUST mandate to use
   those fields as described in RFC 4776.  If the structure of house
   numbers does not directly fit into those two Elements, the document
   MUST define strategies on how to map source Fields into Elements.
   Besides HNO and HNS, LOC and BLD could be considered for carrying
   house number information.

   The document SHOULD describe whether abbreviations of house number
   information is valid or not.  If abbreviations are used, they MUST be
   clearly defined.  If house number consists of more than one number,
   or multiple prefixes and suffixes may coexist, a delimiter symbol and

Wolf & Mayrhofer        Expires January 10, 2010               [Page 10]
Internet-Draft        Civic Address Considerations             July 2009

   a clear rule on how to concatenate all this data into the HNO and HNS
   element might be necessary.  Whenever concatenating data into one
   Element, keep in mind that the location recipient might want to
   separate the data again.

   Example from Austria:

   HNO: concatenate all the data elements of Austrian house numbers into
   this single PIDF-LO Element in a defined order with delimiter symbols
   (see Appendix A.4.4 for the complete definition).

   HNS: Usage not allowed since there may be multiple suffixes for the
   different parts of the house number.

   LOC and BLD are not to be used to reflect house number information.

4.2.5.  Local Names

   PIDF-LO contains three elements to reflect local names: LMK, LOC, NAM
   (section 3.4 of RFC 4776).  Such local names may be of importance for
   the identification of a location, and may either coexist with a valid
   civic address or (in some cases) no address may be assigned so that
   the local names itself identifies the location.  In rural regions for
   example, a farm name may be more common than a street address to
   identify a location.  Landmarks typically don't have any civic
   address information assigned.  Therefore, local names may assist in
   finding a "street name" type address, but they might also be the
   authoritative (and only) civic location information.

   For any required or optional Element out of LMK, LOC, NAM the
   considerations document should state potential values (source data)
   for the element.  In the case that multiple values for an Element may
   occur, a concatenation / selection strategy should be described.
   Concatenation using ";" as separator is recommended, unless this
   character also appears in the source Fields.

   If local name information and "common" address information is both
   available and used, the document SHOULD discuss the relation between
   those two address information types, and expected behaviour of
   location recipients.

   Example from Austria:

   NAM: contains the "Vulgoname" (local name), multiple local names are
   separated by a semicolon (if applicable)

   LMK: contains the farm name (just one name possible) (if applicable)

Wolf & Mayrhofer        Expires January 10, 2010               [Page 11]
Internet-Draft        Civic Address Considerations             July 2009

   LOC: can be used without restriction for additional location
   information (as per RFC 4119)

   The "Vulgoname" is useful to identify the location within its
   locality, since official addresses especially in rural regions might
   not be well known.

4.2.6.  Floors

   PIDF-LO defines the element FLR to hold floor information, but does
   not further specify its content.  Section 2.1 of RFC 3825 provides
   guidance about floor numbering, but is not directly related to
   PIDF-LO.

   An address considerations document SHOULD clearly specify how to
   express floors using the FLR element.  Following the above mentioned
   guidance is RECOMMENDED; however, local nomenclature might require a
   completely different system.  The document SHOULD specify whether
   only numbers, text, or both are allowed in the FLR element.  If there
   are standard values for certain floors, they SHOULD be listed.
   Abbreviations SHOULD be avoided, unless they are the primary (well
   known) way of identifying floors.

   Example from Austria:

   If floor numbers are to be mapped, the FLR Element MUST be used.
   Numbers and text are both allowed.  The first floor (<FLR>1</FLR>) is
   the first "full" floor above the floor at street level.  The floor at
   street level is <FLR>EG</FLR> or <FLR>0</FLR>.  There might be
   intermediate floors, especially between the floor at street level and
   the "first floor".  Such intermediate floors have names like
   "Mezzanine", "Erster Halbstock" ("first half floor"), "Zweiter
   Halbstock" ("second half floor"), and have local meanings.

4.2.7.  Address Codes

   Address codes are available in several countries in different forms
   (for estates, buildings or usable units for example).  These codes
   identify an address record, and MAY be placed in the ADDCODE element
   in PIDF-LO.  Address codes can help the location recipient to
   determine the location, and to identify the original record in the
   data source.  Depending on the type of code, the code alone (without
   any other Elements) may even be sufficient to fully identify an
   address within a country.

   In such cases, a PIDF-LO containing just the country and ADDCODE
   elements might provide enough information to retrieve a civic
   address, given the location recipient has access to the respective

Wolf & Mayrhofer        Expires January 10, 2010               [Page 12]
Internet-Draft        Civic Address Considerations             July 2009

   source database.

   A civic address considerations document SHOULD specify whether and in
   which applications the use of the ADDCODE Element is allowed.  If
   ADDCODE is used, its relation to the remaining Elements MUST be
   clearly stated.  If several namespaces for address codes exist in a
   country, a mechanism to distinguish the different code spaces MUST be
   described.

   Examples from Austria:

   Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode
   (AdrsubCD), Objektnummer (ObjNr) and Nutzungseinheitenlaufnummer
   (NtzLnr).

   The following format SHOULD be used:

        <ADDCODE>AdrCD=1234567;AdrsubCD=123;
        ObjNr=2333211;NtzLnr=0001</ADDCODE>

4.2.8.  Other Elements

   This section lists all PIDF-LO Elements that have not been discussed
   so far.

   To specify the location inside a building, the following Elements can
   be useful:

   o  UNIT
   o  ROOM
   o  SEAT

   The following Elements are to be used for the representation of
   postal codes:

   o  PC
   o  PCN
   o  POBOX

   To describe the place-type or the building, the following Elements
   are available:

   o  PLC - Place-type (see [RFC4589])
   o  BLD - Building (structure)

   For any of those Elements that are required or optional in a mapping,
   the semantics of its contents must be described, if it differs from
   the definition in the PIDF-LO base documents.

Wolf & Mayrhofer        Expires January 10, 2010               [Page 13]
Internet-Draft        Civic Address Considerations             July 2009

   It is RECOMMENDED that the elements SEAT, UNIT and ROOM remain to be
   used for identifying a location inside a building.  They MAY be used
   by the owner of the respective building if a considerations document
   does not restrict their use.  For example, an airport could decide to
   place the gate number in the UNIT element, and a location recipient
   could identify that PIDF-LO by the value of the PLC Element.  The
   name of the airport could be placed in NAM.

5.  Security Considerations

   RFC 4119 contains general security considerations for handling PIDF-
   LOs.

6.  IANA Considerations

   This document requests creation of the registry "PIDF-LO Civic
   Address Consideration Registry", according to the following
   definitions.  Furthermore, this document requests registration of a
   civic address considerations document for Austrian addresses as
   provided in the Appendix of this document and also registers the
   considerations of RFC 4776 as obsolete.

6.1.  PIDF-LO Civic Address Consideration Registry

6.1.1.  Structure

   The IANA Registry contains the following fields:

   o  Country-Code: Either the ISO 3166 alpha-two code of the country to
      which the consideration applies or "other" in case the
      consideration document is not specific to a particular country.
      This field is to be defined by the requestor.

   o  Serial Number: A number that uniquely identifies a considerations
      document within a certain "Country-Code" field value.  Serial
      Numbers are sequentially assigned by IANA per "Country-Code"
      value, start at zero, and are never reused.

   o  Reference to specification: This field contains a reference to the
      considerations document.

   o  Requestor: The author of the document.

   o  Status: One of "active" or "obsolete".  When the document is
      registered by IANA, the status is first set to "active" by IANA.
      Experts may later request changing the status to "obsolete",

Wolf & Mayrhofer        Expires January 10, 2010               [Page 14]
Internet-Draft        Civic Address Considerations             July 2009

      especially if there is an updated version of the considerations
      document available.  Authors of consideration documents must
      contact the experts if they wish to change the status of the
      document.

   Note: The combination of "Country-Code" and "Serial Number" fields
   uniquely identify a considerations document in the registry (for
   example, "AT-0", "US-0", "US-1" or "other-0").

6.1.2.  Registration Template

   For registration of address considerations documents in the registry,
   requestors SHOULD use the following template.  The template SHOULD be
   contained in the considerations document itself.

              <record>
                <country> <!-- Country-Code --> </country>
                <serial> <!-- assigned by IANA --> </serial>

                <reference>
                  <!-- URI to the considerations document -->
                </reference>

                <requesters>
                  <!-- Change accordingly -->
                  <xref type="person" data="John_Doe"/>
                  <xref type="person" data="Jane_Dale"/>
                </requesters>

                <status> <!-- assigned by IANA --> </status>
              </record>

             <people>
               <person id="John_Doe">
                 <name> <!-- Firstname Lastname --> </name>
                 <org> <!-- Organisation Name --> </org>
                 <uri> <!-- mailto: or http: URI --> </uri>
                 <updated> <!-- date format YYYY-MM-DD --> </updated>
               </person>
               <!-- repeat person section for each person -->
             </people>

Wolf & Mayrhofer        Expires January 10, 2010               [Page 15]
Internet-Draft        Civic Address Considerations             July 2009

6.1.3.  Registry Location

   Approved registrations are published in the IANA registry named
   "PIDF-LO Civic Address Consideration Registry", which is available at
   the following URI: XXX ((TO BE DEFINED BY IANA)).

   Registrations are sorted by ascending order by the country code, and
   by serial number within country code values.  Registrations with
   country code of "other" are put at the end of the list.

6.1.4.  Registration Procedure

   Following the policies outlined in [RFC5226], new address
   considerations are added to the registry after Expert Review (see
   Section 4.1 in RFC 5226).  The Expert will generally check if the
   submitted address considerations conforms the civic address
   guidelines in this document (see Section 4).  If in doubt, the
   Experts SHOULD consult the GEOPRIV mailing list or it's dedicated
   successor.  If possible, the Experts SHOULD check the available
   documentation on which the address consideration is based.

6.2.  Registration Request for Austria

   This document requests registration of the Civic Address
   Considerations for addresses from the official Austrian Building and
   Habitation registry, according to the registration procedure
   described above.  The required information is contained in Appendix
   A.

6.3.  Registration of the considerations in RFC 4776 as obsolete

   Since this document updates RFC 4776, the considerations on the sub-
   division elements in Section 3.4 of RFC 4776 for Canada, Germany,
   Japan, Korea and the United States are obsolete.  The following IANA
   registration records register them in the IANA Registry as obsolete.

   Canada:

Wolf & Mayrhofer        Expires January 10, 2010               [Page 16]
Internet-Draft        Civic Address Considerations             July 2009

              <record>
                <country>CA</country>
                <serial> <!-- assigned by IANA --> </serial>
                <reference>urn:ietf:rfc:4776</reference>
                <requesters>
                  <xref type="person" data="Henning_Schulzrinne"/>
                </requesters>
                <status>obsolete</status>
              </record>

             <people>
               <person id="Henning_Schulzrinne">
                 <name>Henning Schulzrinne</name>
                 <org>Columbia University</org>
                 <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
                 <updated>2009-01-09</updated>
               </person>
             </people>

   Germany:

              <record>
                <country>DE</country>
                <serial> <!-- assigned by IANA --> </serial>
                <reference>urn:ietf:rfc:4776</reference>
                <requesters>
                  <xref type="person" data="Henning_Schulzrinne"/>
                </requesters>
                <status>obsolete</status>
              </record>

             <people>
               <person id="Henning_Schulzrinne">
                 <name>Henning Schulzrinne</name>
                 <org>Columbia University</org>
                 <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
                 <updated>2009-01-09</updated>
               </person>
             </people>

   Japan:

Wolf & Mayrhofer        Expires January 10, 2010               [Page 17]
Internet-Draft        Civic Address Considerations             July 2009

              <record>
                <country>JP</country>
                <serial> <!-- assigned by IANA --> </serial>
                <reference>urn:ietf:rfc:4776</reference>
                <requesters>
                  <xref type="person" data="Henning_Schulzrinne"/>
                </requesters>
                <status>obsolete</status>
              </record>

             <people>
               <person id="Henning_Schulzrinne">
                 <name>Henning Schulzrinne</name>
                 <org>Columbia University</org>
                 <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
                 <updated>2009-01-09</updated>
               </person>
             </people>

   Korea:

              <record>
                <country>KR</country>
                <serial> <!-- assigned by IANA --> </serial>
                <reference>urn:ietf:rfc:4776</reference>
                <requesters>
                  <xref type="person" data="Henning_Schulzrinne"/>
                </requesters>
                <status>obsolete</status>
              </record>

             <people>
               <person id="Henning_Schulzrinne">
                 <name>Henning Schulzrinne</name>
                 <org>Columbia University</org>
                 <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
                 <updated>2009-01-09</updated>
               </person>
             </people>

   United States:

Wolf & Mayrhofer        Expires January 10, 2010               [Page 18]
Internet-Draft        Civic Address Considerations             July 2009

              <record>
                <country>US</country>
                <serial> <!-- assigned by IANA --> </serial>
                <reference>urn:ietf:rfc:4776</reference>
                <requesters>
                  <xref type="person" data="Henning_Schulzrinne"/>
                </requesters>
                <status>obsolete</status>
              </record>

             <people>
               <person id="Henning_Schulzrinne">
                 <name>Henning Schulzrinne</name>
                 <org>Columbia University</org>
                 <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
                 <updated>2009-01-09</updated>
               </person>
             </people>

7.  Acknowledgements

   The authors would like to thank Martin Thomson and Richard Barnes for
   reviewing the document, and Gregor Jaenin for contributing insights
   into the Austrian civic address data format.

Appendix A.  Civic Address Considerations Registration for the Austrian
             building and habitation registry

   The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and
   habitation registry law) is the legal basis for the obligation to
   provide a registry of civic addresses, buildings and their usable
   units (subdivisions of buildings).  The registry is operated by
   "Statistik Austria GmbH", a fully governmental owned company.
   Responsibility for keeping records in the registry up to date is an
   obligation to the local administration of the individual townships.

   The data format definition for the individual records is publicly
   available (data access itself is however restricted).  Hence, a
   uniform address data base for the whole Austria is available.  A
   detailed description of the Statistik Austria civic address data
   format is contained in section Appendix A.1.

Wolf & Mayrhofer        Expires January 10, 2010               [Page 19]
Internet-Draft        Civic Address Considerations             July 2009

A.1.  Civic Address Format in Austria

   Statistik Austria data describes estates, buildings and usable units
   [refs.merkmalskatalog].  On a single estate there may be any number
   of buildings.  Apartment houses that have more than one staircase,
   are split up in separate buildings at every staircase.  In every
   building, there may be several usable units.  For example, an
   apartment house may have several apartments, counting as separate
   usable units.  Moreover, one building may have more than one address,
   but at least one address.  Below, the address Fields for estates
   (Table 1), buildings (Table 2) and usable units (Table 3) are shown.

   The ADDCODE, A5 and PCN Elements are optional, and the other Elements
   MUST be used if the data source contains their corresponding Fields.
   The Elements A1 and A2 (not listed in the tables) SHOULD also be used
   if data is available.  Exception: when using the address codes only
   (access to the codes is necessary for creator and receiver of the
   location information), just the ADDCODE and country Elements are
   mandatory, the other Elements can be used optionally of course.

Wolf & Mayrhofer        Expires January 10, 2010               [Page 20]
Internet-Draft        Civic Address Considerations             July 2009

   +-------------------------+-------------------------------+---------+
   |  Statistik Austria name |          Explanation          | PIDF-LO |
   |                         |                               | Element |
   +-------------------------+-------------------------------+---------+
   |        Adresscode       |       address identifier      | ADDCODE |
   |                         |                               |         |
   |      Gemeindename,      |  commune name and identifier  |    A3   |
   |    Gemeindekennziffer   |                               |         |
   |                         |                               |         |
   |     Ortschaftsname,     |  village name and identifier  |    A4   |
   |   Ortschaftskennziffer  |                               |         |
   |                         |                               |         |
   |      Strassenname,      |   street name and identifier  |    RD   |
   |    Strassenkennziffer   |                               |         |
   |                         |                               |         |
   |  Katastralgemeindename, |   cadastral municipality and  |    A5   |
   | Katastralgemeindenummer |           identifier          |         |
   |                         |                               |         |
   |     Hausnummerntext     |   text in front of the house  |   HNO   |
   |                         |             number            |         |
   |                         |                               |         |
   | Hausnummer - 1.  Teil - |    first part of the house    |   HNO   |
   |          Nummer         |        number, numeric        |         |
   |                         |                               |         |
   | Hausnummer - 1.  Teil - |    first part of the house    |   HNO   |
   |        Buchstabe        |       number, character       |         |
   |                         |                               |         |
   |       Hausnummer -      |  links first and Bis part of  |   HNO   |
   | Verbindungszeichen Teil |          house number         |         |
   |         1 -> Bis        |                               |         |
   |                         |                               |         |
   | Hausnummer - Bis-Nummer |  number of bis part of house  |   HNO   |
   |                         |             number            |         |
   |                         |                               |         |
   |       Hausnummer -      |    character of bis part of   |   HNO   |
   |      Bis-Buchstabe      |          house number         |         |
   |                         |                               |         |
   |    Hausnummernbereich   |     indicates if all house    |   HNO   |
   |                         | numbers specified or just odd |         |
   |                         |   or even numbers are stated  |         |
   |                         |                               |         |
   |       Postleitzahl      |          postal code          |    PC   |
   |                         |                               |         |
   |   Postleitzahlengebiet  |     postal community code     |   PCN   |
   |                         |                               |         |
   |        Vulgoname        |           local name          |   NAM   |
   |                         |                               |         |

Wolf & Mayrhofer        Expires January 10, 2010               [Page 21]
Internet-Draft        Civic Address Considerations             July 2009

   |         Hofname         |           farm name           |   LMK   |
   +-------------------------+-------------------------------+---------+

                 Table 1: Civic Address Fields for Estates

   +------------------------+--------------------------------+---------+
   | Statistik Austria name |           Explanation          | PIDF-LO |
   |                        |                                | Element |
   +------------------------+--------------------------------+---------+
   |      Adresssubcode     |         address subcode        | ADDCODE |
   |                        |                                |         |
   |      Objektnummer      |           object code          | ADDCODE |
   |                        |                                |         |
   |      Hausnummer -      |  links Bis and second part of  |   HNO   |
   |   Verbindungszeichen   |          house number          |         |
   |   Teil Bis -> Teil 2   |                                |         |
   |                        |                                |         |
   |  Hausnummer - 2.  Teil |    second part of the house    |   HNO   |
   |        - Nummer        |         number, numeric        |         |
   |                        |                                |         |
   |  Hausnummer - 2.  Teil |    second part of the house    |   HNO   |
   |       - Buchstabe      |        number, character       |         |
   |                        |                                |         |
   |      Hausnummer -      | links second and third part of |   HNO   |
   |   Verbindungszeichen   |          house number          |         |
   |     Teil 2-> Teil 3    |                                |         |
   |                        |                                |         |
   |  Hausnummer - 3.  Teil |     third part of the house    |   HNO   |
   |        - Nummer        |         number, numeric        |         |
   |                        |                                |         |
   |  Hausnummer - 3.  Teil |     third part of the house    |   HNO   |
   |       - Buchstabe      |        number, character       |         |
   |                        |                                |         |
   | Gebaeudeunterscheidung |     for differentiation of     |   HNO   |
   |                        |  buildings, e.g.  Maierweg 27  |         |
   |                        |      Hotel vs. Maierweg 27     |         |
   |                        |         Appartmenthaus         |         |
   |                        |                                |         |
   +------------------------+--------------------------------+---------+

          Table 2: Additional Civic Address Fields for Buildings

Wolf & Mayrhofer        Expires January 10, 2010               [Page 22]
Internet-Draft        Civic Address Considerations             July 2009

   +-----------------------------+---------------------------+---------+
   |    Statistik Austria name   |        Explanation        | PIDF-LO |
   |                             |                           | Element |
   +-----------------------------+---------------------------+---------+
   | Nutzungseinheitenlaufnummer |      usable unit code     | ADDCODE |
   |                             |                           |         |
   |          Tuernummer         |        door number        |   HNO   |
   |                             |                           |         |
   |          Topnummer          |        unit number        |   HNO   |
   |                             |                           |         |
   |       Lagebeschreibung      |   for verbal description  |   HNO   |
   |                             |                           |         |
   |             Lage            |  describes if the usable  |   FLR   |
   |                             |  unit is in the basement, |         |
   |                             |  mezzanine, attic floor,  |         |
   |                             |   ... (but not the floor  |         |
   |                             |          number)          |         |
   |                             |                           |         |
   |          Stockwerk          |           floor           |   FLR   |
   |                             |                           |         |
   +-----------------------------+---------------------------+---------+

         Table 3: Additional Civic Address Fields for usable units

   Note: "Floors" in Austria (as in most parts of Europe) are counted
   differently compared to the US.  The "1st floor" in Austria is
   actually the floor above the floor at street level (2nd floor in US),
   not considering the fact that in old buildings there might be even
   more floors between street level and 1st floor, like "mezzanine",
   "2nd mezzanine".  So, an Austrian "1st floor" could well be the "4th
   floor" according to US nomenclature.

   According to Statistik Austria [refs.adrwarten], 81.5% of Austrian
   addresses are of the simple type Musterstrasse 1 (Musterstrasse is an
   example street name). 5% of all addresses have an additional
   character, like Musterstrasse 1b. 1% of Austrian addresses look like
   Musterstrasse 21A - 23A. For 8% of addresses, an additional separator
   is necessary, like Musterstrasse 10 Haus 1 Stiege 2 or Musterstrasse
   20 Gruppe A Reihe 1 Parzelle 13 or Musterstrasse 30 Weg 1 Parzelle
   10.  Very seldom, there are so called special addresses (0.03%), for
   example Musterstrasse gegenueber 3A, meaning this address is actually
   opposite of house number 3A. Rather surprisingly, 4.47% of Austrian
   addresses contain the identifier of the estate since no house number
   is assigned at all, for example: Musterstrasse GNR 1234, or
   Musterstrasse GNR .12/4 Kirche (this type of addresses is common for
   churches) or a real example in Stockerau: Kolomaniwoerth GNR 1583.
   This identifier is stored by Statistik Austria as Hausnummerntext.
   Otherwise one could misinterpret this number as a house number, what

Wolf & Mayrhofer        Expires January 10, 2010               [Page 23]
Internet-Draft        Civic Address Considerations             July 2009

   would be definitely wrong.

A.2.  Sample Addresses

   In order to clarify the Austrian civic address format, this section
   provides some exemplary addresses:

   1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1
   Postleitzahl: 1234
   Stadt: Musterstadt
   Strasse: Hauptstrasse
   Hausnummer - 1.  Teil - Nummer: 1
   Hausnummer - 1.  Teil - Buchstabe: a
   Hausnummer - Verbindungszeichen Teil 1 -> Bis: -
   Hausnummer - 2.  Teil - Nummer: 5
   Hausnummer - 2.  Teil - Buchstabe: a
   Hausnummer - Verbindungszeichen Teil Bis -> Teil 2: Block
   Hausnummer - 2.  Teil - Nummer: 1
   Hausnummer - 2.  Teil - Buchstabe: b
   Hausnummer - Verbindungszeichen Teil 2-> Teil 3: Haus
   Hausnummer - 3.  Teil - Nummer: 2
   Hausnummer - 3.  Teil - Buchstabe: c
   Gebaeudeunterscheidung: Stiege 1

   1234 Musterstadt, Musterstrasse 13 Hotel
   Postleitzahl: 1234
   Stadt: Musterstadt
   Strasse: Musterstrasse
   Hausnummer - 1. Teil - Nummer: 13
   Gebaeudeunterscheidung: Hotel

   6020 Innsbruck, Anichstrasse vor 35
   Postleitzahl: 6020
   Stadt: Innsbruck
   Strasse: Anichstrasse
   Hausnummerntext: vor ("in front of")
   Hausnummer: 35

   6173 Oberperfuss, Riedl 3097 (Pfarrkirche)
   Postleitzahl: 6173
   Stadt: Oberperfuss
   Strasse: Riedl
   Hausnummerntext: 3097
   (since the estate identifier is 81305 3097 where 81305 is the
   Katastralgemeindenummer (cadastral municipality) and no house
   number is assigned)
   Vulgoname: Pfarrkirche

Wolf & Mayrhofer        Expires January 10, 2010               [Page 24]
Internet-Draft        Civic Address Considerations             July 2009

A.3.  Address Codes in Austria

   Statistik Austria registers 4 codes: Adresscode, Adresssubcode,
   Objektnummer and the Nutzungseinheitenlaufnummer.  The Adresscode (7
   digits) is a unique code for an address in Austria.  The
   Adressregister maps the Adresscode to the civic address.  If there is
   a building located at an address, there is also an Adresssubcode (3
   digits) assigned.  Every building at an address has its own
   Adresssubcode (assigned sequentially starting with 001, 002, 003 and
   so on) in order to distinguish between buildings at the same address.
   Furthermore, every building located in Austria has its own unique
   code, the Objektnummer (7 digits).  This code identifies the building
   independent of the Adresscode.  That's because addresses are subject
   to change while the building may persist.  To differ multiple usable
   units inside a building, the Nutzungseinheitenlaufnummer (4 digits)
   is used.  This code is also assigned in sequential order for each
   building.

   Besides, every address and building is geocoded by Statistik Austria.
   Hence, if every PIDF-LO location object would carry data in the
   format of Statistik Austria and every PSAP would use the database of
   Statistik Austria for mapping, a time saving, definite mapping
   without irregularities could be achieved.

   Besides these codes, Statistik Austria maintains reference numbers
   for communes, localities or streets, to mention just a few.

A.4.  Austrian Addresses in PIDF-LO

   The following subsections define the mapping procedure.

A.4.1.  Country

   The country element for Austria must be set to AT, since this is the
   ISO 3166-1 [refs.ISO3166-1] alpha-2 code for Austria.

   <country>AT</country>

   The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119] and
   RFC 5139 [RFC5139] proposes to use upper case characters only.

A.4.2.  Country Subdivisions A1-A6

Wolf & Mayrhofer        Expires January 10, 2010               [Page 25]
Internet-Draft        Civic Address Considerations             July 2009

   A1 province (Bundesland), Section A.4.2.1
   A2 political district name or identifier (politischer Bezirk),
      Section A.4.2.2
   A3 commune name or identifier (Gemeinde), Section A.4.2.3
   A4 village name or identifier (Ortschaft), Section A.4.2.4
   A5 cadastral municipality name or identifier (Katastralgemeindename
      or Katastralgemeindenummer), Section A.4.2.5

   Element A6 must not be used.

   Last, there is an exception to mention concerning the Austrian
   capital Vienna (Wien).  The city of Vienna is equal to its political
   district and even the province is called Vienna.  Nevertheless,
   Vienna is separated in 23 districts within the same political
   district.  Consequently, an address in Vienna would look like:

   <country>AT</country>
   <A1>Wien</A1>
   <A2>Wien</A2>
   <A3>Wien</A3>
   <A4>Favoriten</A4> or <A4>10<A4>
   <A5>Inzersdorf Stadt<A5>

   The element A4, holding the city division, can hold the name or the
   number of the district.

A.4.2.1.  A1 Element

   As proposed in RFC 5139 [RFC5139], for the PIDF-LO element A1, the
   second part of ISO 3166-2 [refs.ISO3166-2] can be used.  However, in
   Austria it is also common to write out the names of the states.
   Table 4 shows the possible values of the A1 element for Austrian
   states.

Wolf & Mayrhofer        Expires January 10, 2010               [Page 26]
Internet-Draft        Civic Address Considerations             July 2009

        +------------------------+--------------------------------+
        |       Bundesland       | second part of ISO 3166-2 code |
        +------------------------+--------------------------------+
        |       Burgenland       |                1               |
        |                        |                                |
        |      K=U+00E4rnten     |                2               |
        |                        |                                |
        | Nieder=U+00F6sterreich |                3               |
        |                        |                                |
        |  Ober=U+00F6sterreich  |                4               |
        |                        |                                |
        |        Salzburg        |                5               |
        |                        |                                |
        |       Steiermark       |                6               |
        |                        |                                |
        |          Tirol         |                7               |
        |                        |                                |
        |       Vorarlberg       |                8               |
        |                        |                                |
        |          Wien          |                9               |
        +------------------------+--------------------------------+

     Table 4: A1 element format for Austria (Note: values are shown in
            UTF-8, which is recommended to be used for PIDF-LO)

A.4.2.2.  A2 Element

   Names of the Austrian political districts are available at Statistik
   Austria [refs.bezirke].  These names, the unique code for the
   political district or both can be used for the A2 element.  If the
   content of the A2 element is numeric, obviously the code is provieded
   (there is no political district in Austria with a number in its
   name).  In case both, the name and the code are provided, they are
   separated by a semicolon, and the name must be listed first.

   The district of "Bruck an der Leitha" could be represented by:

   <A2>Bruck an der Leitha<A2> or <A2>307</A2> or
   <A2>Bruck an der Leitha;307</A2>

A.4.2.3.  A3 Element

   The element A3 holds the Gemeindename (commune name) or the
   identifier of the Gemeinde, or both separated by a semicolon (the
   name must be listed first).  If the content of the A3 element
   consists of a number only, it is obvious that just the identifier is
   provided.  Statistik Austria maintains a table with the Gemeindenamen
   and identifiers [refs.gemeinden], which must be used as the content

Wolf & Mayrhofer        Expires January 10, 2010               [Page 27]
Internet-Draft        Civic Address Considerations             July 2009

   for the A3 element, no other spelling is allowed.

   Sample:

   <A3>Neusiedl am See</A3>
   or
   <A3>10713</A3>
   or
   <A3>Neusiedl am See;10713</A3>

A.4.2.4.  A4 Element

   The element A4 holds the Ortschaftsname (village name), the
   Ortschaftskennziffer (the identifier), or both separated by a
   semicolon (the name must be listed first).  If the content of the A4
   element consists of a number only, it is obvious that just the
   identifier is provided since there are no Ortschaftsnamen in Austria
   which contain a number.  Statistik Austria maintains a table with the
   Ortschaftsnamen and identifiers [refs.ortschaften], which must be
   used as the content for the A4 element, no other spelling is allowed.

   Sample:

   <A4>Wilfleinsdorf</A4> or <A4>03448</A4> or
   <A4>Wilfleinsdorf;03448</A4>

A.4.2.5.  A5 Element

   The element A5 holds the Katastralgemeindename (cadastral
   municipality), the Katastralgemeindenummer (the identifier), or both
   separated by a semicolon (the name must be listed first).  If the
   content of the A5 element consists of a number only, it is obvious
   that just the identifier is provided since there are no
   Katastralgemeindenamen in Austria which contain a number.

   Sample (Vienna, Fuenfhaus):

   <A5>Oberbaumgarten</A5> or <A5>1208</A5> or
   <A5>Oberbaumgarten;1208</A5>

A.4.3.  Road and Street Names

   The PIDF-LO element RD holds the complete street name, including the
   street suffix.  No abbreviations are allowed.  No other elements are
   needed for streets and must not be used.

Wolf & Mayrhofer        Expires January 10, 2010               [Page 28]
Internet-Draft        Civic Address Considerations             July 2009

A.4.4.  House Numbers

   Statistik Austria lists 14 data fields related to the house number of
   a building plus another 5 fields for distinction of different usable
   units inside a building (including the floor, which has a separate
   element in PIDF-LO).  Unfortunately, PIDF-LO only defines a single
   house number element (HNO, numeric part only) and a house number
   suffix element (HNS).  Therefore, this section defines a mapping in
   order to accommodate all data: All house number data is concatenate
   into a single HNO element, even though it is expected to hold numeric
   part only.

   In order to allow automatic procession of the HNO Element, it is
   necessary to use a semicolon as delimiter symbol (Austrian house
   numbers do not contain semicolons).  The house number parts MUST be
   provided in the order as they are listed by the Statistik Austria
   document [refs.merkmalskatalog].  For user interface representation,
   the semicolon separated format can be transformed by replacing
   semicolons by spaces (multiple spaces should be combined) and no
   space should be present between a numeric part of a house number part
   and its related character.

   It is not allowed to use the HNS element for Austrian addresses,
   since there are addresses that do not have just a single suffix.

   The house number "vor 1 - 1A" (consisting of a house number text
   "vor", first part of the house number numeric "1", "-" as the link of
   the first and Bis part, "1" as house number bis part numeric, "A" as
   character of the bis part) would be mapped to:

   <HNO>vor;1;;-;1;A;;;;;;;;;;;</HNO>

A.4.5.  Local Names

   NAM: contains the Vulgoname (local name), multiple local names are
   separated by a semicolon (if applicable)

   LMK: contains the farm name (just one name possible) (if applicable)

   LOC: can be used without restriction for additional location
   information (as per RFC 4119)

A.4.6.  Floors

   The floor element may contain numbers or text describing the floor.
   The first floor (<FLR>1</FLR>) is the floor above the floor at street
   level.  The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>.
   Other floors may have names like mezzanine, for example.  The

Wolf & Mayrhofer        Expires January 10, 2010               [Page 29]
Internet-Draft        Civic Address Considerations             July 2009

   Statistik Austria data elements Lage and Stockwerk are concatenated
   if necessary.

A.4.7.  Additional Code Element

   The element additional code may be used to hold the codes provided by
   Statistik Austria.  There is an Adresscode, Adresssubcode,
   Objektnummer and a Nutzungseinheitenlaufnummer.  These unique codes
   identify the location.  Actually, these codes alone would be enough,
   but requires that the location recipient has access to the database
   of Statistik Austria.

   If the additional code in a PIDF-LO document is going to hold the
   codes from Statistik Austria, the following format should be used:

   <ADDCODE>AdrCD=1234567;AdrsubCD=123;
   ObjNr=2333211;NtzLnr=0001</ADDCODE>

   It is not necessary to provide all codes, but there are some
   restrictions: The Adresssubcode cannot be used without an Adresscode.
   More restrictions are defined by Statistik Austria.  By setting the
   country element to AT (see Section 4.2.1), indicating an Austrian
   address, the Additional Code element is expected to hold codes from
   Statistik Austria only.  When creating PIDF-LO documents using
   address codes by Statistik Austria, the country and ADDCODE elements
   are mandatory.

A.4.8.  Other Elements

   The elements PC and PCN can hold the data form Statistik Austria, the
   POBOX can be used if the post assigned a post office box.  At least
   the PC element should be present.

   PC: Postleitzahl (postal code)

   PCN: Postleitzahlengebiet (postal community name)

   POBOX: Postfach

   The elements UNIT, ROOM, SEAT, PLC and BLD may be used without
   further restriction.

A.4.9.  Elements not to be used

Wolf & Mayrhofer        Expires January 10, 2010               [Page 30]
Internet-Draft        Civic Address Considerations             July 2009

   A6
   STS
   HNS
   PRD
   POD
   RDBR
   RDSUBBR
   PRM
   POM

A.5.  Example

   This section shows an example mapping of an Austrian address to
   PIDF-LO.

   Address:

   Bundesland: Wien
   Politischer Bezirk: Wien
   Gemeindename: Wien
   9. Bezirk
   Strasse: Lazarettgasse
   Hausnummer - 1. Teil - Nummer: 13
   Hausnummer - 1. Teil - Buchstabe: A
   Hausnummer - Verbindungszeichen Teil 1-Bis: -
   Hausnummer - Bis-Nummer: 13
   Hausnummer - Bis-Buchstabe: C
   Postleitzahl: 1090

   PIDF-LO:

Wolf & Mayrhofer        Expires January 10, 2010               [Page 31]
Internet-Draft        Civic Address Considerations             July 2009

<?xml version="1.0" encoding="UTF-8" ?>
  <presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
     xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
     entity="pres:123@examplehost">
   <tuple id="abcd123456">
    <status>
     <gp:geopriv>
       <gp:location-info>
         <cl:civicAddress xml:lang="de">
           <cl:country>AT</cl:country>
           <cl:A1>Wien</cl:A1>
           <cl:A2>Wien</cl:A2>
           <cl:A3>Wien</cl:A3>
           <cl:A4>9</cl:A4>
           <cl:RD>Lazarettgasse</cl:RD>
           <cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</cl:HNO>
           <cl:PC>1090</cl:PC>
         </cl:civicAddress>
       </gp:location-info>
       <gp:usage-rules>
         <gp:retransmission-allowed>yes</gp:retransmission-allowed>
         <gp:retention-expiry>2009-11-10T12:00:00Z</gp:retention-expiry>
       </gp:usage-rules>
     </gp:geopriv>
    </status>
    <timestamp>2009-02-09T12:00:00Z</timestamp>
   </tuple>
  </presence>

A.6.  IANA Registration Record

Wolf & Mayrhofer        Expires January 10, 2010               [Page 32]
Internet-Draft        Civic Address Considerations             July 2009

              <record>
                <country>AT</country>
                <serial> <!-- assigned by IANA --> </serial>

                <reference>
                  <!-- RFC-Editor: the URN to this RFC / -->
                </reference>

                <requesters>
                  <xref type="person" data="Alexander_Mayrhofer"/>
                  <xref type="person" data="Karl_Heinz_Wolf"/>
                </requesters>

                <status> <!-- assigned by IANA --> </status>
              </record>

             <people>
               <person id="Alexander_Mayrhofer">
                 <name>Alexander Mayrhofer</name>
                 <org>nic.at GmbH</org>
                 <uri>mailto:alexander.mayrhofer@nic.at</uri>
                 <updated>2009-01-09</updated>
               </person>
               <person id="Karl_Heinz_Wolf">
                 <name>Karl Heinz Wolf</name>
                 <org>nic.at GmbH</org>
                 <uri>mailto:karlheinz.wolf@nic.at</uri>
                 <updated>2009-01-09</updated>
               </person>
             </people>

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses

Wolf & Mayrhofer        Expires January 10, 2010               [Page 33]
Internet-Draft        Civic Address Considerations             July 2009

              Configuration Information", RFC 4776, November 2006.

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC4589]  Schulzrinne, H. and H. Tschofenig, "Location Types
              Registry", RFC 4589, July 2006.

8.2.  Informative References

   [refs.adrwarten]
              Statistik Austria, "Handbuch Adress-GWR-Online Teil A
              Theoretisches Handbuch Kapitel 2 Warten von Adressen im
              Adress-GWR-Online", Jan 2005.

   [refs.merkmalskatalog]
              Statistik Austria, "Handbuch Adress-GWR-Online Teil C
              Anhang 2 Merkmalskatalog", Sept 2004.

   [refs.ISO3166-1]
              International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions - Part 1: Country codes", ISO Standard 3166-
              1:1997, 1997.

   [refs.ISO3166-2]
              International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions - Part 2: Country subdivision code", ISO
              Standard 3166-2:1998, 1998.

   [refs.bezirke]
              Statistik Austria, "Politische Bezirke, Gebietsstand
              2008", Feb 2008.

   [refs.gemeinden]
              Statistik Austria, "Gemeindeliste sortiert nach
              Gemeindekennziffer, Gebietsstand 2008", Feb 2008.

   [refs.ortschaften]
              Statistik Austria, "Gemeinden mit Ortschaften und
              Postleitzahlen, Gebietsstand 2008", Feb 2008.

Wolf & Mayrhofer        Expires January 10, 2010               [Page 34]
Internet-Draft        Civic Address Considerations             July 2009

Authors' Addresses

   Karl Heinz Wolf
   nic.at GmbH
   Karlsplatz 1/2/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 37
   Email: karlheinz.wolf@nic.at
   URI:   http://www.nic.at/

   Alexander Mayrhofer
   nic.at GmbH
   Karlsplatz 1/2/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 34
   Email: alexander.mayrhofer@nic.at
   URI:   http://www.nic.at/

Wolf & Mayrhofer        Expires January 10, 2010               [Page 35]