Internet Engineering Task Force (IETF) K. Wolf Request for Comments: 5774 A. Mayrhofer BCP: 154 nic.at Updates: 4776 March 2010 Category: Best Current Practice ISSN: 2070-1721 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition
AbstractThis document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5774. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................3 2. Terminology .....................................................4 3. Requirements ....................................................4 4. Specifying PIDF-LO Element Usage ................................5 4.1. General Considerations and Workflow ........................5 4.2. Guidelines for Individual Elements .........................7 4.2.1. Country .............................................7 4.2.2. Country Subdivisions A1-A6 ..........................7 4.2.3. Road and Street Names ...............................8 4.2.4. House Numbers .......................................8 4.2.5. Local Names .........................................9 4.2.6. Floors .............................................10 4.2.7. Address Codes ......................................10 4.2.8. Other Elements .....................................11 5. Security Considerations ........................................12 6. IANA Considerations ............................................12 6.1. PIDF-LO Civic Address Considerations Registry .............12 6.1.1. Structure ..........................................12 6.1.2. Registration Template ..............................13 6.1.3. Registry Location ..................................14 6.1.4. Registration Procedure .............................14 6.2. Registration Request for Austria ..........................14 6.3. Registration of the Considerations in RFC 4776 as Obsolete ..................................................14 7. Acknowledgements ...............................................17 Appendix A. Civic Address Considerations Registration for the Austrian Building and Habitation Registry .............18 A.1. Civic Address Format in Austria ...........................18 A.2. Sample Addresses ..........................................22 A.3. Address Codes in Austria ..................................23 A.4. Austrian Addresses in PIDF-LO .............................23 A.4.1. Country ............................................23 A.4.2. Country Subdivisions A1-A6 .........................24 A.4.3. Road and Street Names ..............................27 A.4.4. House Numbers ......................................27 A.4.5. Local Names ........................................28 A.4.6. Floors .............................................28 A.4.7. Additional Code Element ............................28 A.4.8. Other Elements .....................................29 A.4.9. Elements Not to Be Used ............................29 A.5. Example ...................................................29 A.6. IANA Registration Record ..................................30 Normative References ..............................................31 Informative References ............................................32
RFC4119] is an object format for carrying geographical information on the Internet. PIDF-LO can contain civic address information and supports a range of "civic address types" (CAtypes) to hold the individual attributes of such addresses (see Section 2.2.1 of [RFC4119] and Section 3.1 of [RFC5139]). In many use cases, PIDF-LOs are populated with data from long- established sources, like postal and governmental building registers, line information databases and yellow/white pages of infrastructure providers, or official residents registers. The structure and format of data from such sources is almost always different from PIDF-LO's CAtypes definition -- additionally, the structure and format of those sources differ from country to country. To make use of such existing data sources, transposing that data into PIDF-LO format is required. With no guidelines available on how to map source Fields into CAtype Elements, different creators of PIDF-LO documents might end up with different results, even when using the same data source, which reduces interoperability and increases the risk of misinterpretation by recipients. Therefore, civic address considerations are necessary to ensure uniform usage of PIDF-LO Elements for such data sources. [RFC4776] explicitly requests such documents to be provided, but defines neither their structure nor a way to publish them. This memo provides documentation on how to create such civic address considerations, and IANA has created a registry to store references to such documents. Furthermore, civic address considerations for Austria are provided in Appendix A and have been registered in the IANA registry. Section 3.4 of [RFC4776] contains some example considerations regarding the use of administrative subdivision Elements for Canada, Germany, Japan, Korea, and the United States. This document registers these examples with IANA as "obsolete" (see Section 6.3). Section 3.4 of [RFC4776] also contains instructions on the creation of civic address considerations documents on page 8. This document updates that section and replaces said instructions with Sections 4 and 5 of this memo. The guidelines in this document have been created with a focus on formal application of PIDF-LO (such as conveying location during an emergency call). It is not intended to forbid other, more informal uses of PIDF-LO that may not follow any formal mapping
specifications. An example use case of such informal usage may be the transmission of PIDF-LO documents during an instant-messaging session between humans. Such use may, however, imply some drawbacks, like prohibiting automatic processing of civic addresses from such a PIDF-LO. RFC2119]. In addition, this document uses "Field" to refer to a field of a civic address data source, and "Element" to refer to a CAtype Element of a PIDF-LO.
o In many cases, data sources used in the mapping process might be subject to access restrictions. Such restrictions (as imposed on the original data) MUST also be imposed on the resulting PIDF-LO documents. The considerations document SHOULD note such restrictions in its Security Considerations section. Although the mapping is defined in a national way and the actual meaning of several PIDF-LO Elements may not be clear to an outsider, at least the country Element tells in what context this PIDF-LO was created. In case of emergency calls, a PIDF-LO would just be passed to a Public Safety Answering Point (PSAP) in the same country as the location generator anyway. However, in a border region there might be exceptions and the PIDF-LO could be sent to a neighboring country. The PIDF-LO can still be passed on to a PSAP in the right country (based on the country Element), or the PSAP might be aware of the mapping scheme used in the neighboring country. A consistent mapping is also very important for checking if two PIDF- LO documents describe the same location. When civic address Fields are put into different PIDF-LO Elements, it may be difficult to identify whether or not two PIDF-LOs describe identical addresses.
4. Provide a list of all CAtypes registered and describe their level of usage in this mapping (or combine it with the list of Fields above and clearly list which Elements are not used for the mapping procedure). For Elements that are not described in detail, state whether they MUST NOT be used at all or whether they may be used without further restriction. 5. Provide examples of source data and mapping results. Civic address Elements are designed to be generic containers. In some cases, Fields clearly correspond to such a container; however, in some other cases, identifying the correct container might require some approximation. For example, in some countries the RD (road) Element might also be appropriate for other thoroughfares, like waterways or tunnels. Fields that are identified to have the same meaning as one of the CAtypes SHOULD be directly mapped to that CAtype Element. Where CAtype usage diverges from the original specification, the mapping definition of Fields that are mapped to that Element SHOULD include a discussion of the differences. Fields that do not fit into an existing CAtype: Even though the list of CAtypes could be extended, it is not feasible to add new Elements for every new Field in every data source in every country. Therefore, unless new generic CAtypes are specified by the IETF, only existing Elements can be used, which leaves the following options: 1. Concatenate several civic address Fields into a single PIDF-LO Element (define delimiters if applicable and make sure the separate civic address parts can be retrieved again). 2. Use a PIDF-LO Element that is unused so far. Note: Obviously, the first option is required if the number of Fields that are used in the mapping procedure is greater than the number of existing CAtype Elements. Note that the xml:lang attribute should be present in PIDF-LO XML [W3C.REC-xml-20060816] documents, according to RFC 5139.
ISO3166-1] in uppercase characters, as clarified in Section 3.3 of RFC 5139 [RFC5139]. This Element cannot be redefined on a national basis since it identifies the country itself. This Element is used to identify which national mapping for civic addresses has been used in a specific PIDF-LO. Example for Austria: <country>AT</country> ISO3166-2] (see Section 3.4 of RFC 5139 [RFC5139]) or other values as described in the particular address considerations document. Elements "A2" to "A6" may contain additional levels of subdivisions (see Section 2.2.1 of RFC 4119). For A1, an address considerations document MUST state whether ISO 3166-2 codes are to be used exclusively; alternatively, it should define a list of values to be used (for example, subdivision names). In either case, A1 MUST NOT be redefined for any other use than describing top-level subdivisions. For each of the A2 - A6 Elements that are required or optional, the document SHOULD define the set of allowed values, either by listing them or by referring to such a list. Example for Austria: A1 province (Bundesland) A2 political district (politischer Bezirk) name or identifier A3 commune (Gemeinde) name or identifier A4 village (Ortschaft) name or identifier A5 cadastral municipality (Katastralgemeinde) name or identifier
A6 must not be used. For more details, see the example in Appendix A.4.2. 3.1 and 3.2 of RFC 5139 [RFC5139]) and PRD, POD, STS (Sections 3.4 of [RFC4776]). Note: the use of the A6 Element for street names is not valid any more (Section 3.2 of RFC 5139 [RFC5139]). Besides the basic specification of which of those Elements are required, optional, or not to be used, an address considerations document may also describe more complicated dependencies (for example, "RD is optional, but required if any other road name Element is used"). For any required or optional Element, the relation of those Elements to Fields of the data source used MUST be described, as should special considerations (like concatenation of Fields into an Element), if they apply. The usage of the Element STS (street suffix) SHOULD be consistent. In case no suffixes are known in a data source, or it is common to write the street name and the suffix together, the STS Element SHOULD be left out completely. If suffixes may be abbreviated, the common abbreviations SHOULD be defined. Example for Austria: RD: street name All other road Elements must not be used. Street suffixes are already included in the "street name" Field and must not be abbreviated. Section 3.4 of RFC 4776). However, in many countries house numbers have a more complex format. In any case, a clear definition is REQUIRED to minimize the potential for confusion. An address considerations document should provide the following information with regards to house numbers: if the structure of house numbers fits the HNO/HNS structure, the document MUST mandate to use those Elements as described in RFC 4776. If the structure of house numbers does not directly fit into those two Elements, the document
MUST define strategies on how to map source Fields into Elements. Besides HNO and HNS, LOC and BLD could be considered for carrying house number information. The document SHOULD describe whether or not abbreviations of house number information is valid. If abbreviations are used, they MUST be clearly defined. If house numbers consist of more than one number, or if multiple prefixes and suffixes may coexist, a delimiter symbol and a clear rule on how to concatenate all this data into the HNO and HNS Element might be necessary. Whenever concatenating data into one Element, keep in mind that the location recipient might want to separate the data again. Example from Austria: HNO: concatenate all the data Fields of Austrian house numbers into this single PIDF-LO Element in a defined order with delimiter symbols (see Appendix A.4.4 for the complete definition). HNS: usage not allowed since there may be multiple suffixes for the different parts of the house number. LOC and BLD are not to be used to reflect house number information. Section 3.4 of RFC 4776). Such local names may be of importance for the identification of a location and may either coexist with a valid civic address or (in some cases) have no address assigned, in which case the local name, itself, identifies the location. In rural regions, for example, a farm name may be more common than a street address to identify a location. Landmarks typically don't have any civic address information assigned. Therefore, local names may assist in finding a "street name" type address, but they might also be the authoritative (and only) civic location information. For any required or optional Element out of LMK, LOC, or NAM, the considerations document should state potential values (source data) for the Element. In the case that multiple values for an Element may occur, a concatenation/selection strategy should be described. Concatenation using ";" as a separator is recommended, unless this character also appears in the source Fields. If local name information and "common" address information is both available and used, the document SHOULD discuss the relationship between those two address information types and the expected behavior of location recipients.
Example from Austria: NAM: contains the "Vulgoname" (local name); multiple local names are separated by a semicolon (if applicable). LMK: contains the farm name (just one name possible) (if applicable). LOC: can be used without restriction for additional location information (as per RFC 4119). The "Vulgoname" is useful to identify the location within its locality, since official addresses (especially in rural regions) might not be well known. Section 2.1 of RFC 3825 provides guidance about floor numbering but is not directly related to PIDF- LO. An address considerations document SHOULD clearly specify how to express floors using the FLR Element. Following the above-mentioned guidance is RECOMMENDED; however, local nomenclature might require a completely different system. The document SHOULD specify whether only numbers, text, or both are allowed in the FLR Element. If there are standard values for certain floors, they SHOULD be listed. Abbreviations SHOULD be avoided, unless they are the primary (well- known) way of identifying floors. Example from Austria: If floor numbers are to be mapped, the FLR Element MUST be used. Numbers and text are both allowed. The first floor (<FLR>1</FLR>) is the first "full" floor above the floor at street level. The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>. There might be intermediate floors, especially between the floor at street level and the "first floor". Such intermediate floors have names like "Mezzanine", "Erster Halbstock" ("first half floor"), or "Zweiter Halbstock" ("second half floor"), and have local meanings.
data source. Depending on the type of code, the code alone (without any other Elements) may even be sufficient to fully identify an address within a country. In such cases, a PIDF-LO containing just the country and ADDCODE Elements might provide enough information to retrieve a civic address, given the location recipient has access to the respective source database. A civic address considerations document SHOULD specify whether and in which applications the use of the ADDCODE Element is allowed. If ADDCODE is used, its relation to the remaining Elements MUST be clearly stated. If several namespaces for address codes exist in a country, a mechanism to distinguish the different code spaces MUST be described. Examples from Austria: Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode (AdrsubCD), Objektnummer (ObjNr), and Nutzungseinheitenlaufnummer (NtzLnr). The following format SHOULD be used: <ADDCODE>AdrCD=1234567;AdrsubCD=123; ObjNr=2333211;NtzLnr=0001</ADDCODE>
To describe the place-type or the building, the following Elements are available: o PLC - Place-type (for allowed values, refer to the IANA registry defined in [RFC4589]) o BLD - Building (structure) For any of those Elements that are required or optional in a mapping, the semantics of its contents must be described if it differs from the definition in the PIDF-LO base documents. It is RECOMMENDED that the Elements SEAT, UNIT, and ROOM remain to be used for identifying a location inside a building. They MAY be used by the owner of the respective building if a considerations document does not restrict their use. For example, an airport could decide to place the gate number in the UNIT Element and a location recipient could identify that PIDF-LO by the value of the PLC Element. The name of the airport could be placed in NAM. RFC 4119 contains general security considerations for handling PIDF- LOs. RFC 4776 as obsolete.
o Reference to specification: this field contains a reference to the considerations document. The xref type "rfc" should be used for referencing to RFCs, while other documents should use the "uri" type. o Requestor: the author of the document. o Status: one of either "active" or "obsolete". When the document is registered by IANA, the status is first set to "active" by IANA. Experts may later request changing the status to "obsolete", especially if there is an updated version of the considerations document available. Authors of considerations documents must contact the experts if they wish to change the status of the document. Note: the combination of Country-Code and Serial Number fields uniquely identifies a considerations document in the registry (for example, "AT-0", "US-0", "US-1", or "other-0"). 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>
http://www.iana.org. Registrations are sorted by ascending order by the Country-Code and by Serial Number within Country-Code values. Registrations with Country-Code of "other" are put at the end of the list. 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. Appendix A. 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.
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:firstname.lastname@example.org</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:email@example.com</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:firstname.lastname@example.org</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:email@example.com</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:firstname.lastname@example.org</uri> <updated>2009-01-09</updated> </person> </people>
Appendix A. Civic Address Considerations Registration for the Austrian Building and Habitation RegistryThe 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. merkmalskatalog]. On a single estate there may be any number of buildings. Apartment houses that have more than one staircase are split up in separate buildings at every staircase. In every building, there may be several usable units. For example, an apartment house may have several apartments, counting as separate usable units. Moreover, one building may have more than one address but will have at least one address. Below, the address Fields for estates (Table 1), buildings (Table 2), and usable units (Table 3) are shown. The ADDCODE, A5, and PCN Elements are optional, and the other Elements MUST be used if the data source contains their corresponding Fields. The Elements A1 and A2 (not listed in the tables) SHOULD also be used if data is available. Exception: when using the address codes only (access to the codes is necessary for the creator and recipient of the location information), just the ADDCODE and country Elements are mandatory; the other Elements can be used optionally, of course.
+-------------------------+-------------------------------+---------+ | 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 Units Note: "floors" in Austria (as in most parts of Europe) are counted differently compared to the US. The "1st floor" in Austria is actually the floor above the floor at street level (2nd floor in US) -- not considering the fact that, in old buildings, there might be even more floors between street level and 1st floor, like "mezzanine" and "2nd mezzanine". So, an Austrian "1st floor" could well be the "4th floor" according to US nomenclature. According to Statistik Austria [adrwarten], 81.5% of Austrian addresses are of the simple type Musterstrasse 1 (Musterstrasse is an example street name). 5% of all addresses have an additional character, like Musterstrasse 1b. 1% of Austrian addresses look like Musterstrasse 21A - 23A. For 8% of addresses, an additional separator is necessary -- like Musterstrasse 10 Haus 1 Stiege 2, or Musterstrasse 20 Gruppe A Reihe 1 Parzelle 13, or Musterstrasse 30 Weg 1 Parzelle 10. Very seldom, there are so-called special addresses (0.03%) -- for example, Musterstrasse gegenueber 3A, meaning this address is actually opposite of house number 3A. Rather surprisingly, 4.47% of Austrian addresses contain the identifier of the estate since no house number is assigned at all -- for example, Musterstrasse GNR 1234, or Musterstrasse GNR .12/4 Kirche (this type of addresses is common for churches), or a real example in Stockerau:
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.
Section A.4.2.1 A2 political district name or identifier (politischer Bezirk), Section A.4.2.2 A3 commune name or identifier (Gemeinde), Section A.4.2.3 A4 village name or identifier (Ortschaft), Section A.4.2.4 A5 cadastral municipality name or identifier (Katastralgemeindename or Katastralgemeindenummer), Section A.4.2.5 Element A6 must not be used. Last, there is an exception to mention that concerns the Austrian capital, Vienna (Wien). The city of Vienna is equal to its political district and even the province is called Vienna. Nevertheless, Vienna is separated in 23 districts within the same political district. Consequently, an address in Vienna would look like: <country>AT</country> <A1>Wien</A1> <A2>Wien</A2> <A3>Wien</A3> <A4>Favoriten</A4> or <A4>10<A4> <A5>Inzersdorf Stadt<A5> The Element A4, holding the city division, can hold the name or the number of the district. RFC5139], for the PIDF-LO Element A1, the second part of ISO 3166-2 [ISO3166-2] can be used. However, in Austria it is also common to write out the names of the states. Table 4 shows the possible values of the A1 Element for Austrian states.
+------------------------+--------------------------------+ | 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.) bezirke]. These names, the unique code for the political district, or both can be used for the A2 Element. If the content of the A2 Element is numeric, obviously the code is provided (there is no political district in Austria with a number in its name). In case both the name and the code are provided, they are separated by a semicolon and the name must be listed first. The district of "Bruck an der Leitha" could be represented by: <A2>Bruck an der Leitha<A2> or <A2>307</A2> or <A2>Bruck an der Leitha;307</A2>
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> 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>
content of the A5 Element consists of a number only, it is obvious that just the identifier is provided, since there are no Katastralgemeindenamen in Austria that contain a number. Sample (Vienna, Fuenfhaus): <A5>Oberbaumgarten</A5> or <A5>1208</A5> or <A5>Oberbaumgarten;1208</A5> merkmalskatalog]. For user-interface representation, the semicolon-separated format can be transformed by replacing semicolons by spaces (multiple spaces should be combined) and no space should be present between a numeric part of a house number and its related character. It is not allowed to use the HNS Element for Austrian addresses, since there are addresses that do not have just a single suffix.
The house number "vor 1 - 1A" (consisting of a house number text "vor", first part of the house number numeric "1", "-" as the link of the first and Bis part, "1" as house number Bis part numeric, "A" as character of the Bis part) would be mapped to: <HNO>vor;1;;-;1;A;;;;;;;;;;;</HNO> RFC 4119). Section 4.2.1), indicating an Austrian address, the Additional Code Element is expected to hold codes from
Statistik Austria only. When creating PIDF-LO documents using address codes by Statistik Austria, the country and ADDCODE Elements are mandatory.
Hausnummer - Bis-Nummer: 13 Hausnummer - Bis-Buchstabe: C Postleitzahl: 1090 PIDF-LO: <?xml version="1.0" encoding="UTF-8" ?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:123@examplehost"> <tuple id="abcd123456"> <status> <gp:geopriv> <gp:location-info> <cl:civicAddress xml:lang="de"> <cl:country>AT</cl:country> <cl:A1>Wien</cl:A1> <cl:A2>Wien</cl:A2> <cl:A3>Wien</cl:A3> <cl:A4>9</cl:A4> <cl:RD>Lazarettgasse</cl:RD> <cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</cl:HNO> <cl:PC>1090</cl:PC> </cl:civicAddress> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>yes</gp:retransmission-allowed> <gp:retention-expiry>2009-11-10T12:00:00Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2009-02-09T12:00:00Z</timestamp> </tuple> </presence>
<status>active</status> </record> <people> <person id="Alexander_Mayrhofer"> <name>Alexander Mayrhofer</name> <org>nic.at GmbH</org> <uri>mailto:email@example.com</uri> <updated>2009-01-09</updated> </person> <person id="Karl_Heinz_Wolf"> <name>Karl Heinz Wolf</name> <org>nic.at GmbH</org> <uri>mailto:firstname.lastname@example.org</uri> <updated>2009-01-09</updated> </person> </people> [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>.
[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.
http://www.nic.at/ Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria Phone: +43 1 5056416 34 EMail: email@example.com URI: http://www.nic.at/