draft-ietf-geopriv-civic-address-recommendations-03.txt   rfc5774.txt 
GEOPRIV K. Wolf Internet Engineering Task Force (IETF) K. Wolf
Internet-Draft A. Mayrhofer Request for Comments: 5774 A. Mayrhofer
Updates: 4776 (if approved) nic.at BCP: 154 nic.at
Intended status: BCP July 9, 2009 Updates: 4776 March 2010
Expires: January 10, 2010 Category: Best Current Practice
ISSN: 2070-1721
Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA
Registry Definition
draft-ietf-geopriv-civic-address-recommendations-03
Status of this Memo Considerations for Civic Addresses in the
Presence Information Data Format Location Object (PIDF-LO):
Guidelines and IANA Registry Definition
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document provides a guideline for creating civic address
Task Force (IETF), its areas, and its working groups. Note that considerations documents for individual countries, as required by RFC
other groups may also distribute working documents as Internet- 4776. Furthermore, this document also creates an IANA Registry
Drafts. referring to such address considerations documents and registers such
address considerations for Austria.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This memo documents an Internet Best Current Practice.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (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.
This Internet-Draft will expire on January 10, 2010. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document provides a guideline for creating civic address described in the Simplified BSD License.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................3
2. Terminology .....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements ....................................................4
4. Specifying PIDF-LO Element Usage ................................5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General Considerations and Workflow ........................5
4.2. Guidelines for Individual Elements .........................7
4. Specifying PIDF-LO Element Usage . . . . . . . . . . . . . . . 7 4.2.1. Country .............................................7
4.1. General Considerations and Workflow . . . . . . . . . . . 7 4.2.2. Country Subdivisions A1-A6 ..........................7
4.2. Guidelines for Individual Elements . . . . . . . . . . . . 8 4.2.3. Road and Street Names ...............................8
4.2.1. Country . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.4. House Numbers .......................................8
4.2.2. Country Subdivisions A1-A6 . . . . . . . . . . . . . . 9 4.2.5. Local Names .........................................9
4.2.3. Road and Street Names . . . . . . . . . . . . . . . . 9 4.2.6. Floors .............................................10
4.2.4. House Numbers . . . . . . . . . . . . . . . . . . . . 10 4.2.7. Address Codes ......................................10
4.2.5. Local Names . . . . . . . . . . . . . . . . . . . . . 11 4.2.8. Other Elements .....................................11
4.2.6. Floors . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations ........................................12
4.2.7. Address Codes . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations ............................................12
4.2.8. Other Elements . . . . . . . . . . . . . . . . . . . . 13 6.1. PIDF-LO Civic Address Considerations Registry .............12
6.1.1. Structure ..........................................12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6.1.2. Registration Template ..............................13
6.1.3. Registry Location ..................................14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1.4. Registration Procedure .............................14
6.1. PIDF-LO Civic Address Consideration Registry . . . . . . . 14 6.2. Registration Request for Austria ..........................14
6.1.1. Structure . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Registration of the Considerations in RFC 4776 as
6.1.2. Registration Template . . . . . . . . . . . . . . . . 15 Obsolete ..................................................14
6.1.3. Registry Location . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements ...............................................17
6.1.4. Registration Procedure . . . . . . . . . . . . . . . . 16 Appendix A. Civic Address Considerations Registration for
6.2. Registration Request for Austria . . . . . . . . . . . . . 16 the Austrian Building and Habitation Registry .............18
6.3. Registration of the considerations in RFC 4776 as A.1. Civic Address Format in Austria ...........................18
obsolete . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Sample Addresses ..........................................22
A.3. Address Codes in Austria ..................................23
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 A.4. Austrian Addresses in PIDF-LO .............................23
A.4.1. Country ............................................23
Appendix A. Civic Address Considerations Registration for the A.4.2. Country Subdivisions A1-A6 .........................24
Austrian building and habitation registry . . . . . . 19 A.4.3. Road and Street Names ..............................27
A.1. Civic Address Format in Austria . . . . . . . . . . . . . 20 A.4.4. House Numbers ......................................27
A.2. Sample Addresses . . . . . . . . . . . . . . . . . . . . . 24 A.4.5. Local Names ........................................28
A.3. Address Codes in Austria . . . . . . . . . . . . . . . . . 25 A.4.6. Floors .............................................28
A.4. Austrian Addresses in PIDF-LO . . . . . . . . . . . . . . 25 A.4.7. Additional Code Element ............................28
A.4.1. Country . . . . . . . . . . . . . . . . . . . . . . . 25 A.4.8. Other Elements .....................................29
A.4.2. Country Subdivisions A1-A6 . . . . . . . . . . . . . . 25 A.4.9. Elements Not to Be Used ............................29
A.4.3. Road and Street Names . . . . . . . . . . . . . . . . 28 A.5. Example ...................................................29
A.4.4. House Numbers . . . . . . . . . . . . . . . . . . . . 29 A.6. IANA Registration Record ..................................30
A.4.5. Local Names . . . . . . . . . . . . . . . . . . . . . 29 Normative References ..............................................31
A.4.6. Floors . . . . . . . . . . . . . . . . . . . . . . . . 29 Informative References ............................................32
A.4.7. Additional Code Element . . . . . . . . . . . . . . . 30
A.4.8. Other Elements . . . . . . . . . . . . . . . . . . . . 30
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
1. Introduction 1. Introduction
The "Presence Information Data Format Location Object" (PIDF-LO) The Presence Information Data Format Location Object (PIDF-LO)
[RFC4119] is an object format for carrying geographical information [RFC4119] is an object format for carrying geographical information
on the Internet. PIDF-LO can contain civic address information, and on the Internet. PIDF-LO can contain civic address information and
supports a range of "civic address types" (CATypes) to hold supports a range of "civic address types" (CAtypes) to hold the
individual attributes of such addresses (see Section 2.2.1 of individual attributes of such addresses (see Section 2.2.1 of
[RFC4119] and Section 3.1 of [RFC5139]). [RFC4119] and Section 3.1 of [RFC5139]).
In many use cases, PIDF-LOs are populated with data from long- In many use cases, PIDF-LOs are populated with data from long-
established sources, like postal or governmental building registers, established sources, like postal and governmental building registers,
line information databases and yellow / white pages of infrastructure line information databases and yellow/white pages of infrastructure
providers, or official residents registers. The structure and format providers, or official residents registers. The structure and format
of data from such sources is almost always different from PIDF-LO's of data from such sources is almost always different from PIDF-LO's
CAtypes definition - additionally, structure and format of those CAtypes definition -- additionally, the structure and format of those
sources differs from country to country. sources differ from country to country.
To make use of such existing data sources, transposing that data into To make use of such existing data sources, transposing that data into
PIDF-LO format is required. With no guidelines available on how to PIDF-LO format is required. With no guidelines available on how to
map source Fields into CAtype Elements, different creators of PIDF-LO map source Fields into CAtype Elements, different creators of PIDF-LO
documents might end up with different results, even when using the documents might end up with different results, even when using the
same data source - which reduces interoperability and increases the same data source, which reduces interoperability and increases the
risk of misinterpretation by receivers. risk of misinterpretation by recipients.
Therefore, civic address considerations are necessary to ensure Therefore, civic address considerations are necessary to ensure
uniform usage of PIDF-LO Elements for such data sources. [RFC4776] uniform usage of PIDF-LO Elements for such data sources. [RFC4776]
explicitly requests such documents to be provided, but does neither explicitly requests such documents to be provided, but defines
define their structure nor a way to publish them. This memo provides neither their structure nor a way to publish them. This memo
documentation on how to create such civic address considerations, and provides documentation on how to create such civic address
requests the creation of an IANA Registry to store references to such considerations, and IANA has created a registry to store references
documents. Furthermore, a civic address consideration for Austria is to such documents. Furthermore, civic address considerations for
provided in Appendix A to be registered in the IANA Registry. Austria are provided in Appendix A and have been registered in the
IANA registry.
Section 3.4 of [RFC4776] contains some example considerations Section 3.4 of [RFC4776] contains some example considerations
regarding the use of administrative sub-division elements for Canada, regarding the use of administrative subdivision Elements for Canada,
Germany, Japan, Korea and the United States. This document IANA Germany, Japan, Korea, and the United States. This document
registers these examples as "obsolete" (see Section 6.3). registers these examples with IANA as "obsolete" (see Section 6.3).
Section 3.4 of [RFC4776] also contains instructions on the creation Section 3.4 of [RFC4776] also contains instructions on the creation
of Civic Address Consideration documents on page 8. This document of civic address considerations documents on page 8. This document
updates this section, and replaces said instructions with Section 4 updates that section and replaces said instructions with Sections 4
and 5 of this memo. and 5 of this memo.
The guidelines in this document have been created with a focus on The guidelines in this document have been created with a focus on
formal application of PIDF-LO (such as conveying location during an formal application of PIDF-LO (such as conveying location during an
emergency call). It is not intended to forbid other, more informal emergency call). It is not intended to forbid other, more informal
uses of PIDF-LO that may not follow any formal mapping uses of PIDF-LO that may not follow any formal mapping
specifications. An example usecase of such informal usage may be the specifications. An example use case of such informal usage may be
transmission of PIDF-LO documents during an instant messaging session the transmission of PIDF-LO documents during an instant-messaging
between humans. Such use may, however, imply some drawbacks like session between humans. Such use may, however, imply some drawbacks,
prohibiting automatic processing of civic addresses from such a like prohibiting automatic processing of civic addresses from such a
PIDF-LO. PIDF-LO.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition, this document uses "Field" to refer to a field of a 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 civic address data source, and "Element" to refer to a CAtype Element
of a PIDF-LO. of a PIDF-LO.
3. Requirements 3. Requirements
The following requirements apply to defining civic address mapping The following requirements apply to defining civic-address mapping
considerations: considerations:
o The considerations document MUST identify the data source to which o The considerations document MUST identify the data source to which
the definitions apply. A brief description of its structure the definitions apply. A brief description of its structure
SHOULD be provided as well. SHOULD be provided as well.
o For any data source, just one active mapping definition should o For any data source, just one active mapping definition should
exist in order to reduce the risk of ambiguous interpretation. exist in order to reduce the risk of ambiguous interpretation.
o The document MUST include instructions for any Field that occurs o The document MUST include instructions for any Field that occurs
in the data. For any of the Fields, the document MUST describe in the data. For any of the Fields, the document MUST describe
whether the Field is required, optional, or must not be used in whether the Field is required, optional, or must not be used in
the mapping procedure. the mapping procedure.
o Instructions MUST be included for any CAtype Element that is o Instructions MUST be included for any CAtype Element that is
registered by the time the document is created. Those registered by the time the document is created. Those
instructions MUST include information whether an Element is instructions MUST include information regarding whether an Element
required, optional, or must not be used in that mapping. In case is required, optional, or must not be used in that mapping. In
the set of CAtypes is revised by the IETF, the address case the set of CAtypes is revised by the IETF, the address
consideration document SHOULD be updated. Until an update is considerations document SHOULD be updated. Until an update is
approved, the existing mapping procedure MUST be used. approved, the existing mapping procedure MUST be used.
o Address mapping procedures SHOULD be reversible, so that location o Address mapping procedures SHOULD be reversible so that location
recipients can identify the corresponding record in the original recipients can identify the corresponding record in the original
data source (given they have access to that source). data source (given they have access to that source).
o For any source data Field that is required or optional, at least o For any source data Field that is required or optional, at least
one example mapping MUST be provided. one example mapping MUST be provided.
o In many cases, data sources used in the mapping process might be o In many cases, data sources used in the mapping process might be
subject to access restrictions. Such restrictions (as imposed on subject to access restrictions. Such restrictions (as imposed on
the original data) MUST also be imposed on the resulting PIDF-LO the original data) MUST also be imposed on the resulting PIDF-LO
documents. The considerations document SHOULD note such documents. The considerations document SHOULD note such
restrictions in its Security Considerations section. restrictions in its Security Considerations section.
Although the mapping is defined in a national way and the actual 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, 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 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 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. to a Public Safety Answering Point (PSAP) in the same country as the
However, in a border region there might be exceptions and the PIDF-LO location generator anyway. However, in a border region there might
could be sent to a neighboring country. The PIDF-LO can still be be exceptions and the PIDF-LO could be sent to a neighboring country.
passed on to a PSAP in the right country (based on the country The PIDF-LO can still be passed on to a PSAP in the right country
element), or the PSAP might be aware of the mapping scheme used in (based on the country Element), or the PSAP might be aware of the
the neighboring country. mapping scheme used in the neighboring country.
A consistent mapping is also very important for checking if two A consistent mapping is also very important for checking if two PIDF-
PIDF-LO documents describe the same location. When civic address LO documents describe the same location. When civic address Fields
Fields are put into different PIDF-LO Elements, it may be difficult are put into different PIDF-LO Elements, it may be difficult to
to identify whether or not two PIDF-LOs describe identical addresses. identify whether or not two PIDF-LOs describe identical addresses.
4. Specifying PIDF-LO Element Usage 4. Specifying PIDF-LO Element Usage
The purpose of the civic address considerations for an individual The purpose of the civic address considerations for an individual
data source is to create interoperability by specifying a common list data source is to create interoperability by specifying a common list
of PIDF-LO Elements to be used, and by defining the mapping between of PIDF-LO Elements to be used and by defining the mapping between
these Elements and the Fields of the respective data source. these Elements and the Fields of the respective data source.
4.1. General Considerations and Workflow 4.1. General Considerations and Workflow
The workflow for creating an address considerations document is as The workflow for creating an address considerations document is as
follows: follows:
1. Describe the data source to which the address considerations 1. Describe the data source to which the address considerations
document applies. 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).
3. For each of the Fields that is required or optional, specify a 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. 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 4. Provide a list of all CAtypes registered and describe their level
Fields above and clearly list which Elements are not used for the 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 mapping procedure). For Elements that are not described in
detail state whether they MUST NOT be used at all or they may be detail, state whether they MUST NOT be used at all or whether
used without further restriction. 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 5. Provide examples of source data and mapping results.
cases, Fields clearly correspond to such a container; however, in
some other cases, identifying the correct container might require 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) some approximation. For example, in some countries the RD (road)
Element might also be appropriate for other thoroughfares, like Element might also be appropriate for other thoroughfares, like
waterways or tunnels. waterways or tunnels.
Fields that are identified to have the same meaning as one of the Fields that are identified to have the same meaning as one of the
CAtypes SHOULD be directly mapped to that CAtype Element. CAtypes SHOULD be directly mapped to that CAtype Element.
Where CAtype usage diverges from the original specification, the Where CAtype usage diverges from the original specification, the
mapping definition of Fields that are mapped to that Element SHOULD mapping definition of Fields that are mapped to that Element SHOULD
include a discussion of the differences. include a discussion of the differences.
Fields that do not fit into an existing CAtype: Even though the list Fields that do not fit into an existing CAtype:
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 Even though the list of CAtypes could be extended, it is not
element (define delimiters if applicable and make sure the feasible to add new Elements for every new Field in every data
separate civic address parts can be retrieved again) source in every country. Therefore, unless new generic CAtypes
2. Use a PIDF-LO element that is unused so far are specified by the IETF, only existing Elements can be used,
which leaves the following options:
Note: Obviously, the first option is required if the number of Fields 1. Concatenate several civic address Fields into a single PIDF-LO
that are used in the mapping procedure is greater than the number of Element (define delimiters if applicable and make sure the
existing CAtype Elements. 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 Note that the xml:lang attribute should be present in PIDF-LO XML
documents according to RFC 5139. [W3C.REC-xml-20060816] documents, according to RFC 5139.
4.2. Guidelines for Individual Elements 4.2. Guidelines for Individual Elements
The following sections discuss individual PIDF-LO Elements and The following sections discuss individual PIDF-LO Elements and
describe what to consider for each Element when defining civic describe what to consider for each Element when defining civic
address considerations. It is RECOMMENDED to follow a similar address considerations. It is RECOMMENDED to follow a similar
structure for considerations documents. structure for considerations documents.
4.2.1. Country 4.2.1. Country
The country element must hold the alpha-2 codes from ISO 3166-1 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 [ISO3166-1] in uppercase characters, as clarified in Section 3.3 of
of RFC 5139 [RFC5139]. RFC 5139 [RFC5139].
This element cannot be redefined on a national basis since it This Element cannot be redefined on a national basis since it
identifies the country itself. This element is used to identify identifies the country itself. This Element is used to identify
which national mapping for civic addresses has been used in a which national mapping for civic addresses has been used in a
specific PIDF-LO. specific PIDF-LO.
Example for Austria: <country>AT</country> Example for Austria: <country>AT</country>
4.2.2. Country Subdivisions A1-A6 4.2.2. Country Subdivisions A1-A6
The elements A1 to A6 are used to hold national subdivision The Elements A1 to A6 are used to hold national subdivision
identifiers, with A1 holding the top-level subdivision identifier. identifiers, with A1 holding the top-level subdivision identifier.
A1 may either contain the second part of ISO 3166-2 [refs.ISO3166-2] A1 may either contain the second part of ISO 3166-2 [ISO3166-2] (see
(see section 3.4 of RFC 5139 [RFC5139]), or values as described in Section 3.4 of RFC 5139 [RFC5139]) or other values as described in
the address consideration document. Elements "A2" to "A6" may the particular address considerations document. Elements "A2" to
contain additional levels of subdivisions (see section 2.2.1 of RFC "A6" may contain additional levels of subdivisions (see Section 2.2.1
4119). of RFC 4119).
For A1, an address consideration document MUST state whether ISO For A1, an address considerations document MUST state whether ISO
3166-2 codes are to be used exclusively; alternatively it should 3166-2 codes are to be used exclusively; alternatively, it should
define a list of values to be used (for example, subdivision names). 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 In either case, A1 MUST NOT be redefined for any other use than
describing top level subdivisions. describing top-level subdivisions.
For each of the A2 - A6 Elements that is required or optional, the For each of the A2 - A6 Elements that are required or optional, the
document SHOULD define the set of allowed values, either by listing document SHOULD define the set of allowed values, either by listing
them, or by referring to such a list. them or by referring to such a list.
Example for Austria: Example for Austria:
A1 province (Bundesland) A1 province (Bundesland)
A2 political district (politischer Bezirk) name or identifier A2 political district (politischer Bezirk) name or identifier
A3 commune (Gemeinde) name or identifier A3 commune (Gemeinde) name or identifier
A4 village (Ortschaft) name or identifier A4 village (Ortschaft) name or identifier
A5 cadastral municipality (Katastralgemeinde) name or identifier A5 cadastral municipality (Katastralgemeinde) name or identifier
A6 must not be used. For more details, see the example in Appendix
A6 must not be used. For more details see the example in A.4.2.
Appendix A.4.2.
4.2.3. Road and Street Names 4.2.3. Road and Street Names
PIDF-LO contains the following Elements related to road names: RD, 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 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
[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 use of the A6 Element for street names is not valid any more (Section
3.2 of RFC 5139 [RFC5139]). 3.2 of RFC 5139 [RFC5139]).
Besides the basic specification of which of those Elements are Besides the basic specification of which of those Elements are
required, optional or not to be used, an address considerations required, optional, or not to be used, an address considerations
document may also describe more complicated dependencies (for document may also describe more complicated dependencies (for
example, "RD is optional, but required if any other road name Element example, "RD is optional, but required if any other road name Element
is used"). is used").
For any required or optional element, the relation of those Elements For any required or optional Element, the relation of those Elements
to Fields of the data source used MUST be described, as well as to Fields of the data source used MUST be described, as should
special considerations (like concatenation of Fields into an Element) special considerations (like concatenation of Fields into an
if they apply. The usage of the Element STS (street suffix) SHOULD Element), if they apply. The usage of the Element STS (street
be consistent. In case no suffixes are known in a data source, or it suffix) SHOULD be consistent. In case no suffixes are known in a
is common to write the street name and the suffix together, the STS data source, or it is common to write the street name and the suffix
Element SHOULD be left out completely. If suffixes may be together, the STS Element SHOULD be left out completely. If suffixes
abbreviated the common abbreviations SHOULD be defined. may be abbreviated, the common abbreviations SHOULD be defined.
Example for Austria: Example for Austria:
RD: street name RD: street name
All other road Elements must not be used. Street suffixes are All other road Elements must not be used. Street suffixes are
already included in the "street name" Field, and must not be already included in the "street name" Field and must not be
abbreviated. abbreviated.
4.2.4. House Numbers 4.2.4. House Numbers
PIDF-LO specifies two Elements related to house numbers: HNO ("house PIDF-LO specifies two Elements related to house numbers: HNO ("house
number", numeric part only) and HNS ("house number suffix") (see number", numeric part only) and HNS ("house number suffix") (see
section 3.4 of RFC 4776). However, in many countries house numbers Section 3.4 of RFC 4776). However, in many countries house numbers
have a more complex format. In any case, a clear definition is have a more complex format. In any case, a clear definition is
REQUIRED to minimize confusion potential. REQUIRED to minimize the potential for confusion.
An address considerations document should provide the following An address considerations document should provide the following
information with regards to house numbers: If the structure of house information with regards to house numbers: if the structure of house
numbers fits the HNO/HNS structure, the document MUST mandate to use numbers fits the HNO/HNS structure, the document MUST mandate to use
those fields as described in RFC 4776. If the structure of house those Elements as described in RFC 4776. If the structure of house
numbers does not directly fit into those two Elements, the document numbers does not directly fit into those two Elements, the document
MUST define strategies on how to map source Fields into Elements. MUST define strategies on how to map source Fields into Elements.
Besides HNO and HNS, LOC and BLD could be considered for carrying Besides HNO and HNS, LOC and BLD could be considered for carrying
house number information. house number information.
The document SHOULD describe whether abbreviations of house number The document SHOULD describe whether or not abbreviations of house
information is valid or not. If abbreviations are used, they MUST be number information is valid. If abbreviations are used, they MUST be
clearly defined. If house number consists of more than one number, clearly defined. If house numbers consist of more than one number,
or multiple prefixes and suffixes may coexist, a delimiter symbol and or if multiple prefixes and suffixes may coexist, a delimiter symbol
a clear rule on how to concatenate all this data into the HNO and HNS and a clear rule on how to concatenate all this data into the HNO and
element might be necessary. Whenever concatenating data into one HNS Element might be necessary. Whenever concatenating data into one
Element, keep in mind that the location recipient might want to Element, keep in mind that the location recipient might want to
separate the data again. separate the data again.
Example from Austria: Example from Austria:
HNO: concatenate all the data elements of Austrian house numbers into HNO: concatenate all the data Fields of Austrian house numbers into
this single PIDF-LO Element in a defined order with delimiter symbols this single PIDF-LO Element in a defined order with delimiter
(see Appendix A.4.4 for the complete definition). symbols (see Appendix A.4.4 for the complete definition).
HNS: Usage not allowed since there may be multiple suffixes for the HNS: usage not allowed since there may be multiple suffixes for the
different parts of the house number. different parts of the house number.
LOC and BLD are not to be used to reflect house number information. LOC and BLD are not to be used to reflect house number information.
4.2.5. Local Names 4.2.5. Local Names
PIDF-LO contains three elements to reflect local names: LMK, LOC, NAM PIDF-LO contains three Elements to reflect local names: LMK, LOC, and
(section 3.4 of RFC 4776). Such local names may be of importance for NAM (Section 3.4 of RFC 4776). Such local names may be of importance
the identification of a location, and may either coexist with a valid for the identification of a location and may either coexist with a
civic address or (in some cases) no address may be assigned so that valid civic address or (in some cases) have no address assigned, in
the local names itself identifies the location. In rural regions for which case the local name, itself, identifies the location. In rural
example, a farm name may be more common than a street address to regions, for example, a farm name may be more common than a street
identify a location. Landmarks typically don't have any civic address to identify a location. Landmarks typically don't have any
address information assigned. Therefore, local names may assist in civic address information assigned. Therefore, local names may
finding a "street name" type address, but they might also be the assist in finding a "street name" type address, but they might also
authoritative (and only) civic location information. be the authoritative (and only) civic location information.
For any required or optional Element out of LMK, LOC, NAM the For any required or optional Element out of LMK, LOC, or NAM, the
considerations document should state potential values (source data) considerations document should state potential values (source data)
for the element. In the case that multiple values for an Element may for the Element. In the case that multiple values for an Element may
occur, a concatenation / selection strategy should be described. occur, a concatenation/selection strategy should be described.
Concatenation using ";" as separator is recommended, unless this Concatenation using ";" as a separator is recommended, unless this
character also appears in the source Fields. character also appears in the source Fields.
If local name information and "common" address information is both If local name information and "common" address information is both
available and used, the document SHOULD discuss the relation between available and used, the document SHOULD discuss the relationship
those two address information types, and expected behaviour of between those two address information types and the expected behavior
location recipients. of location recipients.
Example from Austria: Example from Austria:
NAM: contains the "Vulgoname" (local name), multiple local names are NAM: contains the "Vulgoname" (local name); multiple local names are
separated by a semicolon (if applicable) separated by a semicolon (if applicable).
LMK: contains the farm name (just one name possible) (if applicable).
LMK: contains the farm name (just one name possible) (if applicable)
LOC: can be used without restriction for additional location LOC: can be used without restriction for additional location
information (as per RFC 4119) information (as per RFC 4119).
The "Vulgoname" is useful to identify the location within its The "Vulgoname" is useful to identify the location within its
locality, since official addresses especially in rural regions might locality, since official addresses (especially in rural regions)
not be well known. might not be well known.
4.2.6. Floors 4.2.6. Floors
PIDF-LO defines the element FLR to hold floor information, but does PIDF-LO defines the Element FLR to hold floor information but does
not further specify its content. Section 2.1 of RFC 3825 provides not further specify its content. Section 2.1 of RFC 3825 provides
guidance about floor numbering, but is not directly related to guidance about floor numbering but is not directly related to PIDF-
PIDF-LO. LO.
An address considerations document SHOULD clearly specify how to An address considerations document SHOULD clearly specify how to
express floors using the FLR element. Following the above mentioned express floors using the FLR Element. Following the above-mentioned
guidance is RECOMMENDED; however, local nomenclature might require a guidance is RECOMMENDED; however, local nomenclature might require a
completely different system. The document SHOULD specify whether completely different system. The document SHOULD specify whether
only numbers, text, or both are allowed in the FLR element. If there only numbers, text, or both are allowed in the FLR Element. If there
are standard values for certain floors, they SHOULD be listed. are standard values for certain floors, they SHOULD be listed.
Abbreviations SHOULD be avoided, unless they are the primary (well Abbreviations SHOULD be avoided, unless they are the primary (well-
known) way of identifying floors. known) way of identifying floors.
Example from Austria: Example from Austria:
If floor numbers are to be mapped, the FLR Element MUST be used. 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 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 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 street level is <FLR>EG</FLR> or <FLR>0</FLR>. There might be
intermediate floors, especially between the floor at street level and intermediate floors, especially between the floor at street level and
the "first floor". Such intermediate floors have names like the "first floor". Such intermediate floors have names like
"Mezzanine", "Erster Halbstock" ("first half floor"), "Zweiter "Mezzanine", "Erster Halbstock" ("first half floor"), or "Zweiter
Halbstock" ("second half floor"), and have local meanings. Halbstock" ("second half floor"), and have local meanings.
4.2.7. Address Codes 4.2.7. Address Codes
Address codes are available in several countries in different forms Address codes are available in several countries in different forms
(for estates, buildings or usable units for example). These codes (for estates, buildings, or usable units for example). These codes
identify an address record, and MAY be placed in the ADDCODE element identify an address record and MAY be placed in the ADDCODE Element
in PIDF-LO. Address codes can help the location recipient to in PIDF-LO. Address codes can help the location recipient to
determine the location, and to identify the original record in the determine the location and to identify the original record in the
data source. Depending on the type of code, the code alone (without data source. Depending on the type of code, the code alone (without
any other Elements) may even be sufficient to fully identify an any other Elements) may even be sufficient to fully identify an
address within a country. address within a country.
In such cases, a PIDF-LO containing just the country and ADDCODE In such cases, a PIDF-LO containing just the country and ADDCODE
elements might provide enough information to retrieve a civic Elements might provide enough information to retrieve a civic
address, given the location recipient has access to the respective address, given the location recipient has access to the respective
source database. source database.
A civic address considerations document SHOULD specify whether and in A civic address considerations document SHOULD specify whether and in
which applications the use of the ADDCODE Element is allowed. If which applications the use of the ADDCODE Element is allowed. If
ADDCODE is used, its relation to the remaining Elements MUST be ADDCODE is used, its relation to the remaining Elements MUST be
clearly stated. If several namespaces for address codes exist in a clearly stated. If several namespaces for address codes exist in a
country, a mechanism to distinguish the different code spaces MUST be country, a mechanism to distinguish the different code spaces MUST be
described. described.
Examples from Austria: Examples from Austria:
Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode
(AdrsubCD), Objektnummer (ObjNr) and Nutzungseinheitenlaufnummer (AdrsubCD), Objektnummer (ObjNr), and Nutzungseinheitenlaufnummer
(NtzLnr). (NtzLnr).
The following format SHOULD be used: The following format SHOULD be used:
<ADDCODE>AdrCD=1234567;AdrsubCD=123; <ADDCODE>AdrCD=1234567;AdrsubCD=123;
ObjNr=2333211;NtzLnr=0001</ADDCODE> ObjNr=2333211;NtzLnr=0001</ADDCODE>
4.2.8. Other Elements 4.2.8. Other Elements
This section lists all PIDF-LO Elements that have not been discussed This section lists all PIDF-LO Elements that have not been discussed
skipping to change at page 13, line 42 skipping to change at page 12, line 4
o UNIT o UNIT
o ROOM o ROOM
o SEAT o SEAT
The following Elements are to be used for the representation of The following Elements are to be used for the representation of
postal codes: postal codes:
o PC o PC
o PCN o PCN
o POBOX o POBOX
To describe the place-type or the building, the following Elements To describe the place-type or the building, the following Elements
are available: are available:
o PLC - Place-type (see [RFC4589]) o PLC - Place-type (for allowed values, refer to the IANA registry
defined in [RFC4589])
o BLD - Building (structure) o BLD - Building (structure)
For any of those Elements that are required or optional in a mapping, 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 semantics of its contents must be described if it differs from
the definition in the PIDF-LO base documents. the definition in the PIDF-LO base documents.
It is RECOMMENDED that the elements SEAT, UNIT and ROOM remain to be 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 used for identifying a location inside a building. They MAY be used
by the owner of the respective building if a considerations document by the owner of the respective building if a considerations document
does not restrict their use. For example, an airport could decide to does not restrict their use. For example, an airport could decide to
place the gate number in the UNIT element, and a location recipient 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 could identify that PIDF-LO by the value of the PLC Element. The
name of the airport could be placed in NAM. name of the airport could be placed in NAM.
5. Security Considerations 5. Security Considerations
RFC 4119 contains general security considerations for handling PIDF- RFC 4119 contains general security considerations for handling PIDF-
LOs. LOs.
6. IANA Considerations 6. IANA Considerations
This document requests creation of the registry "PIDF-LO Civic IANA has created the registry "PIDF-LO Civic Address Considerations
Address Consideration Registry", according to the following Registry", according to the following definitions. Furthermore, this
definitions. Furthermore, this document requests registration of a document registers a civic address considerations document for
civic address considerations document for Austrian addresses as Austrian addresses, as provided in the Appendix of this document, and
provided in the Appendix of this document and also registers the also registers the considerations of RFC 4776 as obsolete.
considerations of RFC 4776 as obsolete.
6.1. PIDF-LO Civic Address Consideration Registry 6.1. PIDF-LO Civic Address Considerations Registry
6.1.1. Structure 6.1.1. Structure
The IANA Registry contains the following fields: The IANA registry contains the following fields:
o Country-Code: Either the ISO 3166 alpha-two code of the country to o Country-Code: either the ISO 3166 alpha-two code of the country to
which the consideration applies or "other" in case the which the consideration applies or "other" in case the
consideration document is not specific to a particular country. considerations document is not specific to a particular country.
This field is to be defined by the requestor. This field is to be defined by the requestor.
o Serial Number: A number that uniquely identifies a considerations o Serial Number: a number that uniquely identifies a considerations
document within a certain "Country-Code" field value. Serial document within a certain "Country-Code" field value. Serial
Numbers are sequentially assigned by IANA per "Country-Code" Numbers are sequentially assigned by IANA per Country-Code value,
value, start at zero, and are never reused. start at zero, and are never reused.
o Reference to specification: This field contains a reference to the o Reference to specification: this field contains a reference to the
considerations document. 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 Requestor: the author of the document.
o Status: One of "active" or "obsolete". When the document is o Status: one of either "active" or "obsolete". When the document
registered by IANA, the status is first set to "active" by IANA. is registered by IANA, the status is first set to "active" by
Experts may later request changing the status to "obsolete", IANA. Experts may later request changing the status to
especially if there is an updated version of the considerations "obsolete", especially if there is an updated version of the
document available. Authors of consideration documents must considerations document available. Authors of considerations
contact the experts if they wish to change the status of the documents must contact the experts if they wish to change the
document. status of the document.
Note: The combination of "Country-Code" and "Serial Number" fields Note: the combination of Country-Code and Serial Number fields
uniquely identify a considerations document in the registry (for uniquely identifies a considerations document in the registry (for
example, "AT-0", "US-0", "US-1" or "other-0"). example, "AT-0", "US-0", "US-1", or "other-0").
6.1.2. Registration Template 6.1.2. Registration Template
For registration of address considerations documents in the registry, For registration of address considerations documents in the registry,
requestors SHOULD use the following template. The template SHOULD be requesters SHOULD use the following template. The template SHOULD be
contained in the considerations document itself. contained in the considerations document itself.
<record> <record>
<country> <!-- Country-Code --> </country> <country> <!-- Country-Code --> </country>
<serial> <!-- assigned by IANA --> </serial> <serial> <!-- assigned by IANA --> </serial>
<reference> <!-- reference to document -->
<!-- URI to the considerations document --> <xref type="uri" data="http://www.example.org/civicaddr/"/>
</reference>
<requesters> <!-- record requesters -->
<!-- Change accordingly --> <xref type="person" data="John_Doe"/>
<xref type="person" data="John_Doe"/> <xref type="person" data="Jane_Dale"/>
<xref type="person" data="Jane_Dale"/>
</requesters>
<status> <!-- assigned by IANA --> </status> <status> <!-- assigned by IANA --> </status>
</record> </record>
<people> <people>
<person id="John_Doe"> <person id="John_Doe">
<name> <!-- Firstname Lastname --> </name> <name> <!-- Firstname Lastname --> </name>
<org> <!-- Organisation Name --> </org> <org> <!-- Organization Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri> <uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated> <updated> <!-- date format YYYY-MM-DD --> </updated>
</person> </person>
<!-- repeat person section for each person --> <!-- repeat person section for each person -->
</people> </people>
6.1.3. Registry Location 6.1.3. Registry Location
Approved registrations are published in the IANA registry named Approved registrations are published in the IANA registry named
"PIDF-LO Civic Address Consideration Registry", which is available at "PIDF-LO Civic Address Considerations Registry", which is available
the following URI: XXX ((TO BE DEFINED BY IANA)). from http://www.iana.org.
Registrations are sorted by ascending order by the country code, and Registrations are sorted by ascending order by the Country-Code and
by serial number within country code values. Registrations with by Serial Number within Country-Code values. Registrations with
country code of "other" are put at the end of the list. Country-Code of "other" are put at the end of the list.
6.1.4. Registration Procedure 6.1.4. Registration Procedure
Following the policies outlined in [RFC5226], new address Following the policies outlined in [RFC5226], new address
considerations are added to the registry after Expert Review (see considerations are added to the registry after Expert Review (see
Section 4.1 in RFC 5226). The Expert will generally check if the Section 4.1 in RFC 5226). The Expert will generally check if the
submitted address considerations conforms the civic address submitted address considerations conform to the civic address
guidelines in this document (see Section 4). If in doubt, the guidelines in this document (see Section 4). If in doubt, the Expert
Experts SHOULD consult the GEOPRIV mailing list or it's dedicated SHOULD consult the GEOPRIV mailing list or its dedicated successor.
successor. If possible, the Experts SHOULD check the available If possible, the Experts SHOULD check the available documentation on
documentation on which the address consideration is based. which the address consideration is based.
6.2. Registration Request for Austria 6.2. Registration Request for Austria
This document requests registration of the Civic Address This document registers the civic address considerations for
Considerations for addresses from the official Austrian Building and addresses from the official Austrian Building and Habitation
Habitation registry, according to the registration procedure registry, according to the registration procedure described above.
described above. The required information is contained in Appendix The required information is contained in Appendix A.
A.
6.3. Registration of the considerations in RFC 4776 as obsolete 6.3. Registration of the Considerations in RFC 4776 as Obsolete
Since this document updates RFC 4776, the considerations on the sub- Since this document updates RFC 4776, the considerations on the
division elements in Section 3.4 of RFC 4776 for Canada, Germany, subdivision Elements in Section 3.4 of RFC 4776 for Canada, Germany,
Japan, Korea and the United States are obsolete. The following IANA Japan, Korea, and the United States are obsolete. The following IANA
registration records register them in the IANA Registry as obsolete. registration records register them in the IANA registry as obsolete.
Canada: Canada:
<record> <record>
<country>CA</country> <country>CA</country>
<serial> <!-- assigned by IANA --> </serial> <serial>0</serial>
<reference>urn:ietf:rfc:4776</reference> <xref type="rfc" data="rfc4776"/>
<requesters> <xref type="person" data="Henning_Schulzrinne"/>
<xref type="person" data="Henning_Schulzrinne"/>
</requesters>
<status>obsolete</status> <status>obsolete</status>
</record> </record>
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
skipping to change at page 17, line 25 skipping to change at page 15, line 24
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
</people> </people>
Germany: Germany:
<record> <record>
<country>DE</country> <country>DE</country>
<serial> <!-- assigned by IANA --> </serial> <serial>0</serial>
<reference>urn:ietf:rfc:4776</reference> <xref type="rfc" data="rfc4776"/>
<requesters> <xref type="person" data="Henning_Schulzrinne"/>
<xref type="person" data="Henning_Schulzrinne"/>
</requesters>
<status>obsolete</status> <status>obsolete</status>
</record> </record>
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
skipping to change at page 18, line 4 skipping to change at page 16, line 6
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
</people> </people>
Japan: Japan:
<record> <record>
<country>JP</country> <country>JP</country>
<serial> <!-- assigned by IANA --> </serial> <serial>0</serial>
<reference>urn:ietf:rfc:4776</reference> <xref type="rfc" data="rfc4776"/>
<requesters> <xref type="person" data="Henning_Schulzrinne"/>
<xref type="person" data="Henning_Schulzrinne"/>
</requesters>
<status>obsolete</status> <status>obsolete</status>
</record> </record>
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
skipping to change at page 18, line 25 skipping to change at page 16, line 24
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
</people> </people>
Korea: Korea:
<record> <record>
<country>KR</country> <country>KR</country>
<serial> <!-- assigned by IANA --> </serial> <serial>0</serial>
<reference>urn:ietf:rfc:4776</reference> <xref type="rfc" data="rfc4776"/>
<requesters> <xref type="person" data="Henning_Schulzrinne"/>
<xref type="person" data="Henning_Schulzrinne"/>
</requesters>
<status>obsolete</status> <status>obsolete</status>
</record> </record>
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
skipping to change at page 19, line 4 skipping to change at page 17, line 6
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
</people> </people>
United States: United States:
<record> <record>
<country>US</country> <country>US</country>
<serial> <!-- assigned by IANA --> </serial> <serial>0</serial>
<reference>urn:ietf:rfc:4776</reference> <xref type="rfc" data="rfc4776"/>
<requesters> <xref type="person" data="Henning_Schulzrinne"/>
<xref type="person" data="Henning_Schulzrinne"/>
</requesters>
<status>obsolete</status> <status>obsolete</status>
</record> </record>
<people> <people>
<person id="Henning_Schulzrinne"> <person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name> <name>Henning Schulzrinne</name>
<org>Columbia University</org> <org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri> <uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
</people> </people>
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Martin Thomson and Richard Barnes for The authors would like to thank Martin Thomson and Richard Barnes for
reviewing the document, and Gregor Jaenin for contributing insights reviewing the document, and Gregor Jaenin for contributing insights
into the Austrian civic address data format. into the Austrian civic address data format.
Appendix A. Civic Address Considerations Registration for the Austrian Appendix A. Civic Address Considerations Registration for the Austrian
building and habitation registry Building and Habitation Registry
The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and
habitation registry law) is the legal basis for the obligation to habitation registry law) is the legal basis for the obligation to
provide a registry of civic addresses, buildings and their usable provide a registry of civic addresses, buildings, and their usable
units (subdivisions of buildings). The registry is operated by units (subdivisions of buildings). The registry is operated by
"Statistik Austria GmbH", a fully governmental owned company. "Statistik Austria GmbH", a fully governmentally owned company. The
Responsibility for keeping records in the registry up to date is an local administrations of individual townships are responsible for
obligation to the local administration of the individual townships. keeping records in the registry up to date.
The data format definition for the individual records is publicly The data format definition for the individual records is publicly
available (data access itself is however restricted). Hence, a available (data access itself is, however, restricted). Hence, a
uniform address data base for the whole Austria is available. A uniform address database for the whole of Austria is available. A
detailed description of the Statistik Austria civic address data detailed description of the Statistik Austria civic address data
format is contained in section Appendix A.1. format is contained in Appendix A.1.
A.1. Civic Address Format in Austria A.1. Civic Address Format in Austria
Statistik Austria data describes estates, buildings and usable units Statistik Austria data describes estates, buildings, and usable units
[refs.merkmalskatalog]. On a single estate there may be any number [merkmalskatalog]. On a single estate there may be any number of
of buildings. Apartment houses that have more than one staircase, buildings. Apartment houses that have more than one staircase are
are split up in separate buildings at every staircase. In every split up in separate buildings at every staircase. In every
building, there may be several usable units. For example, an building, there may be several usable units. For example, an
apartment house may have several apartments, counting as separate apartment house may have several apartments, counting as separate
usable units. Moreover, one building may have more than one address, usable units. Moreover, one building may have more than one address
but at least one address. Below, the address Fields for estates but will have at least one address. Below, the address Fields for
(Table 1), buildings (Table 2) and usable units (Table 3) are shown. 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 The ADDCODE, A5, and PCN Elements are optional, and the other
MUST be used if the data source contains their corresponding Fields. Elements MUST be used if the data source contains their corresponding
The Elements A1 and A2 (not listed in the tables) SHOULD also be used Fields. The Elements A1 and A2 (not listed in the tables) SHOULD
if data is available. Exception: when using the address codes only also be used if data is available. Exception: when using the address
(access to the codes is necessary for creator and receiver of the codes only (access to the codes is necessary for the creator and
location information), just the ADDCODE and country Elements are recipient of the location information), just the ADDCODE and country
mandatory, the other Elements can be used optionally of course. Elements are mandatory; the other Elements can be used optionally, of
course.
+-------------------------+-------------------------------+---------+ +-------------------------+-------------------------------+---------+
| Statistik Austria name | Explanation | PIDF-LO | | Statistik Austria name | Explanation | PIDF-LO |
| | | Element | | | | Element |
+-------------------------+-------------------------------+---------+ +-------------------------+-------------------------------+---------+
| Adresscode | address identifier | ADDCODE | | Adresscode | address identifier | ADDCODE |
| | | | | | | |
| Gemeindename, | commune name and identifier | A3 | | Gemeindename, | commune name and identifier | A3 |
| Gemeindekennziffer | | | | Gemeindekennziffer | | |
| | | | | | | |
skipping to change at page 21, line 36 skipping to change at page 19, line 36
| Hausnummer - 1. Teil - | first part of the house | HNO | | Hausnummer - 1. Teil - | first part of the house | HNO |
| Nummer | number, numeric | | | Nummer | number, numeric | |
| | | | | | | |
| Hausnummer - 1. Teil - | first part of the house | HNO | | Hausnummer - 1. Teil - | first part of the house | HNO |
| Buchstabe | number, character | | | Buchstabe | number, character | |
| | | | | | | |
| Hausnummer - | links first and Bis part of | HNO | | Hausnummer - | links first and Bis part of | HNO |
| Verbindungszeichen Teil | house number | | | Verbindungszeichen Teil | house number | |
| 1 -> Bis | | | | 1 -> Bis | | |
| | | | | | | |
| Hausnummer - Bis-Nummer | number of bis part of house | HNO | | Hausnummer - Bis-Nummer | number of Bis part of house | HNO |
| | number | | | | number | |
| | | | | | | |
| Hausnummer - | character of bis part of | HNO | | Hausnummer - | character of Bis part of | HNO |
| Bis-Buchstabe | house number | | | Bis-Buchstabe | house number | |
| | | | | | | |
| Hausnummernbereich | indicates if all house | HNO | | Hausnummernbereich | indicates if all house | HNO |
| | numbers specified or just odd | | | | numbers specified or just odd | |
| | or even numbers are stated | | | | or even numbers are stated | |
| | | | | | | |
| Postleitzahl | postal code | PC | | Postleitzahl | postal code | PC |
| | | | | | | |
| Postleitzahlengebiet | postal community code | PCN | | Postleitzahlengebiet | postal community code | PCN |
| | | | | | | |
skipping to change at page 23, line 27 skipping to change at page 21, line 27
| Lage | describes if the usable | FLR | | Lage | describes if the usable | FLR |
| | unit is in the basement, | | | | unit is in the basement, | |
| | mezzanine, attic floor, | | | | mezzanine, attic floor, | |
| | ... (but not the floor | | | | ... (but not the floor | |
| | number) | | | | number) | |
| | | | | | | |
| Stockwerk | floor | FLR | | Stockwerk | floor | FLR |
| | | | | | | |
+-----------------------------+---------------------------+---------+ +-----------------------------+---------------------------+---------+
Table 3: Additional Civic Address Fields for usable units Table 3: Additional Civic Address Fields for Usable Units
Note: "Floors" in Austria (as in most parts of Europe) are counted Note: "floors" in Austria (as in most parts of Europe) are counted
differently compared to the US. The "1st floor" in Austria is differently compared to the US. The "1st floor" in Austria is
actually the floor above the floor at street level (2nd floor in US), 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 -- not considering the fact that, in old buildings, there might be
more floors between street level and 1st floor, like "mezzanine", even more floors between street level and 1st floor, like "mezzanine"
"2nd mezzanine". So, an Austrian "1st floor" could well be the "4th and "2nd mezzanine". So, an Austrian "1st floor" could well be the
floor" according to US nomenclature. "4th floor" according to US nomenclature.
According to Statistik Austria [refs.adrwarten], 81.5% of Austrian According to Statistik Austria [adrwarten], 81.5% of Austrian
addresses are of the simple type Musterstrasse 1 (Musterstrasse is an addresses are of the simple type Musterstrasse 1 (Musterstrasse is an
example street name). 5% of all addresses have an additional example street name). 5% of all addresses have an additional
character, like Musterstrasse 1b. 1% of Austrian addresses look like character, like Musterstrasse 1b. 1% of Austrian addresses look like
Musterstrasse 21A - 23A. For 8% of addresses, an additional separator Musterstrasse 21A - 23A. For 8% of addresses, an additional
is necessary, like Musterstrasse 10 Haus 1 Stiege 2 or Musterstrasse separator is necessary -- like Musterstrasse 10 Haus 1 Stiege 2, or
20 Gruppe A Reihe 1 Parzelle 13 or Musterstrasse 30 Weg 1 Parzelle Musterstrasse 20 Gruppe A Reihe 1 Parzelle 13, or Musterstrasse 30
10. Very seldom, there are so called special addresses (0.03%), for Weg 1 Parzelle 10. Very seldom, there are so-called special
example Musterstrasse gegenueber 3A, meaning this address is actually addresses (0.03%) -- for example, Musterstrasse gegenueber 3A,
opposite of house number 3A. Rather surprisingly, 4.47% of Austrian meaning this address is actually opposite of house number 3A. Rather
addresses contain the identifier of the estate since no house number surprisingly, 4.47% of Austrian addresses contain the identifier of
is assigned at all, for example: Musterstrasse GNR 1234, or the estate since no house number is assigned at all -- for example,
Musterstrasse GNR .12/4 Kirche (this type of addresses is common for Musterstrasse GNR 1234, or Musterstrasse GNR .12/4 Kirche (this type
churches) or a real example in Stockerau: Kolomaniwoerth GNR 1583. of addresses is common for churches), or a real example in Stockerau:
This identifier is stored by Statistik Austria as Hausnummerntext.
Otherwise one could misinterpret this number as a house number, what Kolomaniwoerth GNR 1583. This identifier is stored by Statistik
would be definitely wrong. Austria as Hausnummerntext. Otherwise, one could misinterpret this
number as a house number, which would be definitely wrong.
A.2. Sample Addresses A.2. Sample Addresses
In order to clarify the Austrian civic address format, this section In order to clarify the Austrian civic address format, this section
provides some exemplary addresses: provides some exemplary addresses:
1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1 1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1
Postleitzahl: 1234 Postleitzahl: 1234
Stadt: Musterstadt Stadt: Musterstadt
Strasse: Hauptstrasse Strasse: Hauptstrasse
skipping to change at page 24, line 47 skipping to change at page 22, line 50
Stadt: Innsbruck Stadt: Innsbruck
Strasse: Anichstrasse Strasse: Anichstrasse
Hausnummerntext: vor ("in front of") Hausnummerntext: vor ("in front of")
Hausnummer: 35 Hausnummer: 35
6173 Oberperfuss, Riedl 3097 (Pfarrkirche) 6173 Oberperfuss, Riedl 3097 (Pfarrkirche)
Postleitzahl: 6173 Postleitzahl: 6173
Stadt: Oberperfuss Stadt: Oberperfuss
Strasse: Riedl Strasse: Riedl
Hausnummerntext: 3097 Hausnummerntext: 3097
(since the estate identifier is 81305 3097 where 81305 is the (since the estate identifier is 81305 3097, where 81305 is the
Katastralgemeindenummer (cadastral municipality) and no house Katastralgemeindenummer (cadastral municipality), and no house
number is assigned) number is assigned)
Vulgoname: Pfarrkirche Vulgoname: Pfarrkirche
A.3. Address Codes in Austria A.3. Address Codes in Austria
Statistik Austria registers 4 codes: Adresscode, Adresssubcode, Statistik Austria registers 4 codes: Adresscode, Adresssubcode,
Objektnummer and the Nutzungseinheitenlaufnummer. The Adresscode (7 Objektnummer, and the Nutzungseinheitenlaufnummer. The Adresscode (7
digits) is a unique code for an address in Austria. The digits) is a unique code for an address in Austria. The
Adressregister maps the Adresscode to the civic address. If there is Adressregister maps the Adresscode to the civic address. If there is
a building located at an address, there is also an Adresssubcode (3 a building located at an address, there is also an Adresssubcode (3
digits) assigned. Every building at an address has its own digits) assigned. Every building at an address has its own
Adresssubcode (assigned sequentially starting with 001, 002, 003 and Adresssubcode (assigned sequentially starting with 001, 002, 003, and
so on) in order to distinguish between buildings at the same address. so on) in order to distinguish between buildings at the same address.
Furthermore, every building located in Austria has its own unique Furthermore, every building located in Austria has its own unique
code, the Objektnummer (7 digits). This code identifies the building code, the Objektnummer (7 digits). This code identifies the building
independent of the Adresscode. That's because addresses are subject independent of the Adresscode. That's because addresses are subject
to change while the building may persist. To differ multiple usable to change while the building may persist. To differentiate multiple
units inside a building, the Nutzungseinheitenlaufnummer (4 digits) usable units inside a building, the Nutzungseinheitenlaufnummer (4
is used. This code is also assigned in sequential order for each digits) is used. This code is also assigned in sequential order for
building. each building.
Besides, every address and building is geocoded by Statistik Austria. Besides, every address and building is geocoded by Statistik Austria.
Hence, if every PIDF-LO location object would carry data in the Hence, if every PIDF-LO would carry data in the format of Statistik
format of Statistik Austria and every PSAP would use the database of Austria and if every PSAP would use the database of Statistik Austria
Statistik Austria for mapping, a time saving, definite mapping for mapping, a time-saving, definite mapping without irregularities
without irregularities could be achieved. could be achieved.
Besides these codes, Statistik Austria maintains reference numbers Besides these codes, Statistik Austria maintains reference numbers
for communes, localities or streets, to mention just a few. for communes, localities, or streets, to mention just a few.
A.4. Austrian Addresses in PIDF-LO A.4. Austrian Addresses in PIDF-LO
The following subsections define the mapping procedure. The following subsections define the mapping procedure.
A.4.1. Country A.4.1. Country
The country element for Austria must be set to AT, since this is the 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. ISO 3166-1 [ISO3166-1] alpha-2 code for Austria.
<country>AT</country> <country>AT</country>
The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119] and The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119], and
RFC 5139 [RFC5139] proposes to use upper case characters only. RFC 5139 [RFC5139] proposes to use uppercase characters only.
A.4.2. Country Subdivisions A1-A6 A.4.2. Country Subdivisions A1-A6
A1 province (Bundesland), Section A.4.2.1 A1 province (Bundesland), Section A.4.2.1
A2 political district name or identifier (politischer Bezirk), A2 political district name or identifier (politischer Bezirk),
Section A.4.2.2 Section A.4.2.2
A3 commune name or identifier (Gemeinde), Section A.4.2.3 A3 commune name or identifier (Gemeinde), Section A.4.2.3
A4 village name or identifier (Ortschaft), Section A.4.2.4 A4 village name or identifier (Ortschaft), Section A.4.2.4
A5 cadastral municipality name or identifier (Katastralgemeindename A5 cadastral municipality name or identifier (Katastralgemeindename
or Katastralgemeindenummer), Section A.4.2.5 or Katastralgemeindenummer), Section A.4.2.5
Element A6 must not be used. Element A6 must not be used.
skipping to change at page 26, line 14 skipping to change at page 24, line 17
A1 province (Bundesland), Section A.4.2.1 A1 province (Bundesland), Section A.4.2.1
A2 political district name or identifier (politischer Bezirk), A2 political district name or identifier (politischer Bezirk),
Section A.4.2.2 Section A.4.2.2
A3 commune name or identifier (Gemeinde), Section A.4.2.3 A3 commune name or identifier (Gemeinde), Section A.4.2.3
A4 village name or identifier (Ortschaft), Section A.4.2.4 A4 village name or identifier (Ortschaft), Section A.4.2.4
A5 cadastral municipality name or identifier (Katastralgemeindename A5 cadastral municipality name or identifier (Katastralgemeindename
or Katastralgemeindenummer), Section A.4.2.5 or Katastralgemeindenummer), Section A.4.2.5
Element A6 must not be used. Element A6 must not be used.
Last, there is an exception to mention concerning the Austrian Last, there is an exception to mention that concerns the Austrian
capital Vienna (Wien). The city of Vienna is equal to its political capital, Vienna (Wien). The city of Vienna is equal to its political
district and even the province is called Vienna. Nevertheless, district and even the province is called Vienna. Nevertheless,
Vienna is separated in 23 districts within the same political Vienna is separated in 23 districts within the same political
district. Consequently, an address in Vienna would look like: district. Consequently, an address in Vienna would look like:
<country>AT</country> <country>AT</country>
<A1>Wien</A1> <A1>Wien</A1>
<A2>Wien</A2> <A2>Wien</A2>
<A3>Wien</A3> <A3>Wien</A3>
<A4>Favoriten</A4> or <A4>10<A4> <A4>Favoriten</A4> or <A4>10<A4>
<A5>Inzersdorf Stadt<A5> <A5>Inzersdorf Stadt<A5>
The element A4, holding the city division, can hold the name or the The Element A4, holding the city division, can hold the name or the
number of the district. number of the district.
A.4.2.1. A1 Element A.4.2.1. A1 Element
As proposed in RFC 5139 [RFC5139], for the PIDF-LO element A1, the 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 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. 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 Table 4 shows the possible values of the A1 Element for Austrian
states. states.
+------------------------+--------------------------------+ +------------------------+--------------------------------+
| Bundesland | second part of ISO 3166-2 code | | Bundesland | second part of ISO 3166-2 code |
+------------------------+--------------------------------+ +------------------------+--------------------------------+
| Burgenland | 1 | | Burgenland | 1 |
| | | | | |
| K=U+00E4rnten | 2 | | K=U+00E4rnten | 2 |
| | | | | |
| Nieder=U+00F6sterreich | 3 | | Nieder=U+00F6sterreich | 3 |
skipping to change at page 27, line 27 skipping to change at page 25, line 27
| | | | | |
| Steiermark | 6 | | Steiermark | 6 |
| | | | | |
| Tirol | 7 | | Tirol | 7 |
| | | | | |
| Vorarlberg | 8 | | Vorarlberg | 8 |
| | | | | |
| Wien | 9 | | Wien | 9 |
+------------------------+--------------------------------+ +------------------------+--------------------------------+
Table 4: A1 element format for Austria (Note: values are shown in Table 4: A1 Element Format for Austria
UTF-8, which is recommended to be used for PIDF-LO) (Note: values are shown in UTF-8, which is recommended to be used for
PIDF-LO.)
A.4.2.2. A2 Element A.4.2.2. A2 Element
Names of the Austrian political districts are available at Statistik Names of the Austrian political districts are available at Statistik
Austria [refs.bezirke]. These names, the unique code for the Austria [bezirke]. These names, the unique code for the political
political district or both can be used for the A2 element. If the district, or both can be used for the A2 Element. If the content of
content of the A2 element is numeric, obviously the code is provieded the A2 Element is numeric, obviously the code is provided (there is
(there is no political district in Austria with a number in its no political district in Austria with a number in its name). In case
name). In case both, the name and the code are provided, they are both the name and the code are provided, they are separated by a
separated by a semicolon, and the name must be listed first. semicolon and the name must be listed first.
The district of "Bruck an der Leitha" could be represented by: 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<A2>
or
<A2>307</A2>
or
<A2>Bruck an der Leitha;307</A2> <A2>Bruck an der Leitha;307</A2>
A.4.2.3. A3 Element A.4.2.3. A3 Element
The element A3 holds the Gemeindename (commune name) or the The Element A3 holds the Gemeindename (commune name), the identifier
identifier of the Gemeinde, or both separated by a semicolon (the of the Gemeinde, or both separated by a semicolon (the name must be
name must be listed first). If the content of the A3 element listed first). If the content of the A3 Element consists of a number
consists of a number only, it is obvious that just the identifier is only, it is obvious that just the identifier is provided. Statistik
provided. Statistik Austria maintains a table with the Gemeindenamen Austria maintains a table with the Gemeindenamen and identifiers
and identifiers [refs.gemeinden], which must be used as the content [gemeinden], which must be used as the content for the A3 Element; no
for the A3 element, no other spelling is allowed. other spelling is allowed.
Sample: Sample:
<A3>Neusiedl am See</A3> <A3>Neusiedl am See</A3>
or or
<A3>10713</A3> <A3>10713</A3>
or or
<A3>Neusiedl am See;10713</A3> <A3>Neusiedl am See;10713</A3>
A.4.2.4. A4 Element A.4.2.4. A4 Element
The element A4 holds the Ortschaftsname (village name), the The Element A4 holds the Ortschaftsname (village name), the
Ortschaftskennziffer (the identifier), or both separated by a Ortschaftskennziffer (the identifier), or both separated by a
semicolon (the name must be listed first). If the content of the A4 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 Element consists of a number only, it is obvious that just the
identifier is provided since there are no Ortschaftsnamen in Austria identifier is provided, since there are no Ortschaftsnamen in Austria
which contain a number. Statistik Austria maintains a table with the that contain a number. Statistik Austria maintains a table with the
Ortschaftsnamen and identifiers [refs.ortschaften], which must be Ortschaftsnamen and identifiers [ortschaften], which must be used as
used as the content for the A4 element, no other spelling is allowed. the content for the A4 Element; no other spelling is allowed.
Sample: Sample:
<A4>Wilfleinsdorf</A4> or <A4>03448</A4> or <A4>Wilfleinsdorf</A4>
or
<A4>03448</A4>
or
<A4>Wilfleinsdorf;03448</A4> <A4>Wilfleinsdorf;03448</A4>
A.4.2.5. A5 Element A.4.2.5. A5 Element
The element A5 holds the Katastralgemeindename (cadastral The Element A5 holds the Katastralgemeindename (cadastral
municipality), the Katastralgemeindenummer (the identifier), or both municipality), the Katastralgemeindenummer (the identifier), or both
separated by a semicolon (the name must be listed first). If the 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 content of the A5 Element consists of a number only, it is obvious
that just the identifier is provided since there are no that just the identifier is provided, since there are no
Katastralgemeindenamen in Austria which contain a number. Katastralgemeindenamen in Austria that contain a number.
Sample (Vienna, Fuenfhaus): Sample (Vienna, Fuenfhaus):
<A5>Oberbaumgarten</A5> or <A5>1208</A5> or <A5>Oberbaumgarten</A5>
or
<A5>1208</A5>
or
<A5>Oberbaumgarten;1208</A5> <A5>Oberbaumgarten;1208</A5>
A.4.3. Road and Street Names A.4.3. Road and Street Names
The PIDF-LO element RD holds the complete street name, including the The PIDF-LO Element RD holds the complete street name, including the
street suffix. No abbreviations are allowed. No other elements are street suffix. No abbreviations are allowed. No other Elements are
needed for streets and must not be used. needed for streets and must not be used.
A.4.4. House Numbers A.4.4. House Numbers
Statistik Austria lists 14 data fields related to the house number of Statistik Austria lists 14 data Fields related to the house number of
a building plus another 5 fields for distinction of different usable a building plus another 5 Fields for distinction of different usable
units inside a building (including the floor, which has a separate units inside a building (including the floor, which has a separate
element in PIDF-LO). Unfortunately, PIDF-LO only defines a single Element in PIDF-LO). Unfortunately, PIDF-LO only defines a single
house number element (HNO, numeric part only) and a house number house number Element (HNO, numeric part only) and house number suffix
suffix element (HNS). Therefore, this section defines a mapping in Element (HNS). Therefore, this section defines a mapping in order to
order to accommodate all data: All house number data is concatenate accommodate all data: all house number data is concatenated into a
into a single HNO element, even though it is expected to hold numeric single HNO Element, even though it is expected to hold numeric part
part only. only.
In order to allow automatic procession of the HNO Element, it is In order to allow automatic procession of the HNO Element, it is
necessary to use a semicolon as delimiter symbol (Austrian house necessary to use a semicolon as a delimiter symbol (Austrian house
numbers do not contain semicolons). The house number parts MUST be numbers do not contain semicolons). The house number parts MUST be
provided in the order as they are listed by the Statistik Austria provided in the order in which they are listed by the Statistik
document [refs.merkmalskatalog]. For user interface representation, Austria document [merkmalskatalog]. For user-interface
the semicolon separated format can be transformed by replacing representation, the semicolon-separated format can be transformed by
semicolons by spaces (multiple spaces should be combined) and no replacing semicolons by spaces (multiple spaces should be combined)
space should be present between a numeric part of a house number part and no space should be present between a numeric part of a house
and its related character. number and its related character.
It is not allowed to use the HNS element for Austrian addresses, It is not allowed to use the HNS Element for Austrian addresses,
since there are addresses that do not have just a single suffix. since there are addresses that do not have just a single suffix.
The house number "vor 1 - 1A" (consisting of a house number text 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 "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 the first and Bis part, "1" as house number Bis part numeric, "A" as
character of the bis part) would be mapped to: character of the Bis part) would be mapped to:
<HNO>vor;1;;-;1;A;;;;;;;;;;;</HNO> <HNO>vor;1;;-;1;A;;;;;;;;;;;</HNO>
A.4.5. Local Names A.4.5. Local Names
NAM: contains the Vulgoname (local name), multiple local names are NAM: contains the Vulgoname (local name); multiple local names are
separated by a semicolon (if applicable) separated by a semicolon (if applicable).
LMK: contains the farm name (just one name possible) (if applicable) LMK: contains the farm name (just one name possible) (if applicable).
LOC: can be used without restriction for additional location LOC: can be used without restriction for additional location
information (as per RFC 4119) information (as per RFC 4119).
A.4.6. Floors A.4.6. Floors
The floor element may contain numbers or text describing the floor. 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 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>. level. The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>.
Other floors may have names like mezzanine, for example. The Other floors may have names like mezzanine, for example. The
Statistik Austria data elements Lage and Stockwerk are concatenated Statistik Austria data Fields Lage and Stockwerk are concatenated if
if necessary. necessary.
A.4.7. Additional Code Element A.4.7. Additional Code Element
The element additional code may be used to hold the codes provided by The Element additional code may be used to hold the codes provided by
Statistik Austria. There is an Adresscode, Adresssubcode, Statistik Austria. There is an Adresscode, Adresssubcode,
Objektnummer and a Nutzungseinheitenlaufnummer. These unique codes Objektnummer, and a Nutzungseinheitenlaufnummer. These unique codes
identify the location. Actually, these codes alone would be enough, identify the location. Actually, these codes alone would be enough
but requires that the location recipient has access to the database but require that the location recipient has access to the database of
of Statistik Austria. Statistik Austria.
If the additional code in a PIDF-LO document is going to hold the If the additional code in a PIDF-LO document is going to hold the
codes from Statistik Austria, the following format should be used: codes from Statistik Austria, the following format should be used:
<ADDCODE>AdrCD=1234567;AdrsubCD=123; <ADDCODE>AdrCD=1234567;AdrsubCD=123;
ObjNr=2333211;NtzLnr=0001</ADDCODE> ObjNr=2333211;NtzLnr=0001</ADDCODE>
It is not necessary to provide all codes, but there are some It is not necessary to provide all codes, but there are some
restrictions: The Adresssubcode cannot be used without an Adresscode. restrictions: the Adresssubcode cannot be used without an Adresscode.
More restrictions are defined by Statistik Austria. By setting the More restrictions are defined by Statistik Austria. By setting the
country element to AT (see Section 4.2.1), indicating an Austrian country Element to AT (see Section 4.2.1), indicating an Austrian
address, the Additional Code element is expected to hold codes from address, the Additional Code Element is expected to hold codes from
Statistik Austria only. When creating PIDF-LO documents using Statistik Austria only. When creating PIDF-LO documents using
address codes by Statistik Austria, the country and ADDCODE elements address codes by Statistik Austria, the country and ADDCODE Elements
are mandatory. are mandatory.
A.4.8. Other Elements A.4.8. Other Elements
The elements PC and PCN can hold the data form Statistik Austria, the 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 POBOX can be used if the post assigned a post office box. At least
the PC element should be present. the PC Element should be present.
PC: Postleitzahl (postal code) PC: Postleitzahl (postal code)
PCN: Postleitzahlengebiet (postal community name) PCN: Postleitzahlengebiet (postal community name)
POBOX: Postfach POBOX: Postfach
The elements UNIT, ROOM, SEAT, PLC and BLD may be used without The Elements UNIT, ROOM, SEAT, PLC, and BLD may be used without
further restriction. further restriction.
A.4.9. Elements not to be used A.4.9. Elements Not to Be Used
A6 A6
STS STS
HNS HNS
PRD PRD
POD POD
RDBR RDBR
RDSUBBR RDSUBBR
PRM PRM
POM POM
skipping to change at page 32, line 5 skipping to change at page 30, line 10
Strasse: Lazarettgasse Strasse: Lazarettgasse
Hausnummer - 1. Teil - Nummer: 13 Hausnummer - 1. Teil - Nummer: 13
Hausnummer - 1. Teil - Buchstabe: A Hausnummer - 1. Teil - Buchstabe: A
Hausnummer - Verbindungszeichen Teil 1-Bis: - Hausnummer - Verbindungszeichen Teil 1-Bis: -
Hausnummer - Bis-Nummer: 13 Hausnummer - Bis-Nummer: 13
Hausnummer - Bis-Buchstabe: C Hausnummer - Bis-Buchstabe: C
Postleitzahl: 1090 Postleitzahl: 1090
PIDF-LO: PIDF-LO:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:123@examplehost"> entity="pres:123@examplehost">
<tuple id="abcd123456"> <tuple id="abcd123456">
<status> <status>
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<cl:civicAddress xml:lang="de"> <cl:civicAddress xml:lang="de">
<cl:country>AT</cl:country> <cl:country>AT</cl:country>
<cl:A1>Wien</cl:A1> <cl:A1>Wien</cl:A1>
<cl:A2>Wien</cl:A2> <cl:A2>Wien</cl:A2>
<cl:A3>Wien</cl:A3> <cl:A3>Wien</cl:A3>
<cl:A4>9</cl:A4> <cl:A4>9</cl:A4>
<cl:RD>Lazarettgasse</cl:RD> <cl:RD>Lazarettgasse</cl:RD>
<cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</cl:HNO> <cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</cl:HNO>
<cl:PC>1090</cl:PC> <cl:PC>1090</cl:PC>
</cl:civicAddress> </cl:civicAddress>
</gp:location-info> </gp:location-info>
<gp:usage-rules> <gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed> <gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2009-11-10T12:00:00Z</gp:retention-expiry> <gp:retention-expiry>2009-11-10T12:00:00Z</gp:retention-expiry>
</gp:usage-rules> </gp:usage-rules>
</gp:geopriv> </gp:geopriv>
</status> </status>
<timestamp>2009-02-09T12:00:00Z</timestamp> <timestamp>2009-02-09T12:00:00Z</timestamp>
</tuple> </tuple>
</presence> </presence>
A.6. IANA Registration Record A.6. IANA Registration Record
<record>
<country>AT</country>
<serial> <!-- assigned by IANA --> </serial>
<reference> <record>
<!-- RFC-Editor: the URN to this RFC / --> <country>AT</country>
</reference> <serial>0</serial>
<requesters> <!-- reference to document -->
<xref type="person" data="Alexander_Mayrhofer"/> <xref type="rfc" data="rfc5774"/>
<xref type="person" data="Karl_Heinz_Wolf"/>
</requesters>
<status> <!-- assigned by IANA --> </status> <!-- record requesters -->
</record> <xref type="person" data="Alexander_Mayrhofer"/>
<xref type="person" data="Karl_Heinz_Wolf"/>
<status>active</status>
</record>
<people> <people>
<person id="Alexander_Mayrhofer"> <person id="Alexander_Mayrhofer">
<name>Alexander Mayrhofer</name> <name>Alexander Mayrhofer</name>
<org>nic.at GmbH</org> <org>nic.at GmbH</org>
<uri>mailto:alexander.mayrhofer@nic.at</uri> <uri>mailto:alexander.mayrhofer@nic.at</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
<person id="Karl_Heinz_Wolf"> <person id="Karl_Heinz_Wolf">
<name>Karl Heinz Wolf</name> <name>Karl Heinz Wolf</name>
<org>nic.at GmbH</org> <org>nic.at GmbH</org>
<uri>mailto:karlheinz.wolf@nic.at</uri> <uri>mailto:karlheinz.wolf@nic.at</uri>
<updated>2009-01-09</updated> <updated>2009-01-09</updated>
</person> </person>
</people> </people>
8. References Normative References
8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Requirement Levels", BCP 14, RFC 2119, March 1997. Format", RFC 4119, December 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
Format", RFC 4119, December 2005. Registry", RFC 4589, July 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Option for Civic Addresses (DHCPv4 and DHCPv6) Option for Civic Addresses
Configuration Information", RFC 4776, November 2006. Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic
Format for Presence Information Data Format Location Location Format for Presence Information Data Format
Object (PIDF-LO)", RFC 5139, February 2008. Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26, RFC
May 2008. 5226, May 2008.
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types [W3C.REC-xml-20060816]
Registry", RFC 4589, July 2006. W3C, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", Recommendation REC-xml-20060816, August
2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
8.2. Informative References Informative References
[refs.adrwarten] [adrwarten] Statistik Austria, "Handbuch Adress-GWR-Online Teil A
Statistik Austria, "Handbuch Adress-GWR-Online Teil A Theoretisches Handbuch Kapitel 2 Warten von Adressen im
Theoretisches Handbuch Kapitel 2 Warten von Adressen im Adress-GWR-Online", Jan 2005.
Adress-GWR-Online", Jan 2005.
[refs.merkmalskatalog] [merkmalskatalog]
Statistik Austria, "Handbuch Adress-GWR-Online Teil C Statistik Austria, "Handbuch Adress-GWR-Online Teil C
Anhang 2 Merkmalskatalog", Sept 2004. Anhang 2 Merkmalskatalog", Sept 2004.
[refs.ISO3166-1] [ISO3166-1] International Organization for Standardization, "Codes
International Organization for Standardization, "Codes for for the representation of names of countries and their
the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard
subdivisions - Part 1: Country codes", ISO Standard 3166- 3166-1:1997, 1997.
1:1997, 1997.
[refs.ISO3166-2] [ISO3166-2] International Organization for Standardization, "Codes
International Organization for Standardization, "Codes for for the representation of names of countries and their
the representation of names of countries and their subdivisions - Part 2: Country subdivision code", ISO
subdivisions - Part 2: Country subdivision code", ISO Standard 3166-2:1998, 1998.
Standard 3166-2:1998, 1998.
[refs.bezirke] [bezirke] Statistik Austria, "Politische Bezirke, Gebietsstand
Statistik Austria, "Politische Bezirke, Gebietsstand 2008", Feb 2008.
2008", Feb 2008.
[refs.gemeinden] [gemeinden] Statistik Austria, "Gemeindeliste sortiert nach
Statistik Austria, "Gemeindeliste sortiert nach Gemeindekennziffer, Gebietsstand 2008", Feb 2008.
Gemeindekennziffer, Gebietsstand 2008", Feb 2008.
[refs.ortschaften] [ortschaften] Statistik Austria, "Gemeinden mit Ortschaften und
Statistik Austria, "Gemeinden mit Ortschaften und Postleitzahlen, Gebietsstand 2008", Feb 2008.
Postleitzahlen, Gebietsstand 2008", Feb 2008.
Authors' Addresses Authors' Addresses
Karl Heinz Wolf Karl Heinz Wolf
nic.at GmbH nic.at GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 37 Phone: +43 1 5056416 37
Email: karlheinz.wolf@nic.at EMail: karlheinz.wolf@nic.at
URI: http://www.nic.at/ URI: http://www.nic.at/
Alexander Mayrhofer Alexander Mayrhofer
nic.at GmbH nic.at GmbH
Karlsplatz 1/2/9 Karlsplatz 1/2/9
Wien A-1010 Wien A-1010
Austria Austria
Phone: +43 1 5056416 34 Phone: +43 1 5056416 34
Email: alexander.mayrhofer@nic.at EMail: alexander.mayrhofer@nic.at
URI: http://www.nic.at/ URI: http://www.nic.at/
 End of changes. 201 change blocks. 
588 lines changed or deleted 580 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/