GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp154

Internet Engineering Task Force (IETF) K. Wolf Request for Comments: 5774 A. Mayrhofer BCP: 154 nic.at Updates: 4776 March 2010 Category: Best Current Practice ISSN: 2070-1721

             Considerations for Civic Addresses in the
    Presence Information Data Format Location Object (PIDF-LO):
              Guidelines and IANA Registry Definition

Abstract

 This document provides a guideline for creating civic address
 considerations documents for individual countries, as required by RFC
 4776.  Furthermore, this document also creates an IANA Registry
 referring to such address considerations documents and registers such
 address considerations for Austria.

Status of This Memo

 This memo documents an Internet Best Current Practice.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 BCPs is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5774.

Copyright Notice

 Copyright (c) 2010 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
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Wolf & Mayrhofer Best Current Practice [Page 1] RFC 5774 Civic Address Considerations March 2010

Table of Contents

 1. Introduction ....................................................3
 2. Terminology .....................................................4
 3. Requirements ....................................................4
 4. Specifying PIDF-LO Element Usage ................................5
    4.1. General Considerations and Workflow ........................5
    4.2. Guidelines for Individual Elements .........................7
         4.2.1. Country .............................................7
         4.2.2. Country Subdivisions A1-A6 ..........................7
         4.2.3. Road and Street Names ...............................8
         4.2.4. House Numbers .......................................8
         4.2.5. Local Names .........................................9
         4.2.6. Floors .............................................10
         4.2.7. Address Codes ......................................10
         4.2.8. Other Elements .....................................11
 5. Security Considerations ........................................12
 6. IANA Considerations ............................................12
    6.1. PIDF-LO Civic Address Considerations Registry .............12
         6.1.1. Structure ..........................................12
         6.1.2. Registration Template ..............................13
         6.1.3. Registry Location ..................................14
         6.1.4. Registration Procedure .............................14
    6.2. Registration Request for Austria ..........................14
    6.3. Registration of the Considerations in RFC 4776 as
         Obsolete ..................................................14
 7. Acknowledgements ...............................................17
 Appendix A. Civic Address Considerations Registration for
         the Austrian Building and Habitation Registry .............18
    A.1. Civic Address Format in Austria ...........................18
    A.2. Sample Addresses ..........................................22
    A.3. Address Codes in Austria ..................................23
    A.4. Austrian Addresses in PIDF-LO .............................23
         A.4.1. Country ............................................23
         A.4.2. Country Subdivisions A1-A6 .........................24
         A.4.3. Road and Street Names ..............................27
         A.4.4. House Numbers ......................................27
         A.4.5. Local Names ........................................28
         A.4.6. Floors .............................................28
         A.4.7. Additional Code Element ............................28
         A.4.8. Other Elements .....................................29
         A.4.9. Elements Not to Be Used ............................29
    A.5. Example ...................................................29
    A.6. IANA Registration Record ..................................30
 Normative References ..............................................31
 Informative References ............................................32

Wolf & Mayrhofer Best Current Practice [Page 2] RFC 5774 Civic Address Considerations March 2010

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 the
 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 and 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, the structure and format of those
 sources differ 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 recipients.
 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 defines
 neither their structure nor a way to publish them.  This memo
 provides documentation on how to create such civic address
 considerations, and IANA has created a registry to store references
 to such documents.  Furthermore, civic address considerations for
 Austria are provided in Appendix A and have been registered in the
 IANA registry.
 Section 3.4 of [RFC4776] contains some example considerations
 regarding the use of administrative subdivision Elements for Canada,
 Germany, Japan, Korea, and the United States.  This document
 registers these examples with IANA as "obsolete" (see Section 6.3).
 Section 3.4 of [RFC4776] also contains instructions on the creation
 of civic address considerations documents on page 8.  This document
 updates that section and replaces said instructions with Sections 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

Wolf & Mayrhofer Best Current Practice [Page 3] RFC 5774 Civic Address Considerations March 2010

 specifications.  An example use case of such informal usage may be
 the 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 regarding 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
    considerations 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).
 o  For any source data Field that is required or optional, at least
    one example mapping MUST be provided.

Wolf & Mayrhofer Best Current Practice [Page 4] RFC 5774 Civic Address Considerations March 2010

 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 Public Safety Answering Point (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.  The considerations document must
     list all Fields (or at least state which Fields are considered in
     the mapping and clearly state that the other Fields MUST NOT be
     used).
 3.  For each of the Fields that are required or optional, specify a
     clear mapping instruction according to the guidelines below.

Wolf & Mayrhofer Best Current Practice [Page 5] RFC 5774 Civic Address Considerations March 2010

 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 whether
     they may be used without further restriction.
 5.  Provide examples of source data and mapping results.
 Civic address Elements 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
 [W3C.REC-xml-20060816] documents, according to RFC 5139.

Wolf & Mayrhofer Best Current Practice [Page 6] RFC 5774 Civic Address Considerations March 2010

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.

4.2.1. Country

 The country Element must hold the alpha-2 codes from ISO 3166-1
 [ISO3166-1] in uppercase 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 [ISO3166-2] (see
 Section 3.4 of RFC 5139 [RFC5139]) or other values as described in
 the particular address considerations document.  Elements "A2" to
 "A6" may contain additional levels of subdivisions (see Section 2.2.1
 of RFC 4119).
 For A1, an address considerations 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 are 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

Wolf & Mayrhofer Best Current Practice [Page 7] RFC 5774 Civic Address Considerations March 2010

 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 (Sections 3.1 and 3.2 of RFC 5139
 [RFC5139]) and PRD, POD, STS (Sections 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 should
 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 the potential for confusion.
 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 Elements as described in RFC 4776.  If the structure of house
 numbers does not directly fit into those two Elements, the document

Wolf & Mayrhofer Best Current Practice [Page 8] RFC 5774 Civic Address Considerations March 2010

 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 or not abbreviations of house
 number information is valid.  If abbreviations are used, they MUST be
 clearly defined.  If house numbers consist of more than one number,
 or if multiple prefixes and suffixes may coexist, a delimiter symbol
 and 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 Fields 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, and
 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) have no address assigned, in
 which case the local name, 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, or 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 a 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 relationship
 between those two address information types and the expected behavior
 of location recipients.

Wolf & Mayrhofer Best Current Practice [Page 9] RFC 5774 Civic Address Considerations March 2010

 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).
 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"), or "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

Wolf & Mayrhofer Best Current Practice [Page 10] RFC 5774 Civic Address Considerations March 2010

 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
 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

Wolf & Mayrhofer Best Current Practice [Page 11] RFC 5774 Civic Address Considerations March 2010

 To describe the place-type or the building, the following Elements
 are available:
 o  PLC - Place-type (for allowed values, refer to the IANA registry
    defined in [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.
 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

 IANA has created the registry "PIDF-LO Civic Address Considerations
 Registry", according to the following definitions.  Furthermore, this
 document registers 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 Considerations 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
    considerations 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.

Wolf & Mayrhofer Best Current Practice [Page 12] RFC 5774 Civic Address Considerations March 2010

 o  Reference to specification: this field contains a reference to the
    considerations document.  The xref type "rfc" should be used for
    referencing to RFCs, while other documents should use the "uri"
    type.
 o  Requestor: the author of the document.
 o  Status: one of either "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", especially if there is an updated version of the
    considerations document available.  Authors of considerations
    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 identifies 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,
 requesters 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 to document -->
           <xref type="uri" data="http://www.example.org/civicaddr/"/>
           <!-- record requesters -->
           <xref type="person" data="John_Doe"/>
           <xref type="person" data="Jane_Dale"/>
           <status> <!-- assigned by IANA --> </status>
         </record>
        <people>
          <person id="John_Doe">
            <name> <!-- Firstname Lastname --> </name>
            <org> <!-- Organization 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 Best Current Practice [Page 13] RFC 5774 Civic Address Considerations March 2010

6.1.3. Registry Location

 Approved registrations are published in the IANA registry named
 "PIDF-LO Civic Address Considerations Registry", which is available
 from http://www.iana.org.
 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 conform to the civic address
 guidelines in this document (see Section 4).  If in doubt, the Expert
 SHOULD consult the GEOPRIV mailing list or its 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 registers 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
 subdivision 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.

Wolf & Mayrhofer Best Current Practice [Page 14] RFC 5774 Civic Address Considerations March 2010

 Canada:
            <record>
              <country>CA</country>
              <serial>0</serial>
              <xref type="rfc" data="rfc4776"/>
              <xref type="person" data="Henning_Schulzrinne"/>
              <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>0</serial>
              <xref type="rfc" data="rfc4776"/>
              <xref type="person" data="Henning_Schulzrinne"/>
              <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>

Wolf & Mayrhofer Best Current Practice [Page 15] RFC 5774 Civic Address Considerations March 2010

 Japan:
            <record>
              <country>JP</country>
              <serial>0</serial>
              <xref type="rfc" data="rfc4776"/>
              <xref type="person" data="Henning_Schulzrinne"/>
              <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>0</serial>
              <xref type="rfc" data="rfc4776"/>
              <xref type="person" data="Henning_Schulzrinne"/>
              <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>

Wolf & Mayrhofer Best Current Practice [Page 16] RFC 5774 Civic Address Considerations March 2010

 United States:
            <record>
              <country>US</country>
              <serial>0</serial>
              <xref type="rfc" data="rfc4776"/>
              <xref type="person" data="Henning_Schulzrinne"/>
              <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.

Wolf & Mayrhofer Best Current Practice [Page 17] RFC 5774 Civic Address Considerations March 2010

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 governmentally owned company.  The
 local administrations of individual townships are responsible for
 keeping records in the registry up to date.
 The data format definition for the individual records is publicly
 available (data access itself is, however, restricted).  Hence, a
 uniform address database for the whole of Austria is available.  A
 detailed description of the Statistik Austria civic address data
 format is contained in Appendix A.1.

A.1. Civic Address Format in Austria

 Statistik Austria data describes estates, buildings, and usable units
 [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 will have 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 the creator and
 recipient of the location information), just the ADDCODE and country
 Elements are mandatory; the other Elements can be used optionally, of
 course.

Wolf & Mayrhofer Best Current Practice [Page 18] RFC 5774 Civic Address Considerations March 2010

 +-------------------------+-------------------------------+---------+
 |  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   |
 |                         |                               |         |

Wolf & Mayrhofer Best Current Practice [Page 19] RFC 5774 Civic Address Considerations March 2010

 |        Vulgoname        |           local name          |   NAM   |
 |                         |                               |         |
 |         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 Best Current Practice [Page 20] RFC 5774 Civic Address Considerations March 2010

 +-----------------------------+---------------------------+---------+
 |    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"
 and "2nd mezzanine".  So, an Austrian "1st floor" could well be the
 "4th floor" according to US nomenclature.
 According to Statistik Austria [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:

Wolf & Mayrhofer Best Current Practice [Page 21] RFC 5774 Civic Address Considerations March 2010

 Kolomaniwoerth GNR 1583.  This identifier is stored by Statistik
 Austria as Hausnummerntext.  Otherwise, one could misinterpret this
 number as a house number, which 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

Wolf & Mayrhofer Best Current Practice [Page 22] RFC 5774 Civic Address Considerations March 2010

 Katastralgemeindenummer (cadastral municipality), and no house
 number is assigned)
 Vulgoname: Pfarrkirche

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 differentiate 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 would carry data in the format of Statistik
 Austria and if 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 [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 uppercase characters only.

Wolf & Mayrhofer Best Current Practice [Page 23] RFC 5774 Civic Address Considerations March 2010

A.4.2. Country Subdivisions A1-A6

 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 that concerns 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 [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 Best Current Practice [Page 24] RFC 5774 Civic Address Considerations March 2010

      +------------------------+--------------------------------+
      |       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 [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 provided (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>

Wolf & Mayrhofer Best Current Practice [Page 25] RFC 5774 Civic Address Considerations March 2010

A.4.2.3. A3 Element

 The Element A3 holds the Gemeindename (commune name), 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
 [gemeinden], which must be used as the content 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
 that contain a number.  Statistik Austria maintains a table with the
 Ortschaftsnamen and identifiers [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

Wolf & Mayrhofer Best Current Practice [Page 26] RFC 5774 Civic Address Considerations March 2010

 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 that 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.

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 house number suffix
 Element (HNS).  Therefore, this section defines a mapping in order to
 accommodate all data: all house number data is concatenated 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 a delimiter symbol (Austrian house
 numbers do not contain semicolons).  The house number parts MUST be
 provided in the order in which they are listed by the Statistik
 Austria document [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 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.

Wolf & Mayrhofer Best Current Practice [Page 27] RFC 5774 Civic Address Considerations March 2010

 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
 Statistik Austria data Fields 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 require 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

Wolf & Mayrhofer Best Current Practice [Page 28] RFC 5774 Civic Address Considerations March 2010

 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

 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: -

Wolf & Mayrhofer Best Current Practice [Page 29] RFC 5774 Civic Address Considerations March 2010

 Hausnummer - Bis-Nummer: 13
 Hausnummer - Bis-Buchstabe: C
 Postleitzahl: 1090
 PIDF-LO:
 <?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

     <record>
       <country>AT</country>
       <serial>0</serial>
       <!-- reference to document -->
       <xref type="rfc" data="rfc5774"/>
       <!-- record requesters -->
       <xref type="person" data="Alexander_Mayrhofer"/>
       <xref type="person" data="Karl_Heinz_Wolf"/>

Wolf & Mayrhofer Best Current Practice [Page 30] RFC 5774 Civic Address Considerations March 2010

       <status>active</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>

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.
 [RFC4589]     Schulzrinne, H. and H. Tschofenig, "Location Types
               Registry", RFC 4589, July 2006.
 [RFC4776]     Schulzrinne, H., "Dynamic Host Configuration Protocol
               (DHCPv4 and DHCPv6) Option for Civic Addresses
               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.
 [W3C.REC-xml-20060816]
               W3C, "Extensible Markup Language (XML) 1.0 (Fourth
               Edition)", Recommendation REC-xml-20060816, August
               2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.

Wolf & Mayrhofer Best Current Practice [Page 31] RFC 5774 Civic Address Considerations March 2010

Informative References

 [adrwarten]   Statistik Austria, "Handbuch Adress-GWR-Online Teil A
               Theoretisches Handbuch Kapitel 2 Warten von Adressen im
               Adress-GWR-Online", Jan 2005.
 [merkmalskatalog]
               Statistik Austria, "Handbuch Adress-GWR-Online Teil C
               Anhang 2 Merkmalskatalog", Sept 2004.
 [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.
 [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.
 [bezirke]     Statistik Austria, "Politische Bezirke, Gebietsstand
               2008", Feb 2008.
 [gemeinden]   Statistik Austria, "Gemeindeliste sortiert nach
               Gemeindekennziffer, Gebietsstand 2008", Feb 2008.
 [ortschaften] Statistik Austria, "Gemeinden mit Ortschaften und
               Postleitzahlen, Gebietsstand 2008", Feb 2008.

Wolf & Mayrhofer Best Current Practice [Page 32] RFC 5774 Civic Address Considerations March 2010

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 Best Current Practice [Page 33]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp154.txt · Last modified: 2010/03/03 23:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki