RFC 5774
Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition
RFC 5774: Civic Address Considerations for PIDF-LO 💖
okay so this is a Best Current Practice (BCP 154, so it's basically the community's official "do it this way" guide 🎀). It's from March 2010 and it was written by K. Wolf and A. Mayrhofer from nic.at 🦋. It updates RFC 4776 and it's all about how to write civic address rules for PIDF-LO, which is the location format that carries your street address info around the internet 🗺️. It's published under the IETF Trust copyright (2010), and it's ISSN 2070-1721 if you ever need to look it up 🧚
The title, if you want the full drama: Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition 💅
Abstract ✨
okay so the big idea is simple 🌸 This doc gives you a guideline for making civic address considerations documents for individual countries. RFC 4776 says those documents have to exist, but it never explains how to write them, so this fills that gap 🙌 It also creates an IANA Registry that points to these documents, and it registers the considerations for Austria as the first example 🇦🇹💜
Status of This Memo ✨
this memo documents an Internet Best Current Practice 🎀
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on BCPs, check Section 2 of RFC 5741 📖
for the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc5774 🔗
Copyright Notice ✨
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💅
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. please actually read those, bestie, because they explain your rights and restrictions 🙈 and if you pull Code Components out of this document, they have to include the Simplified BSD License text (as described in Section 4.e of the Trust Legal Provisions), and they come with no warranty, as the Simplified BSD License describes 🧚
Table of Contents 🌈
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Requirements ....................................................4
4. Specifying PIDF-LO Element Usage ................................5
4.1. General Considerations and Workflow ........................5
4.2. Guidelines for Individual Elements .........................7
4.2.1. Country .............................................7
4.2.2. Country Subdivisions A1-A6 ..........................7
4.2.3. Road and Street Names ...............................8
4.2.4. House Numbers .......................................8
4.2.5. Local Names .........................................9
4.2.6. Floors .............................................10
4.2.7. Address Codes ......................................10
4.2.8. Other Elements .....................................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
6.1. PIDF-LO Civic Address Considerations Registry .............12
6.1.1. Structure ..........................................12
6.1.2. Registration Template ..............................13
6.1.3. Registry Location ..................................14
6.1.4. Registration Procedure .............................14
6.2. Registration Request for Austria ..........................14
6.3. Registration of the Considerations in RFC 4776 as
Obsolete ..................................................14
7. Acknowledgements ...............................................17
Appendix A. Civic Address Considerations Registration for
the Austrian Building and Habitation Registry .............18
A.1. Civic Address Format in Austria ...........................18
A.2. Sample Addresses ..........................................22
A.3. Address Codes in Austria ..................................23
A.4. Austrian Addresses in PIDF-LO .............................23
A.4.1. Country ............................................23
A.4.2. Country Subdivisions A1-A6 .........................24
A.4.3. Road and Street Names ..............................27
A.4.4. House Numbers ......................................27
A.4.5. Local Names ........................................28
A.4.6. Floors .............................................28
A.4.7. Additional Code Element ............................28
A.4.8. Other Elements .....................................29
A.4.9. Elements Not to Be Used ............................29
A.5. Example ...................................................29
A.6. IANA Registration Record ..................................30
Normative References ..............................................31
Informative References ............................................321. Introduction 🎀
okay so PIDF-LO (see [RFC4119]) is an object format for carrying geographic info across the internet 🌍 it can hold civic address info, and it supports a bunch of "civic address types" (CAtypes) that store each piece of an address separately (see Section 2.2.1 of [RFC4119] and Section 3.1 of [RFC5139]) 💜
here's the tea: a lot of real-world use cases fill PIDF-LOs with data from long-established places like postal and government building registers, line information databases, infrastructure providers' yellow and white pages, or official residents registers 🗂️ the structure and format of that data is almost never the same as the CAtypes definition, and it also changes from country to country 😭
so if you want to use those sources, you have to transpose that data into PIDF-LO format 🦋 and with no guidelines for how to map source Fields into CAtype Elements, different PIDF-LO creators could end up with different results, even from the very same data source 💀 that hurts interoperability and makes it easier for recipients to misinterpret things 🙈
that's why civic address considerations are needed, to get uniform usage of PIDF-LO Elements for these data sources ✨ [RFC4776] explicitly asks for these documents, but it doesn't define their structure or a way to publish them 🤷♀️ this memo explains how to create civic address considerations, and IANA has made a registry to store references to them 📚 civic address considerations for Austria are in Appendix A and are registered in that IANA registry 🇦🇹
Section 3.4 of [RFC4776] has some example considerations about using administrative subdivision Elements for Canada, Germany, Japan, Korea, and the United States 🍁 this document registers those examples with IANA as "obsolete" (see Section 6.3) 🌸
Section 3.4 of [RFC4776] also has instructions for creating civic address considerations documents on page 8 📄 this document updates that section and swaps those instructions out for Sections 4 and 5 of this memo 🔄
the guidelines here are focused on formal use of PIDF-LO, like conveying location during an emergency call 🚨 they are NOT meant to ban other, more informal uses of PIDF-LO that don't follow any formal mapping spec. an example of informal use is sending PIDF-LO documents during an instant-messaging chat between humans 💬 just know that this kind of use can come with drawbacks, like making automatic processing of civic addresses from that PIDF-LO impossible 🙃
2. Terminology 💅
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🎀
also, this document uses "Field" to mean a field of a civic address data source, and "Element" to mean a CAtype Element of a PIDF-LO 🧚
3. Requirements 🌈
these are the requirements for defining civic-address mapping considerations ✨
- the considerations document MUST identify the data source the definitions apply to 🗂️ a short description of its structure SHOULD be included too 💖
- for any data source, just one active mapping definition should exist, so you cut down on the risk of ambiguous interpretation 🫶
- the document MUST include instructions for every Field that shows up in the data 🔥 for each of those Fields, the document MUST say whether the Field is required, optional, or must not be used in the mapping procedure 👑
- instructions MUST be included for every CAtype Element that's registered by the time the document is written 💅 those instructions MUST say whether an Element is required, optional, or must not be used in that mapping 🙈 if the IETF revises the set of CAtypes, the address considerations document SHOULD be updated 🦋 until an update is approved, the existing mapping procedure MUST be used 🫶
- address mapping procedures SHOULD be reversible, so that location recipients can find the matching record in the original data source (assuming they can access that source) 🔍✨
- for any source data Field that is required or optional, at least one example mapping MUST be provided 🌸
- a lot of data sources used in mapping might have access restrictions 🔒 those restrictions (as they apply to the original data) MUST also be applied to the resulting PIDF-LO documents 😤 the considerations document SHOULD note those restrictions in its Security Considerations section 🧚
⚠️ okay bestie, this one's important: access restrictions on the original data follow the data into the PIDF-LO. don't drop them just because the location object looks harmless 💀
so the thing is, the mapping is defined on a national basis, and an outsider might not get what several PIDF-LO Elements actually mean 🌍 but the country Element at least tells you what context the PIDF-LO was made in 🇺🇳 for emergency calls, a PIDF-LO just gets passed to a Public Safety Answering Point (PSAP) in the same country as the location generator anyway 🚨 near borders, though, it could end up going to a neighboring country 🗺️ the PIDF-LO can still get passed on to a PSAP in the right country (based on the country Element), or that PSAP might already know the mapping scheme used in the neighboring country 🤝
consistent mapping also matters a lot for checking whether two PIDF-LO documents describe the same location 👀 if civic address Fields go into different PIDF-LO Elements, it can be really hard to tell whether two PIDF-LOs describe identical addresses 😵💫
4. Specifying PIDF-LO Element Usage ✨
the whole point of civic address considerations for an individual data source is to create interoperability 💜 you do that by specifying a common list of PIDF-LO Elements to use, and by defining the mapping between those Elements and the Fields of the respective data source 🎀
4.1. General Considerations and Workflow 🧭
okay so the workflow for making an address considerations doc goes like this 💖
- Describe the data source that the address considerations doc applies to.
- Identify all Fields from the data source and decide, for each one, whether it's gonna be used for making PIDF-LO documents. The considerations doc must list all Fields (or at least say which Fields are considered in the mapping and clearly say that the other Fields MUST NOT be used).
- For each Field that's required or optional, specify a clear mapping instruction following the guidelines below. ✨
- Provide a list of all CAtypes registered and describe how much each one gets used in this mapping (or combine it with the Fields list above and clearly list which Elements aren't used for the mapping procedure). For Elements that aren't described in detail, state whether they MUST NOT be used at all or whether they may be used without further restriction.
- Provide examples of source data and mapping results. 🎀
Civic address Elements are designed to be generic containers, and that's giving flexibility 🦋 Sometimes a Field clearly matches one of these containers. Other times, finding the right container takes a little approximating. For example, in some countries the RD (road) Element might also be appropriate for other thoroughfares, like waterways or tunnels. 🌊
Fields that are identified to have the same meaning as one of the CAtypes SHOULD be directly mapped to that CAtype Element. 💅
Where CAtype usage diverges from the original specification, the mapping definition of Fields that are mapped to that Element SHOULD include a discussion of the differences. 🧐
Fields that do not fit into an existing CAtype:
Even though the list of CAtypes could be extended, it's not feasible to add new Elements for every new Field in every data source in every country 😭 So unless new generic CAtypes are specified by the IETF, only existing Elements can be used, which leaves these options:
- Concatenate several civic address Fields into a single PIDF-LO Element (define delimiters if applicable and make sure the separate civic address parts can be retrieved again).
- Use a PIDF-LO Element that is unused so far.
Note: Obviously, the first option is required if the number of Fields that are used in the mapping procedure is greater than the number of existing CAtype Elements. 🙈
Note that the xml:lang attribute should be present in PIDF-LO XML [W3C.REC-xml-20060816] documents, according to RFC 5139. 🌸
4.2. Guidelines for Individual Elements 🎀
The following sections talk about individual PIDF-LO Elements and what to think about for each one when you're defining civic address considerations. It is RECOMMENDED to follow a similar structure for considerations docs, so everything stays consistent bestie 🫶
4.2.1. Country 🌍
The country Element must hold the alpha-2 codes from ISO 3166-1 [ISO3166-1] in uppercase characters, as clarified in Section 3.3 of RFC 5139 [RFC5139].
This Element cannot be redefined on a national basis, since it identifies the country itself 💜 It's used to figure out which national mapping for civic addresses was used in a specific PIDF-LO.
Example for Austria: <country>AT</country>
4.2.2. Country Subdivisions A1-A6 🗺️
The Elements A1 to A6 hold national subdivision identifiers, with A1 holding the top-level subdivision identifier. A1 may either contain the second part of ISO 3166-2 [ISO3166-2] (see Section 3.4 of RFC 5139 [RFC5139]) or other values as described in the particular address considerations document. Elements "A2" to "A6" may contain additional levels of subdivisions (see Section 2.2.1 of RFC 4119).
For A1, an address considerations document MUST state whether ISO 3166-2 codes are to be used exclusively. Alternatively, it should define a list of values to be used (for example, subdivision names). Either way, A1 MUST NOT be redefined for any use other than describing top-level subdivisions. 🙅♀️
For each of the A2 - A6 Elements that are required or optional, the document SHOULD define the set of allowed values, either by listing them or by referring to such a list. ⭐
Example for Austria:
A1 province (Bundesland)
A2 political district (politischer Bezirk) name or identifier
A3 commune (Gemeinde) name or identifier
A4 village (Ortschaft) name or identifier
A5 cadastral municipality (Katastralgemeinde) name or identifier
A6 must not be used. For more details, see the example in Appendix
A.4.2.4.2.3. Road and Street Names 🛣️
PIDF-LO contains the following Elements related to road names: RD, RDSEC, RDBR, RDSUBADDR, PRM, POM (Sections 3.1 and 3.2 of RFC 5139 [RFC5139]) and PRD, POD, STS (Sections 3.4 of [RFC4776]). Note: the use of the A6 Element for street names is not valid any more (Section 3.2 of RFC 5139 [RFC5139]). 🙃
Besides the basic specification of which of those Elements are required, optional, or not to be used, an address considerations document may also describe more complicated dependencies. For example, "RD is optional, but required if any other road name Element is used." 🧩
For any required or optional Element, the relation of that Element to the Fields of the data source used MUST be described. Special considerations (like concatenating Fields into an Element) should also be described, if they apply. The usage of the Element STS (street suffix) SHOULD be consistent. If no suffixes are known in a data source, or it's common to write the street name and the suffix together, the STS Element SHOULD be left out completely. If suffixes may be abbreviated, the common abbreviations SHOULD be defined. 📝
Example for Austria:
RD: street nameAll other road Elements must not be used. Street suffixes are already included in the "street name" Field and must not be abbreviated. 🚫
4.2.4. House Numbers 🏠
PIDF-LO specifies two Elements related to house numbers: HNO ("house number", numeric part only) and HNS ("house number suffix") (see Section 3.4 of RFC 4776). However, in many countries house numbers have a more complex format. In any case, a clear definition is REQUIRED to minimize the potential for confusion. 🔢
An address considerations document should provide the following information about house numbers. If the structure of house numbers fits the HNO/HNS structure, the document MUST mandate that those Elements be used as described in RFC 4776. If the structure of house numbers doesn't directly fit into those two Elements, the document MUST define strategies for mapping source Fields into Elements. Besides HNO and HNS, LOC and BLD could be considered for carrying house number information. ✨
The document SHOULD describe whether or not abbreviations of house number information are valid. If abbreviations are used, they MUST be clearly defined. If house numbers consist of more than one number, or if multiple prefixes and suffixes may coexist, a delimiter symbol and a clear rule on how to concatenate all of this data into the HNO and HNS Element might be necessary. Whenever you concatenate data into one Element, keep in mind that the location recipient might want to separate the data again. 🧠
Example from Austria:
HNO: concatenate all the data Fields of Austrian house numbers into
this single PIDF-LO Element in a defined order with delimiter
symbols (see Appendix A.4.4 for the complete definition).
HNS: usage not allowed since there may be multiple suffixes for the
different parts of the house number.LOC and BLD are not to be used to reflect house number information. 🙅♀️
4.2.5. Local Names 🌾
PIDF-LO contains three Elements to reflect local names: LMK, LOC, and NAM (Section 3.4 of RFC 4776). Local names may be really important for identifying a location. They can either coexist with a valid civic address or (in some cases) have no address assigned, in which case the local name itself identifies the location. In rural regions, for example, a farm name may be more common than a street address for identifying a location. Landmarks typically don't have any civic address information assigned. So local names may help find a "street name" type address, but they might also be the authoritative (and only) civic location information. 🏞️
For any required or optional Element out of LMK, LOC, or NAM, the considerations document should state potential values (source data) for the Element. If an Element may have multiple values, a concatenation/selection strategy should be described. Concatenation using ";" as a separator is recommended, unless this character also appears in the source Fields. 🪄
If local name information and "common" address information are both available and used, the document SHOULD discuss the relationship between those two types of address information and the expected behavior of location recipients. 🤝
Example from Austria:
NAM: contains the "Vulgoname" (local name); multiple local names are
separated by a semicolon (if applicable).
LMK: contains the farm name (just one name possible) (if applicable).
LOC: can be used without restriction for additional location
information (as per RFC 4119).The "Vulgoname" is useful for identifying the location within its locality, since official addresses (especially in rural regions) might not be well known. 🐄
4.2.6. Floors 🛗
PIDF-LO defines the Element FLR to hold floor information but does not further specify its content. Section 2.1 of RFC 3825 provides guidance about floor numbering, but it isn't directly related to PIDF-LO. 🔎
An address considerations document SHOULD clearly specify how to express floors using the FLR Element. Following the guidance above is RECOMMENDED. However, local nomenclature might require a completely different system. The document SHOULD specify whether only numbers, text, or both are allowed in the FLR Element. If there are standard values for certain floors, they SHOULD be listed. Abbreviations SHOULD be avoided, unless they are the primary (well-known) way of identifying floors. 🪜
Example from Austria:
If floor numbers are to be mapped, the FLR Element MUST be used. Numbers and text are both allowed. The first floor (<FLR>1</FLR>) is the first "full" floor above the floor at street level. The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>. There might be intermediate floors, especially between the floor at street level and the "first floor". Such intermediate floors have names like "Mezzanine", "Erster Halbstock" ("first half floor"), or "Zweiter Halbstock" ("second half floor"), and they have local meanings. 💖
4.2.7. Address Codes ✨
Okay so some countries have address codes 🏢 for things like estates, buildings, or usable units. These codes identify an address record, and they MAY go in the ADDCODE Element in PIDF-LO 💖. They help the location recipient figure out where someone is and find the original record in the data source. Depending on the type of code, the code alone (no other Elements!) might even be enough to fully identify an address within a country 🤯.
In those cases, a PIDF-LO with just the country and ADDCODE Elements might give enough info to retrieve a civic address, as long as the location recipient has access to the right source database 🗂️.
A civic address considerations document SHOULD specify whether and in which applications the use of the ADDCODE Element is allowed. If ADDCODE is used, its relation to the remaining Elements MUST be clearly stated. If several namespaces for address codes exist in a country, a mechanism to distinguish the different code spaces MUST be described. Bestie, this part is so important 😤🫶.
Examples from Austria:
Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode (AdrsubCD), Objektnummer (ObjNr), and Nutzungseinheitenlaufnummer (NtzLnr). 🇦🇹
The following format SHOULD be used:
<ADDCODE>AdrCD=1234567;AdrsubCD=123;
ObjNr=2333211;NtzLnr=0001</ADDCODE>4.2.8. Other Elements 🧚
This section lists all the PIDF-LO Elements we haven't covered yet. 📋
To specify the location inside a building, these Elements can be useful:
UNITROOMSEAT
The following Elements are used for postal codes 📮:
PCPCNPOBOX
To describe the place-type or the building, these Elements are available:
PLC- Place-type (for allowed values, refer to the IANA registry defined in [RFC4589])BLD- Building (structure)
For any of those Elements that are required or optional in a mapping, the semantics of its contents must be described if it differs from the definition in the PIDF-LO base documents. Don't skip this, it's giving homework energy 📝.
It is RECOMMENDED that the Elements SEAT, UNIT, and ROOM remain to be used for identifying a location inside a building. They MAY be used by the owner of the respective building if a considerations document does not restrict their use. For example, an airport could decide to place the gate number in the UNIT Element, and a location recipient could identify that PIDF-LO by the value of the PLC Element ✈️. The name of the airport could be placed in NAM 🛫.
5. Security Considerations 🔐
RFC 4119 contains general security considerations for handling PIDF-LOs. Read it, obsessed with it, and never handle PIDF-LOs without it 😭🔥.
6. IANA Considerations 📚
IANA has created the registry "PIDF-LO Civic Address Considerations Registry", according to the following definitions. Furthermore, this document registers a civic address considerations document for Austrian addresses, as provided in the Appendix of this document, and also registers the considerations of RFC 4776 as obsolete 🦋.
6.1. PIDF-LO Civic Address Considerations Registry 🗃️
6.1.1. Structure
The IANA registry contains the following fields:
- Country-Code: either the ISO 3166 alpha-two code of the country to which the consideration applies, or "other" in case the considerations document is not specific to a particular country. This field is to be defined by the requestor.
- Serial Number: a number that uniquely identifies a considerations document within a certain "Country-Code" field value. Serial Numbers are sequentially assigned by IANA per Country-Code value, start at zero, and are never reused.
- Reference to specification: this field contains a reference to the considerations document. The xref type "rfc" should be used for referencing to RFCs, while other documents should use the "uri" type.
- Requestor: the author of the document.
- Status: one of either "active" or "obsolete". When the document is registered by IANA, the status is first set to "active" by IANA. Experts may later request changing the status to "obsolete", especially if there is an updated version of the considerations document available. Authors of considerations documents must contact the experts if they wish to change the status of the document.
Note: the combination of Country-Code and Serial Number fields uniquely identifies a considerations document in the registry (for example, AT-0, US-0, US-1, or other-0). 💅
6.1.2. Registration Template
For registration of address considerations documents in the registry, requesters SHOULD use the following template. The template SHOULD be contained in the considerations document itself 📝.
<record>
<country> <!-- Country-Code --> </country>
<serial> <!-- assigned by IANA --> </serial>
<!-- reference to document -->
<xref type="uri" data="http://www.example.org/civicaddr/"/>
<!-- record requesters -->
<xref type="person" data="John_Doe"/>
<xref type="person" data="Jane_Dale"/>
<status> <!-- assigned by IANA --> </status>
</record>
<people>
<person id="John_Doe">
<name> <!-- Firstname Lastname --> </name>
<org> <!-- Organization Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated>
</person>
<!-- repeat person section for each person -->
</people>6.1.3. Registry Location 📍
Approved registrations are published in the IANA registry named "PIDF-LO Civic Address Considerations Registry", which is available from http://www.iana.org. 🌸
Registrations are sorted in ascending order by Country-Code, and by Serial Number within Country-Code values. Registrations with a Country-Code of "other" are put at the end of the list.
6.1.4. Registration Procedure
Following the policies outlined in [RFC5226], new address considerations are added to the registry after Expert Review (see Section 4.1 in RFC 5226). The Expert will generally check if the submitted address considerations conform to the civic address guidelines in this document (see Section 4). If in doubt, the Expert SHOULD consult the GEOPRIV mailing list or its dedicated successor. If possible, the Experts SHOULD check the available documentation on which the address consideration is based 🔍.
6.2. Registration Request for Austria 🇦🇹
This document registers the civic address considerations for addresses from the official Austrian Building and Habitation registry, according to the registration procedure described above. The required information is contained in Appendix A 🎀.
6.3. Registration of the Considerations in RFC 4776 as Obsolete 🙈
Since this document updates RFC 4776, the considerations on the subdivision Elements in Section 3.4 of RFC 4776 for Canada, Germany, Japan, Korea, and the United States are obsolete. The following IANA registration records register them in the IANA registry as obsolete. Iconic behaviour 👑.
Canada:
<record>
<country>CA</country>
<serial>0</serial>
<xref type="rfc" data="rfc4776"/>
<xref type="person" data="Henning_Schulzrinne"/>
<status>obsolete</status>
</record>
<people>
<person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name>
<org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated>
</person>
</people>Germany:
<record>
<country>DE</country>
<serial>0</serial>
<xref type="rfc" data="rfc4776"/>
<xref type="person" data="Henning_Schulzrinne"/>
<status>obsolete</status>
</record>
<people>
<person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name>
<org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated>
</person>
</people>Japan:
<record>
<country>JP</country>
<serial>0</serial>
<xref type="rfc" data="rfc4776"/>
<xref type="person" data="Henning_Schulzrinne"/>
<status>obsolete</status>
</record>
<people>
<person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name>
<org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated>
</person>
</people>Korea:
<record>
<country>KR</country>
<serial>0</serial>
<xref type="rfc" data="rfc4776"/>
<xref type="person" data="Henning_Schulzrinne"/>
<status>obsolete</status>
</record>
<people>
<person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name>
<org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated>
</person>
</people>United States:
<record>
<country>US</country>
<serial>0</serial>
<xref type="rfc" data="rfc4776"/>
<xref type="person" data="Henning_Schulzrinne"/>
<status>obsolete</status>
</record>
<people>
<person id="Henning_Schulzrinne">
<name>Henning Schulzrinne</name>
<org>Columbia University</org>
<uri>mailto:hgs+geopriv@cs.columbia.edu</uri>
<updated>2009-01-09</updated>
</person>
</people>7. Acknowledgements 🫶
The authors would like to thank Martin Thomson and Richard Barnes for reviewing the document, and Gregor Jaenin for contributing insights into the Austrian civic address data format. Big thank-yous, besties 💖.
Appendix A. Civic Address Considerations Registration for the Austrian Building and Habitation Registry 🇦🇹✨
The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and habitation registry law) is the legal basis for the obligation to provide a registry of civic addresses, buildings, and their usable units (subdivisions of buildings). The registry is operated by "Statistik Austria GmbH", a fully governmentally owned company. The local administrations of individual townships are responsible for keeping records in the registry up to date 🏛️.
The data format definition for the individual records is publicly available (data access itself is, however, restricted). Hence, a uniform address database for the whole of Austria is available. A detailed description of the Statistik Austria civic address data format is contained in Appendix A.1 🌈.
A.1. Civic Address Format in Austria ✨
okay so this section is all about how Austria does addresses, and bestie, it is WILD 😭 Statistik Austria keeps data on estates, buildings, and usable units [merkmalskatalog] 🏘️. One estate can have any number of buildings. Apartment houses with more than one staircase get split into separate buildings at every staircase, and a building can have several usable units, like apartments inside an apartment house 🏢. One building might have more than one address, but it always has at least one 🫶. Below are the address Fields for estates (Table 1), buildings (Table 2), and usable units (Table 3) 💜.
The ADDCODE, A5, and PCN Elements are optional, and the other Elements MUST be used if the data source contains their corresponding Fields. The Elements A1 and A2 (not listed in the tables) SHOULD also be used if data is available. Exception: when you're using the address codes only (access to the codes is necessary for the creator and recipient of the location information), just the ADDCODE and country Elements are mandatory, and the other Elements can be used optionally, of course 🎀.
+-------------------------+-------------------------------+---------+
| Statistik Austria name | Explanation | PIDF-LO |
| | | Element |
+-------------------------+-------------------------------+---------+
| Adresscode | address identifier | ADDCODE |
| | | |
| Gemeindename, | commune name and identifier | A3 |
| Gemeindekennziffer | | |
| | | |
| Ortschaftsname, | village name and identifier | A4 |
| Ortschaftskennziffer | | |
| | | |
| Strassenname, | street name and identifier | RD |
| Strassenkennziffer | | |
| | | |
| Katastralgemeindename, | cadastral municipality and | A5 |
| Katastralgemeindenummer | identifier | |
| | | |
| Hausnummerntext | text in front of the house | HNO |
| | number | |
| | | |
| Hausnummer - 1. Teil - | first part of the house | HNO |
| Nummer | number, numeric | |
| | | |
| Hausnummer - 1. Teil - | first part of the house | HNO |
| Buchstabe | number, character | |
| | | |
| Hausnummer - | links first and Bis part of | HNO |
| Verbindungszeichen Teil | house number | |
| 1 -> Bis | | |
| | | |
| Hausnummer - Bis-Nummer | number of Bis part of house | HNO |
| | number | |
| | | |
| Hausnummer - | character of Bis part of | HNO |
| Bis-Buchstabe | house number | |
| | | |
| Hausnummernbereich | indicates if all house | HNO |
| | numbers specified or just odd | |
| | or even numbers are stated | |
| | | |
| Postleitzahl | postal code | PC |
| | | |
| Postleitzahlengebiet | postal community code | PCN |
| | | |
| Vulgoname | local name | NAM |
| | | |
| Hofname | farm name | LMK |
+-------------------------+-------------------------------+---------+
Table 1: Civic Address Fields for Estates+------------------------+--------------------------------+---------+
| Statistik Austria name | Explanation | PIDF-LO |
| | | Element |
+------------------------+--------------------------------+---------+
| Adresssubcode | address subcode | ADDCODE |
| | | |
| Objektnummer | object code | ADDCODE |
| | | |
| Hausnummer - | links Bis and second part of | HNO |
| Verbindungszeichen | house number | |
| Teil Bis -> Teil 2 | | |
| | | |
| Hausnummer - 2. Teil | second part of the house | HNO |
| - Nummer | number, numeric | |
| | | |
| Hausnummer - 2. Teil | second part of the house | HNO |
| - Buchstabe | number, character | |
| | | |
| Hausnummer - | links second and third part of | HNO |
| Verbindungszeichen | house number | |
| Teil 2-> Teil 3 | | |
| | | |
| Hausnummer - 3. Teil | third part of the house | HNO |
| - Nummer | number, numeric | |
| | | |
| Hausnummer - 3. Teil | third part of the house | HNO |
| - Buchstabe | number, character | |
| | | |
| Gebaeudeunterscheidung | for differentiation of | HNO |
| | buildings, e.g. Maierweg 27 | |
| | Hotel vs. Maierweg 27 | |
| | Appartmenthaus | |
| | | |
+------------------------+--------------------------------+---------+
Table 2: Additional Civic Address Fields for Buildings+-----------------------------+---------------------------+---------+
| Statistik Austria name | Explanation | PIDF-LO |
| | | Element |
+-----------------------------+---------------------------+---------+
| Nutzungseinheitenlaufnummer | usable unit code | ADDCODE |
| | | |
| Tuernummer | door number | HNO |
| | | |
| Topnummer | unit number | HNO |
| | | |
| Lagebeschreibung | for verbal description | HNO |
| | | |
| Lage | describes if the usable | FLR |
| | unit is in the basement, | |
| | mezzanine, attic floor, | |
| | ... (but not the floor | |
| | number) | |
| | | |
| Stockwerk | floor | FLR |
| | | |
+-----------------------------+---------------------------+---------+
Table 3: Additional Civic Address Fields for Usable UnitsNote: "floors" in Austria (as in most parts of Europe) are counted differently compared to the US. The "1st floor" in Austria is actually the floor above the floor at street level (2nd floor in US), not considering the fact that, in old buildings, there might be even more floors between street level and 1st floor, like "mezzanine" and "2nd mezzanine". So, an Austrian "1st floor" could well be the "4th floor" according to US nomenclature 🙈
According to Statistik Austria [adrwarten], 81.5% of Austrian addresses are of the simple type Musterstrasse 1 (Musterstrasse is an example street name) 🥰. 5% of all addresses have an additional character, like Musterstrasse 1b. 1% of Austrian addresses look like Musterstrasse 21A - 23A. For 8% of addresses, an additional separator is necessary, like Musterstrasse 10 Haus 1 Stiege 2, Musterstrasse 20 Gruppe A Reihe 1 Parzelle 13, or Musterstrasse 30 Weg 1 Parzelle 10. Very seldom, there are so-called special addresses (0.03%), for example Musterstrasse gegenueber 3A, meaning this address is actually opposite house number 3A 💀. Rather surprisingly, 4.47% of Austrian addresses contain the identifier of the estate since no house number is assigned at all, for example Musterstrasse GNR 1234, or Musterstrasse GNR .12/4 Kirche (this type of address is common for churches), or a real example in Stockerau: Kolomaniwoerth GNR 1583. This identifier is stored by Statistik Austria as Hausnummerntext. Otherwise, one could misinterpret this number as a house number, which would be definitely wrong 🙅♀️
A.2. Sample Addresses 🎀
okay so to make the Austrian civic address format click, here are some example addresses bestie 💅
1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1
Postleitzahl: 1234
Stadt: Musterstadt
Strasse: Hauptstrasse
Hausnummer - 1. Teil - Nummer: 1
Hausnummer - 1. Teil - Buchstabe: a
Hausnummer - Verbindungszeichen Teil 1 -> Bis: -
Hausnummer - 2. Teil - Nummer: 5
Hausnummer - 2. Teil - Buchstabe: a
Hausnummer - Verbindungszeichen Teil Bis -> Teil 2: Block
Hausnummer - 2. Teil - Nummer: 1
Hausnummer - 2. Teil - Buchstabe: b
Hausnummer - Verbindungszeichen Teil 2-> Teil 3: Haus
Hausnummer - 3. Teil - Nummer: 2
Hausnummer - 3. Teil - Buchstabe: c
Gebaeudeunterscheidung: Stiege 1
1234 Musterstadt, Musterstrasse 13 Hotel
Postleitzahl: 1234
Stadt: Musterstadt
Strasse: Musterstrasse
Hausnummer - 1. Teil - Nummer: 13
Gebaeudeunterscheidung: Hotel
6020 Innsbruck, Anichstrasse vor 35
Postleitzahl: 6020
Stadt: Innsbruck
Strasse: Anichstrasse
Hausnummerntext: vor ("in front of")
Hausnummer: 35
6173 Oberperfuss, Riedl 3097 (Pfarrkirche)
Postleitzahl: 6173
Stadt: Oberperfuss
Strasse: Riedl
Hausnummerntext: 3097
(since the estate identifier is 81305 3097, where 81305 is the
Katastralgemeindenummer (cadastral municipality), and no house
number is assigned)
Vulgoname: PfarrkircheA.3. Address Codes in Austria 🔢
Statistik Austria registers 4 codes: Adresscode, Adresssubcode, Objektnummer, and the Nutzungseinheitenlaufnummer. The Adresscode (7 digits) is a unique code for an address in Austria, and the Adressregister maps it to the civic address. ✨ If there is a building at an address, there is also an Adresssubcode (3 digits). Every building at an address gets its own Adresssubcode, assigned sequentially starting with 001, 002, 003, and so on, so buildings at the same address can be told apart.
Every building located in Austria also has its own unique code, the Objektnummer (7 digits). It identifies the building independent of the Adresscode, because addresses can change while the building sticks around 🏠 To tell apart multiple usable units inside a building, the Nutzungseinheitenlaufnummer (4 digits) is used. It's also assigned in sequential order for each building.
Besides that, every address and building is geocoded by Statistik Austria. So if every PIDF-LO carried data in the format of Statistik Austria, and every PSAP used the Statistik Austria database for mapping, a time-saving, definite mapping without irregularities could be achieved. 🙌
Besides these codes, Statistik Austria also maintains reference numbers for communes, localities, or streets, to mention just a few.
A.4. Austrian Addresses in PIDF-LO 🗺️
The following subsections define the mapping procedure.
A.4.1. Country 🇦🇹
The country Element for Austria must be set to AT, since this is the ISO 3166-1 [ISO3166-1] alpha-2 code for Austria.
<country>AT</country>The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119], and RFC 5139 [RFC5139] proposes to use uppercase characters only.
A.4.2. Country Subdivisions A1-A6 🧩
A1province (Bundesland), Section A.4.2.1A2political district name or identifier (politischer Bezirk), Section A.4.2.2A3commune name or identifier (Gemeinde), Section A.4.2.3A4village name or identifier (Ortschaft), Section A.4.2.4A5cadastral municipality name or identifier (Katastralgemeindename or Katastralgemeindenummer), Section A.4.2.5
Element A6 must not be used.
Last but not least, there's an exception for the Austrian capital, Vienna (Wien) 🌸 The city of Vienna is equal to its political district, and even the province is called Vienna. BUT Vienna is separated into 23 districts within that same political district, so an address in Vienna would look like:
<country>AT</country>
<A1>Wien</A1>
<A2>Wien</A2>
<A3>Wien</A3>
<A4>Favoriten</A4> or <A4>10<A4>
<A5>Inzersdorf Stadt<A5>The Element A4, which holds the city division, can hold the name or the number of the district.
A.4.2.1. A1 Element 🦋
As proposed in RFC 5139 [RFC5139], for the PIDF-LO Element A1, the second part of ISO 3166-2 [ISO3166-2] can be used. However, in Austria it's also common to write out the names of the states. Table 4 shows the possible values of the A1 Element for Austrian states.
+------------------------+--------------------------------+
| Bundesland | second part of ISO 3166-2 code |
+------------------------+--------------------------------+
| Burgenland | 1 |
| | |
| K=U+00E4rnten | 2 |
| | |
| Nieder=U+00F6sterreich | 3 |
| | |
| Ober=U+00F6sterreich | 4 |
| | |
| Salzburg | 5 |
| | |
| Steiermark | 6 |
| | |
| Tirol | 7 |
| | |
| Vorarlberg | 8 |
| | |
| Wien | 9 |
+------------------------+--------------------------------+
Table 4: A1 Element Format for Austria(Note: values are shown in UTF-8, which is recommended to be used for PIDF-LO. 💜)
A.4.2.2. A2 Element 🏛️
Names of the Austrian political districts are available at Statistik Austria [bezirke]. You can use these names, the unique code for the political district, or both for the A2 Element. If the content of the A2 Element is numeric, obviously the code is provided, since there's no political district in Austria with a number in its name. If both the name and the code are provided, they're separated by a semicolon, and the name must be listed first.
The district of "Bruck an der Leitha" could be represented by:
<A2>Bruck an der Leitha<A2>
or
<A2>307</A2>
or
<A2>Bruck an der Leitha;307</A2>A.4.2.3. A3 Element 🏘️
The Element A3 holds the Gemeindename (commune name), the identifier of the Gemeinde, or both, separated by a semicolon (the name must be listed first). If the content of the A3 Element consists of a number only, it's obvious that just the identifier is provided. Statistik Austria maintains a table with the Gemeindenamen and identifiers [gemeinden], which must be used as the content for the A3 Element; no other spelling is allowed. 🚫✏️
Sample:
<A3>Neusiedl am See</A3>
or
<A3>10713</A3>
or
<A3>Neusiedl am See;10713</A3>A.4.2.4. A4 Element 🌼
The Element A4 holds the Ortschaftsname (village name), the Ortschaftskennziffer (the identifier), or both, separated by a semicolon (the name must be listed first). If the content of the A4 Element consists of a number only, it's obvious that just the identifier is provided, since there are no Ortschaftsnamen in Austria that contain a number. Statistik Austria maintains a table with the Ortschaftsnamen and identifiers [ortschaften], which must be used as the content for the A4 Element; no other spelling is allowed.
Sample:
<A4>Wilfleinsdorf</A4>
or
<A4>03448</A4>
or
<A4>Wilfleinsdorf;03448</A4>A.4.2.5. A5 Element 🌿
The Element A5 holds the Katastralgemeindename (cadastral municipality), the Katastralgemeindenummer (the identifier), or both, separated by a semicolon (the name must be listed first). If the content of the A5 Element consists of a number only, it's obvious that just the identifier is provided, since there are no Katastralgemeindenamen in Austria that contain a number.
Sample (Vienna, Fuenfhaus):
<A5>Oberbaumgarten</A5>
or
<A5>1208</A5>
or
<A5>Oberbaumgarten;1208</A5>A.4.3. Road and Street Names 🛣️
The PIDF-LO Element RD holds the complete street name, including the street suffix. No abbreviations are allowed. No other Elements are needed for streets, and they must not be used.
A.4.4. House Numbers 🏠🔢
Statistik Austria lists 14 data Fields related to the house number of a building, plus another 5 Fields for distinguishing different usable units inside a building (including the floor, which has a separate Element in PIDF-LO). Unfortunately, PIDF-LO only defines a single house number Element (HNO, numeric part only) and a house number suffix Element (HNS). So this section defines a mapping to fit all the data: all house number data is concatenated into a single HNO Element, even though it's expected to hold the numeric part only. 😤
To allow automatic processing of the HNO Element, a semicolon must be used as the delimiter symbol (Austrian house numbers do not contain semicolons). The house number parts MUST be provided in the order in which they are listed by the Statistik Austria document [merkmalskatalog]. For user-interface representation, the semicolon-separated format can be transformed by replacing semicolons with spaces (multiple spaces should be combined), and no space should be present between a numeric part of a house number and its related character.
It is not allowed to use the HNS Element for Austrian addresses, since some addresses don't have just a single suffix. 🙅♀️
The house number "vor 1 - 1A" (consisting of a house number text "vor", first part of the house number numeric "1", "-" as the link of the first and Bis part, "1" as house number Bis part numeric, and "A" as character of the Bis part) would be mapped to:
<HNO>vor;1;;-;1;A;;;;;;;;;;;</HNO>A.4.5. Local Names 🌷
NAM: contains the Vulgoname (local name); multiple local names are separated by a semicolon (if applicable).LMK: contains the farm name (just one name possible) (if applicable).LOC: can be used without restriction for additional location information (as per RFC 4119). 📍
A.4.6. Floors 🪜
The floor Element may contain numbers or text describing the floor. The first floor (<FLR>1</FLR>) is the floor above the floor at street level. The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>. Other floors may have names like mezzanine, for example. The Statistik Austria data Fields Lage and Stockwerk are concatenated if necessary. ✨
A.4.7. Additional Code Element ✨
okay so the additional code Element is where Statistik Austria's codes go 🇦🇹🫶 There's an Adresscode, an Adresssubcode, an Objektnummer, and a Nutzungseinheitenlaufnummer. These unique codes pin down the exact location. Honestly, the codes alone would be enough, but the location recipient would need access to the Statistik Austria database to decode them 💅
If the additional code in a PIDF-LO document is going to hold those Statistik Austria codes, use this format:
<ADDCODE>AdrCD=1234567;AdrsubCD=123;
ObjNr=2333211;NtzLnr=0001</ADDCODE>You don't have to include every code, but there are some rules 👀 The Adresssubcode can't be used without an Adresscode. Statistik Austria sets more restrictions on top of these. If you set the country Element to AT (see Section 4.2.1) to mark an Austrian address, the Additional Code Element is expected to hold Statistik Austria codes only 🇦🇹✨ When you make PIDF-LO documents using Statistik Austria address codes, the country and ADDCODE Elements are mandatory, no exceptions 💀
A.4.8. Other Elements 🍓
The PC and PCN Elements can hold data from Statistik Austria, and the POBOX Element can be used if the post office assigned a post office box. At least the PC Element should be present, so don't skip it 🫶
PC: Postleitzahl (postal code)
PCN: Postleitzahlengebiet (postal community name)
POBOX: PostfachThe UNIT, ROOM, SEAT, PLC, and BLD Elements can be used with no further restriction 🌸
A.4.9. Elements Not to Be Used 🚫
These ones are a hard pass, bestie, so don't touch them 😭
A6
STS
HNS
PRD
POD
RDBR
RDSUBBR
PRM
POMA.5. Example 🎀
this section shows an example of how an Austrian address gets mapped to PIDF-LO. Let's go 🦋
The address:
Bundesland: Wien
Politischer Bezirk: Wien
Gemeindename: Wien
9. Bezirk
Strasse: Lazarettgasse
Hausnummer - 1. Teil - Nummer: 13
Hausnummer - 1. Teil - Buchstabe: A
Hausnummer - Verbindungszeichen Teil 1-Bis: -
Hausnummer - Bis-Nummer: 13
Hausnummer - Bis-Buchstabe: C
Postleitzahl: 1090And the PIDF-LO:
<?xml version="1.0" encoding="UTF-8" ?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
entity="pres:123@examplehost">
<tuple id="abcd123456">
<status>
<gp:geopriv>
<gp:location-info>
<cl:civicAddress xml:lang="de">
<cl:country>AT</cl:country>
<cl:A1>Wien</cl:A1>
<cl:A2>Wien</cl:A2>
<cl:A3>Wien</cl:A3>
<cl:A4>9</cl:A4>
<cl:RD>Lazarettgasse</cl:RD>
<cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</cl:HNO>
<cl:PC>1090</cl:PC>
</cl:civicAddress>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>yes</gp:retransmission-allowed>
<gp:retention-expiry>2009-11-10T12:00:00Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2009-02-09T12:00:00Z</timestamp>
</tuple>
</presence>A.6. IANA Registration Record 📋
Here's the registry record, plus the two people who requested it 💖
<record>
<country>AT</country>
<serial>0</serial>
<!-- reference to document -->
<xref type="rfc" data="rfc5774"/>
<!-- record requesters -->
<xref type="person" data="Alexander_Mayrhofer"/>
<xref type="person" data="Karl_Heinz_Wolf"/>
<status>active</status>
</record>
<people>
<person id="Alexander_Mayrhofer">
<name>Alexander Mayrhofer</name>
<org>nic.at GmbH</org>
<uri>mailto:alexander.mayrhofer@nic.at</uri>
<updated>2009-01-09</updated>
</person>
<person id="Karl_Heinz_Wolf">
<name>Karl Heinz Wolf</name>
<org>nic.at GmbH</org>
<uri>mailto:karlheinz.wolf@nic.at</uri>
<updated>2009-01-09</updated>
</person>
</people>Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
[RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[W3C.REC-xml-20060816] W3C, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
Informative References 🌈
[adrwarten] Statistik Austria, "Handbuch Adress-GWR-Online Teil A Theoretisches Handbuch Kapitel 2 Warten von Adressen im Adress-GWR-Online", Jan 2005.
[merkmalskatalog] Statistik Austria, "Handbuch Adress-GWR-Online Teil C Anhang 2 Merkmalskatalog", Sept 2004.
[ISO3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166-1:1997, 1997.
[ISO3166-2] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code", ISO Standard 3166-2:1998, 1998.
[bezirke] Statistik Austria, "Politische Bezirke, Gebietsstand 2008", Feb 2008.
[gemeinden] Statistik Austria, "Gemeindeliste sortiert nach Gemeindekennziffer, Gebietsstand 2008", Feb 2008.
[ortschaften] Statistik Austria, "Gemeinden mit Ortschaften und Postleitzahlen, Gebietsstand 2008", Feb 2008.
Authors' Addresses ✨
Karl Heinz Wolf
nic.at GmbH
Karlsplatz 1/2/9
Wien A-1010
Austria
Phone: +43 1 5056416 37
EMail: karlheinz.wolf@nic.at
URI: http://www.nic.at/
Alexander Mayrhofer
nic.at GmbH
Karlsplatz 1/2/9
Wien A-1010
Austria
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@nic.at
URI: http://www.nic.at/📦 where this page comes from
- ietf: rfc5774 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms