GEOPRIV K. Wolf Internet-Draft A. Mayrhofer Intended status: BCP nic.at Expires:
April 30,July 13, 2009 Jan 09, 2009 nic.at Oct 27, 2008Considerations for Civic Addresses in PIDF-LO draft-ietf-geopriv-civic-address-recommendations-00- Guidelines and IANA Registry Definition draft-ietf-geopriv-civic-address-recommendations-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30,July 13, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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. Abstract This document provides a guideline for creating civic address consideration documents for individual countries, as required by RFC 4776. Since civic addresses may have a different format in individual countries, such address considerations are necessary in orderFurthermore, this document also creates an IANA Registry referring to map the civicsuch address fields to the PIDF Location Object (PIDF-LO) elements.consideration documents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 35 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 36 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 46 4. Specifying PIDF-LO Element Usage . . . . . . . . . . . . . . . 47 4.1. Country . .General Considerations and Workflow . . . . . . . . . . . 7 4.2. Guidelines for Individual Elements . . . . . . . . . . . . 6 4.2.8 4.2.1. Country Subdivisions A1-A6. . . . . . . . . . . . . . . . 6 4.3. Road and Street Names. . . . . . . 8 4.2.2. Country Subdivisions A1-A6 . . . . . . . . . . . 7 4.4. House Numbers. . . 9 4.2.3. Road and Street Names . . . . . . . . . . . . . . . . 9 4.2.4. House Numbers . . . 7 4.5. Local Names. . . . . . . . . . . . . . . . . 10 4.2.5. Local Names . . . . . . 8 4.6. Floors. . . . . . . . . . . . . . . 11 4.2.6. Floors . . . . . . . . . . . 9 4.7. Address Codes. . . . . . . . . . . . . 11 4.2.7. Address Codes . . . . . . . . . 9 4.8. Other Elements. . . . . . . . . . . 12 4.2.8. Other Elements . . . . . . . . . . . 10 5. Austria Example. . . . . . . . . 13 5. Security & Privacy Considerations . . . . . . . . . . . . . . 11 5.1. Civic Address Format in Austria13 6. IANA Considerations . . . . . . . . . . . . . 11 5.2. Sample Addresses. . . . . . . . 14 6.1. PIDF-LO Civic Address Consideration Registry . . . . . . . 14 6.1.1. Structure . . . . . . 16 5.3. Address Codes in Austria. . . . . . . . . . . . . . . . 14 6.1.2. Registration Template . 17 5.4. Austrian Addresses in PIDF-LO. . . . . . . . . . . . . . 17 5.4.1. Country. 15 6.1.3. Registry Location . . . . . . . . . . . . . . . . . . 15 6.1.4. Registration Procedure . . . . 17 5.4.2. Country Subdivisions A1-A6. . . . . . . . . . . . 16 6.2. Registration Request for Austria . . 17 5.4.3. A4 Element. . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . 20 5.4.4. A5 Element. . . . . . . . . . . . 16 Appendix A. Civic Address Considerations Registration for the Austrian building and habitation registry . . . . . . 16 A.1. Civic Address Format in Austria . . . . 20 5.4.5. Road and Street Names. . . . . . . . . 16 A.2. Sample Addresses . . . . . . . 20 5.4.6. House Numbers. . . . . . . . . . . . . . 21 A.3. Address Codes in Austria . . . . . . 20 5.4.7. Local Names. . . . . . . . . . . 22 A.4. Austrian Addresses in PIDF-LO . . . . . . . . . . . . . . 22 5.4.8. FloorsA.4.1. Country . . . . . . . . . . . . . . . . . . . . . . . 22 A.4.2. Country Subdivisions A1-A6 . . . . . . . . . . . . . . 22 5.4.9. Additional Code ElementA.4.3. Road and Street Names . . . . . . . . . . . . . . . 22 5.4.10. Other Elements. 25 A.4.4. House Numbers . . . . . . . . . . . . . . . . . . . . 22 5.4.11. Elements not to be used26 A.4.5. Local Names . . . . . . . . . . . . . . . 23 5.5. Example. . . . . . 26 A.4.6. Floors . . . . . . . . . . . . . . . . . . . 23 6. Security & Privacy Considerations. . . . . 26 A.4.7. Additional Code Element . . . . . . . . . 24 7. IANA Considerations. . . . . . 27 A.4.8. Other Elements . . . . . . . . . . . . . . . . 24 8. Acknowledgements. . . . 27 A.4.9. Elements not to be used . . . . . . . . . . . . . . . 27 A.5. Example . . . . . 24 9. References. . . . . . . . . . . . . . . . . . . . 28 A.6. IANA Registration Record . . . . . . 25 9.1. Normative. . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . 25 9.2. Informative. . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses. 30 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . 26 Intellectual Property and Copyright Statements. . . . . . . . . . 27. . . . . . . . . 32 1. Introduction The "Presence Information Data Format Location Object" (PIDF-LO) [RFC4119] is an anobject format for carrying geographical information on the Internet. PIDF-LO can be used to carryconvey civic address information, and supports a range of "civic address types" (CATypes) to describehold individual attributes of an civic addresssuch addresses (see Section 2.2.1 of RFC 4119[RFC4119] and Section 3.1 of RFC 5139, the revised set of CATypes).[RFC5139]). In many use cases, PIDF-LOs are populated with data from long- established sources, like postal or governmental building registers, line information databases and yellow / white pages of infrastructure providers, or official residents registers. The structure and format of data from thesesuch sources is almost always different from PIDF-LO's CAtypes definition - additionally, structure and format of those sources differs from country to country. To make use of such existing data sources, instructions fortransposing suchthat data into PIDF-LO format (element mapping)is required. Preferrably, those mapping operations are reversable, so that location receipients like public safety answering points (PSAPs) can reconcile such PIDF-LOsWith 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 original data source. Additionally, for anysame data source just a single mapping should exist in order to reduce- which reduces interopability and increases the risk of ambiguous interpretation.misinterpretation by receivers. Therefore, civic address considerations are necessary for individual countriesto ensure uniform usage of PIDF-LO elements. RFC 4776 explicitly asksElements for such documents. This guideline aims to support the creation ofdata sources. [RFC4776] explicitly requests such civic address considerations. For some countries RFC4776 already hasdocuments to be provided, but does neither define their structure nor a way to publish them. This memo provides documentation on how to create such civic address considerations, and requests the creation of an IANA Registry to store references to such documents. For some countries Section 3.4 of [RFC4776] already contains considerations on the use of administrative sub-divisions in Section 3.4. Notesub-division elements. It's important to note that thesethose examples are not compliant tooutdated, because RFC 5139 [RFC5139], since[RFC5139] disallows the A6 element is not useduse of the 'A6' elements for street names any more. This guidelinenames. The guidelines in this document is basedhave been created with a focus on the experienceformal application of writing such a civic address considerations document for Austria. Since there were some difficulties when tryingPIDF-LO (such as conveying location during an emergency call). It is not intended to define aforbid other, more informal uses of PIDF-LO that may not follow any formal mapping for Austrianspecifications. An example usecase 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 address fields to PIDF-LO, this document summarizes important experience and issues to consider. Even though every country has it's own address format and therefore other problems will occur, this guideline should help to identify difficulties. As examples, Austrianaddresses are used.from such a PIDF-LO. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In addition, this document uses "Field" to refer to a field of a civic address data source, and "Element" to refer to a CAType element of a PIDF-LO. 3. Requirements The following requirements apply to defining civic address mapping considerations: o The considerations document MUST identify the data source to which the definitions apply. A brief description of its structure SHOULD be provided as well. o For any data source, all elements must be considered (even if some of those fields arejust one active mapping definition should exist in order to be left outreduce the risk of ambigious interpretation. o The document MUST include instructions for any Field that occurs in the data. For any of the mapping,Fields, the document mustMUST describe that). o Anywhether the Field is required, optional, or must not be used in the mapping procedure. o Instructions MUST be included for any CAtype fieldElement that is registered by the time the document is produced must be considered, and if itcreated. Those instructions MUST include information whether an Element is not being used, that factrequired, optional, or must not be mentioned.used in that mapping. In case the set of CAtypes is revised by the IETF, the address consideration document shouldSHOULD be updated. Until then,an update is approved, the oldexisting mapping procedure mustMUST be used. o Address mappings shouldmapping procedures SHOULD be reversible, so that location recepientsreceipients can identify the corresponding record in the original records ifdata source (given they have access to the original sourcethat source). o For any element used,source data Field that is required or optional, at least one example mustmapping MUST be provided. Although the mapping is defined in a national way and the actual meaning of several PIDF-LO elements may not be clear to an outsider, at least the country element tells in what context this PIDF-LO was created. In case of emergency calls, a PIDF-LO would just be passed to a PSAP in the same country as the location generator anyway. However, in border region there might be exceptions and the PIDF-LO could be sent to a neighboring country. The PIDF-LO can still be passed on to a PSAP in the right country (based on the country element), or the PSAP might be aware of the mapping scheme used in the neighboring country. A consistent mapping is also very important for checking if two PIDF-LO documents describe the same location. When civic address Fields are put into different PIDF-LO elements, it may be difficult to identify whether or not two PIDF-LOs describe identical addresses. 4. Specifying PIDF-LO Element Usage The purpose of the civic address consideration documentconsiderations for an individual countrydata source is to specify thecreate interopability by specifying a common list of PIDF-LO elementsElements to be used, and by defining the mapping between these elementsElements and the fieldsFields of the respective localdata source. 4.1. General Considerations and Workflow The motivationworkflow for such a civiccreating an address considerationconsiderations document is as follows: 1. Describe the data source to ensure interoperability. Location recipients certainly want to rely on finding civicwhich the address parts in defined elements of PIDF-LO for further processing. Especially when it comes to emergency calling, location information is a criticalconsiderations document applies. 2. Identify all Fields from the data where misinterpretation has to be avoided. Therefore, a consistent mapping scheme is required. Since it issource, and decide for each of the Fields whether or not possiblethey are to have global PIDF-LO elements which canbe unambiguouslyused in every country infor the world,purpose of creating PIDF-LO documents. In the mappingconsiderations document, all Fields must be defined on an national level. It has to be ensured, thatlisted (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 used forrequired or optional, specify a clear mapping instruction according to the guidelines below. 4. Provide a list of all civic addressesCAtypes registered, and describe their level of usage in this country. Is is important to identify the civic address fields that can be mapped directly tomapping (or combine it with the corresponding PIDF-LO elementslist of Fields above and clearly list which civic address parts need special consideration. PIDF-LO elementsElements are not used for the mapping procedure). For Elements that are not neededdescribed in a specific country, can simplydetail state whether they MUST NOT be omitted. The civic address consideration document has to specify clearly that those elements must notused at all or they may be used for representing civic addresses in this country. Even though the listwithout further restriction. 5. Provide examples of CAtypes couldsource data and mapping results Civic address fields are designed to be extended, it is no feasiblegeneric containers. In some cases, Fields clearly correspond to add new elements for any new fieldsuch a container, however, in anysome 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 definiton 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 anyevery country. Therefore, unless new generic CAtypes are specified by the IETF, just theonly existing elements can be used. Thatused, which leaves the following two options in case the CAtypes do not provide a perfect fit for local civic address data (especially in case the local data contains more fields than PIDF-LO provides):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 All existing civic address parts must find a place inNote: Obviously, the PIDF-LO. Even exotic addresses, that might be very rare, must be considered. Civic addresses can be very complex in some countries. So itfirst option is very important to identifyrequired if the data sourcenumber of Fields that is representing all the possible civic addressesare used in a country. Perhaps this database is maintained by a governmental company, by an authority, orthe post. Moreover, itmapping procedure is important,greater than the number of existing CAtype Elements. Note that this data format is accepted by Public Safety Answering Point (PSAP) operators and they have access tothe data source. Even PSAPs within a country mayxml:lang attribute should be organized differentlypresent in PIDF-LO XML documents according to RFC 5139. 4.2. Guidelines for Individual Elements The following sections discuss individual PIDF-LO Elements and use different data basesdescribe what to consider for each Element when defining civic addresses.address considerations. It is crucialRECOMMENDED to define the PIDF-LO mapping infollow a way that all PSAPs can use it. It is disireable to have PSAP operators involved in the process of developing civic address considerations, so that their needs are especially considered. Although the mapping is defined in a national way and the actual meaning of several PIDF-LO elements may not be clear to an outsider, at least the country element tells in what context this PIDF-LO was created. In case of emergency calls, a PIDF-LO would just be passed to a PSAP in the same country as the location generator anyway. However, in border region there might be exceptions and the PIDF-LO is sent to a neighboring country. The PIDF-LO can still be passed on to a PSAP in the right country because of the country element or the PSAP knows the mapping of the neighbor country. A consistent mapping is also very importantsimilar structure 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 recognize two equal addresses. The following sections discuss individual PIDF-LO elements and describe what to consider when defining civic address considerations. 4.1.considerations documents. 4.2.1. Country The country element must hold the alpha-2 codes from ISO 3166-1 [refs.ISO3166-1] in upper case characters as clarified in Section 3.3 of RFC 5139 [RFC5139]. This element cannot be redefined on a national basis since it identifies the country itself. This element is used to identify which national mapping for civic addresses has been used in a specific PIDF-LO. Example for Austria: <country>AT</country> 220.127.116.11.2. Country Subdivisions A1-A6 The elements A1 to A6 are used to hold national subdivision identifiers, with A1 holding the top-level subdivision identifier. A1 may either contain the second part of ISO 3166-2 [refs.ISO3166-2] (see section 3.4 of RFC 5139 [RFC5139]), or values as described in the address consideration document for that country.document. Elements "A2" to "A6" may contain additional levels of subdivisions (see section 2.2.1 of RFC 4119). For A1, an address consideration document for a country shouldMUST state whether ISO 3166-2 codes are to be used,used exclusively, alternatively it should define a list of validvalues to be used (for example, subdivision names). In either case, A1 must notMUST NOT be redefined for any other use than describing top level subdivisions. The document should also specify forFor each of the A2 - A6 elements whether they are required, optional, or not allowed. For each elementElements that is required or optional, it shouldthe document SHOULD define the set of validallowed values, either by listing them, or by referring to such a list. For countries which are already discussed in section 3.4 of RFC 4776, it is recommended to follow those mappings.Example for AustriaAustria: A1 province (Bundesland) A2 political district name or identifier (politscher Bezirk) A3 commune name or identifier (Gemeinde) A4 village name or identifier (Ortschaft) A5 cadastral municipality name or identifier (Katastralgemeindename or Katastralgemeindenummer) A6 must not be used. For more details see the example in Section 5.4.2. 4.3.Appendix A.4.2. 4.2.3. Road and Street Names PIDF-LO contains the following elementsElements related to road names: RD, RDSEC, RDBR, RDSUBADDR, PRM, POM (section 3.1 and 3.2 of RFC 5139 [RFC5139]) and PRD, POD, STS (section 3.4 of [RFC4776]). Note that theNote: The use of the A6 elementElement for street names is not valid any more (Section 3.2 of RFC 5139 [RFC5139]). An address considerations document for a country should specifyBesides the basic specification which of those nine elementsElements are required, optional or not allowed. If neccessary, theto be used, and address considerations document may also describe more complicated dependencies (for example, "RD is optional, but required if any other road name elementElement is used"). For any required or optional element, it should describethe relation of those elementsElements to elementsFields of the data source used. Ifused MUST be described, as well as special considerations apply to certain elements,(like concatenation of Fields into an Element) if they should be described. Also focus on the element STS,apply. The usage of the street suffix. It mustElement STS (street suffix) SHOULD be assured that this suffix is used in a consistent way.consistent. In case no suffixes are known in a countrydata source, or it is common to write the street name and the suffix together, it is allowed to forbid the usage ofthe STS elementElement SHOULD be left out completely. SuffixesIf suffixes may alsobe abbreviated. Defineabbreviated the common abbreviations.abbreviations SHOULD be defined. Example for Austria: RD: street name All other road elementsElements must not be used, street suffix issuffixes are already included in RD element. Street suffixesthe "street name" Field, and must not be abbreviated. 18.104.22.168.4. House Numbers PIDF-LO specifies two elementsElements related to house numbers: "house number" (HNO,HNO ("house number", numeric part only) and "houseHNS ("house number suffix" (HNS)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 on mapping national house numbers to PIDF-LOis neededREQUIRED to minimize confusion potential. An address consideration document for a countryshould provide the following information with regards to house numbers: If the structure of house numbers in that countryfits the HNO/HNS structure, the document mustMUST mandate to use those fields as described in RFC 4776. If the structure of house numbers does not directly fit into those two elements,Elements, the document must propose rulesMUST define strategies on how to map origin datasource Fields into PIDF-LO elements.Elements. Besides HNO and HNS, LOC and BLD could be considered for carrying house number information. The document shouldSHOULD describe whether abbreviations of house number elements areinformation is valid or not. If abbreviations are used, they mustMUST be clearly defined. If thehouse number consists of more than one numbernumber, or 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 field,Element, keep in mind that the location recipient might want to separate the data again. Example from Austria: HNO: concatenate all the data elements of Austrian house numbers into this single PIDF-LO elementElement in a defined order with delimiter symbols (see Section 5.4.6Appendix A.4.4 for the complete definition). HNS: Usage not recommended to be usedallowed since there may be multiple suffixes for the different parts of the house number. 4.5.LOC and BLD are not to be used to reflect house number information. 4.2.5. Local Names PIDF-LO contains three elements to reflect local names: LMK, LOC, NAM (section 3.4 of RFC 4776). Such local names may be of importance for the identification of a location, and may either coexist with a valid civic address or (in some cases) no address may be assigned so that the local names itself identify 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 either assist in finding a "street name" type addess, but they might also be the authoritative (and only) civic location information. Address consideration documents for individual countries should state for each of the LMK, LOC, NAM elements whether they are required, optional, or not to be used.For any required or optional field, itElement out of LMK, LOC, NAM the considerations docuiment should state potential values (source data) for the element. In case that multiple values for an elementElement may occur, a concatenation / selection strategy should be described. Concatenation using ";" as seperator is recommended.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 shouldSHOULD discuss the relation between those two address information types, and expected behaviour of location receipients. 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. 22.214.171.124.6. Floors PIDF-LO defines the element FLR to hold thefloor information, but does not further specify its content. Section 2.1 of RFC 3825 provides guidance about floor numbering, but is not directly related to PIDF-LO. An address consideration document for a country shouldSHOULD clearly specify how to express floors using the FLR element. Following the above mentioned guidance is recommended,RECOMMENDED, however, local nomenclature might require a completely different system. The document shouldSHOULD specify whether only numbers, text, or both are allowed in the FLR element. If there are standard values for certain floors, they shouldSHOULD be listed. Abbreviations shouldSHOULD be avoided, unless they are the primary (well known) way of identifying floors. Example from Austria: If floor numbers are to be mapped, the FLR Element MUST be used. Numbers and text are both allowed. The first floor (<FLR>1</FLR>) is the first "full" floor above the floor at street level. The floor at street level is <FLR>EG</FLR> or <FLR>0</FLR>. There might be intermediate floors, especially between the floor at street level and the "first floor". Such intermediate floors have names like "Mezzanine", "Erster Halbstock" ("first half floor"), "Zweiter Halbstock" ("second half floor"). 4.7.floor"), and have local meanings. 4.2.7. Address Codes Address codes are available in several countries in different forms (for estates, buildings or usable units for example). These codes identify an address record, and canMAY be placed in the ADDCODE element in PIDF-LO. Address codes can help the location recipient to determine the location, and to identify the original record in the data source. Depending on the type of code, the code alone (without any other Elements) may even be sufficient as location information within a country. The PIDF-LO country element can be usedto fully identify the name space in which the address code elements are valid. Countries may have more than one type ofan address codes (multiple namespaces), so it might be necessary to choose the code that is most widely accepted (by PSAPs) or to have identifiers for the different codes. Awithin 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 for a country shouldSHOULD specify whether and in which applications the use of the ADDCODE elementsElement is allowed. If ADDCODE is used, its relation to the remaining elements mustElements MUST be clearly stated. If several namespaces for address codes exist in a country, a mechanism to distinguish the different code spaces mustMUST be described. Examples from Austria: Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode (AdrsubCD), Objektnummer (ObjNr) and Nutzungseinheitenlaufnummer (NtzLnr). The following format shouldSHOULD be used: <ADDCODE>AdrCD=1234567;AdrsubCD=123;ObjNr=2333211;NtzLnr=0001</ADDCODE> 4.8.<ADDCODE>AdrCD=1234567;AdrsubCD=123; ObjNr=2333211;NtzLnr=0001</ADDCODE> 4.2.8. Other Elements This section lists all the otherPIDF-LO elements,Elements that arehave not consideredbeen discussed so far. To specify the location inside a building, the following elementsElements can be useful: o UNIT o ROOM o SEAT The following elementsElements are relatedto be used for the representation of postal codes: o PC o PCN o POBOX To describe the place-type or the building, the following elementsElements are available: o PLC - Place-type (see RFC 4589)[RFC4589]) o BLD - Building (structure) The xml:lang attribute should be present in PIDF-LO XML documents. An address considerations document should specify forFor any of those elements whether they are required, optional, or must not be used. For any elementElements that isare required or optional,optional in a mapping, the semantics of its contents must be described, if it differs from the PIDF-LO base documents. 5. Austria Exampledefinition in the PIDF-LO base documents. It is RECOMMENDED that the elements SEAT, UNIT and ROOM remain to be used for identifying a location inside a building. They MAY be used by the owner of the respective building if a considerations document does not restrict their use. For example, an airport could decide to place the gate number in the UNIT element, and a location recipient could identify that PIDF-LO by the value of the PLC Element. The name of the airport could be placed in NAM. 5. Security & Privacy Considerations RFC 4119 contains general security considerations for handling PIDF- LOs. In addition to that, it has to be considered that data from certain data sources (on which the described mapping process is based) are possibly not public, so restrictions as imposed on the original data set MUST also be imposed on the resulting PIDF-LO document. The considerations document SHOULD note such restrictions in its Security Considerations section. 6. IANA Considerations This document requests creation of the registry "PIDF-LO Civic Address Consideration Registry", according to the following definitions. Furthermore, this document requests registration of a civic address considerations document for Austrian addresses as provided in the Appendix of this document. 6.1. PIDF-LO Civic Address Consideration Registry 6.1.1. Structure The IANA Registry contains the following fields: o Country-Code: Either the ISO 3166 alpha-two code of the country to which the consideration applies or "other" in case the consideration document is not specific to a particular country. This field is to be defined by the requestor. o Serial Number: A number that uniquely identifies a considerations document within a certain "Country-Code" field value. Serial Numbers are sequentially assigned by IANA per "Country-Code" value, start at zero, and are never reused. o Reference to specification: This field contains a reference to the considerations document. o Requestor: The author of the document. o Status: One of "active" or "obsolete". When the document is registered by IANA, the status is first set to "active" by IANA. Experts may later request changing the status to "obsolete", especially if there is an updated version of the considerations document available. Authors of consideration documents must contact the experts if they wish to change the status of the document. Note: The combination of "Country-Code" and "Serial Number" fields uniquely identify a considerations document in the registry (for example, "AT-0", "US-0", "US-1" or "other-0"). 6.1.2. Registration Template For registration of address considerations documents in the registry, requestors SHOULD use the following template. The template SHOULD be contained in the considerations document itself. <record> <country> <!-- Country-Code --> </country> <serial> <!-- assigned by IANA --> </serial> <reference> <!-- URI to the considerations document --> </reference> <requesters> <!-- Change accordingly --> <xref type="person" data="John_Doe"/> <xref type="person" data="Jane_Dale"/> </requesters> <status> <!-- assigned by IANA --> </status> </record> <people> <person id="John_Doe"> <name> <!-- Firstname Lastname --> </name> <org> <!-- Organisation Name --> </org> <uri> <!-- mailto: or http: URI --> </uri> <updated> <!-- date format YYYY-MM-DD --> </updated> </person> <!-- repeat person section for each person --> </people> 6.1.3. Registry Location Approved registrations are published in the IANA registry named "PIDF-LO Civic Address Consideration Registry", which is available at the following URI: XXX ((TO BE DEFINED BY IANA)). Registration are sorted by ascending order by the country code, and by serial number within country code values. Registrations with country code of "other" are put at the end of the list. 6.1.4. Registration Procedure Following the policies outlined in [RFC5226], new address considerations are added to the registry after Expert Review (see Section 4.1 in RFC 5226). The Expert will generally check if the submitted address considerations conforms the civic address guidelines in this document (section Section 4). If in doubt, the Experts SHOULD consult the GEOPRIV mailing list or it's dedicated successor. If possible, the Experts SHOULD check the available documentation on which the address consideration is based. 6.2. Registration Request for Austria This document requests registration of the Civic Address Considerations for addresses form the official Austrian Building an Habitation registry, according to the registration procedure described above. The required information is contained in Appendix A 7. Acknowledgements The authors wish to thank Gregor Jaenin for contributing insights into the Austrian civic address data format. Appendix A. Civic Address Considerations Registration for the Austrian building and habitation registry The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and habitation registry law) is the legal basis for the obligation to provide a registry of civic addresses, buildings and their usable units (subdivisions of buildings). The registry is operated by "Statistik Austria GmbH", a fully governmental owned company. Responsibility for keeping records in the registry up to date is an obligation to the local administration of the individual townships. The data format definition for the individual records is publicly available (data access itself is however restricted). Hence, an uniform address data base for whole Austria is available. Unfortunately, Austrian civic addresses use a much more complex format compared to civic addresses in PIDF-LO.A detailed description of the AustrianStatistik Austria civic address data format is contained in section Section 5.1. A guideline of how to use PIDF-LO for Austrian addresses is necessary in order to avoid misinterpretations. This is especially important if the PIDF-LO is conveyed during an emergency call to a Public Safety Answering Point (PSAP). A precise location information is needed in case of emergency to send out responders without any delay to the correct location of the caller. If every data-provider uses its own address mapping to PIDF-LO, confusion and misunderstandings are bound to happen. However, ideally any PSAP should have full access to the data by Statistik Austria. PSAPs must be able to rely that location information is always provided the same way by all data-providers. To address the idiosyncrasies in Austria, the civic address elements are discussed subsequently. 5.1.Appendix A.1. A.1. Civic Address Format in Austria Statistik Austria data describes estates, buildings and usable units [refs.merkmalskatalog]. On a single estate there may be any number of buildings. Apartment houses that have more than one staircase, are split up in separate buildings at every staircase. In every building, there may be several usable units. For example, an apartment house may have several apartments, counting as separate usable units. Moreover, one building may have more than one address, but at least one address. Below, the address elementsFields for estates (Table 1), buildings (Table 2) and usable units (Table 3) are shown. The ADDCODE, A5 and PCN Elements are optional, the other Elements MUST be used if the data source contains their corresponding Fields. The Elements A1 and A2 (not listed in the tables) SHOULD also be used if data is available. Exception: when using the address codes only (access to the codes is necessary for creator and receiver of the location information), just the ADDCODE and country Elements are mandatory, the other Elements can be used optionally of course. +-------------------------+-------------------------------+---------+ | Statistik Austria name | Explaination | 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 ElementsFields for Estates +------------------------+--------------------------------+---------+ | Statistik Austria name | Explaination | PIDF-LO | | | | Element | +------------------------+--------------------------------+---------+ | Adressubcode | 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 vers. Maierweg 27 | | | | Appartmenthaus | | | | | | +------------------------+--------------------------------+---------+ Table 2: Additional Civic Address ElementsFields for Buildings +-----------------------------+---------------------------+---------+ | Statistik Austria name | Explaination | 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 ElementsFields for usable units Note: "Floors" in Austria (as in most parts of Europe) are counted differently compared to the US. The "1st floor" in Austria is actually the floor above the floor at street level (2nd floor in US), not considering the fact that in old buildings there might be even more floors between street level and 1st floor, like "mezzanine", "2nd mezzanine". So, an Austrian "1st floor" could well be the "4th floor" according to US nomenclature. According to Statistik Austria [refs.adrwarten], 81.5% of Austrian addresses are of the simple type Musterstrasse 1 (Musterstrasse is an example street name). 5% of all addresses have an additional character, like Musterstrasse 1b. 1% of Austrian addresses look like Musterstrasse 21A - 23A. For 8% of addresses, an additional separator is necessary, like Musterstrasse 10 Haus 1 Stiege 2 or Musterstrasse 20 Gruppe A Reihe 1 Parzelle 13 or Musterstrasse 30 Weg 1 Parzelle 10. Very seldom, there are so called special addresses (0.03%), for example Musterstrasse gegenueber 3a, meaning this address is actually vis-a-vis of house number 3A. Rather surprisingly, 4.47% of Austrian addresses contain the identifier of the estate since no house number is assigned at all, for example: Musterstrasse GNR 1234, or Musterstrasse GNR .12/4 Kirche (this type of addresses is common for churches) or a real example in Stockerau: Kolomaniwoerth GNR 1583. This identifier is stored by Statistik Austria as Hausnummerntext. Otherwise one could misinterpret this number as a house number, what would be definitely wrong. 5.2.A.2. Sample Addresses In order to clarify the Austrian civic address format, this section provides some exemplary addresses: 1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1 Postleitzahl: 1234 Stadt: Musterstadt Strasse: Hauptstrasse Hausnummer - 1. Teil - Nummer: 1 Hausnummer - 1. Teil - Buchstabe: a Hausnummer - Verbindungszeichen Teil 1 -> Bis: - Hausnummer - 2. Teil - Nummer: 5 Hausnummer - 2. Teil - Buchstabe: a Hausnummer - Verbindungszeichen Teil Bis -> Teil 2: Block Hausnummer - 2. Teil - Nummer: 1 Hausnummer - 2. Teil - Buchstabe: b Hausnummer - Verbindungszeichen Teil 2-> Teil 3: Haus Hausnummer - 3. Teil - Nummer: 2 Hausnummer - 3. Teil - Buchstabe: c Gebaeudeunterscheidung: Stiege 1 1234 Musterstadt, Musterstrasse 13 Hotel Postleitzahl: 1234 Stadt: Musterstadt Strasse: Musterstrasse Hausnummer - 1. Teil - Nummer: 13 Gebaeudeunterscheidung: Hotel 6020 Innsbruck, Anichstrasse vor 35 Postleitzahl: 6020 Stadt: Innsbruck Strasse: Anichstrasse Hausnummerntext: vor ("in front of") Hausnummer: 35 6173 Oberperfuss, Riedl 3097 (Pfarrkirche) Postleitzahl: 6173 Stadt: Oberperfuss Strasse: Riedl Hausnummerntext: 3097 (since the estate identifier is 81305 3097 where 81305 is the Katastralgemeindenummer (cadastral municipality) and no house number is assigned) Vulgoname: Pfarrkirche 5.3.A.3. Address Codes in Austria Statistik Austria registers 4 codes: Adresscode, Adresssubcode, Objektnummer and the Nutzungseinheitenlaufnummer. The Adresscode (7 digits) is a unique code for an address in Austria. The Adressregister maps the Adresscode to the civic address. If there is a building located at an address, there is also an Adresssubcode (3 digits) assigned. Every building at an address has its own Adresssubcode (assigned sequentially starting with 001, 002, 003 and so on) in order to distinguish between buildings at the same address. Furthermore, every building located in Austria has its own unique code, the Objektnummer (7 digits). This code identifies the building independent of the Adresscode. That's because addresses are subject to change while the building may persist. To differ multiple usable units inside a building, the Nutzungseinheitenlaufnummer (4 digits) is used. This code is also assigned in sequential order for each building. Besides, every address and building is geocoded by Statistik Austria. Hence, if every PIDF-LO location object would carry data in the format of Statistik Austria and every PSAP would use the database of Statistik Austria for mapping, a time saving, definite mapping without irregularities could be achieved. Besides these codes, Statistik Austria maintains reference numbers for communes, localities or streets, to mention just a few. 5.4.A.4. Austrian Addresses in PIDF-LO A good number of Austrian addresses do not fit into the PIDF-LO format, as described above. So theThe following subsectionsubsections define the mapping procedure. 5.4.1.A.4.1. Country The country element for Austria must be set to AT, since this is the ISO 3166-1 [refs.ISO3166-1] alpha-2 code for Austria. <country>AT</country> The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119] and RFC 5139 [RFC5139] proposes to use upper case characters only. 5.4.2.A.4.2. Country Subdivisions A1-A6 A1 province (Bundesland), Section 126.96.36.199A.4.2.1 A2 political district name or identifier (politscher Bezirk), Section 188.8.131.52A.4.2.2 A3 commune name or identifier (Gemeinde), Section 184.108.40.206A.4.2.3 A4 village name or identifier (Ortschaft), Section 220.127.116.11A.4.2.4 A5 cadastral municipality name or identifier (Katastralgemeindename or Katastralgemeindenummer), Section 18.104.22.168A.4.2.5 Element A6 must not be used. Last, there is an exception to mention concerning the Austrian capital Vienna (Wien). The city of Vienna is equal to its political district and even the province is called Vienna. Nevertheless, Vienna is separated in 23 districts within the same political district. Consequently, an address in Vienna would look like: <country>AT</country> <A1>Wien</A1> <A2>Wien</A2> <A3>Wien</A3> <A4>Favoriten</A4> or <A4>10<A4> <A5>Inzersdorf Stadt<A5> The element A4, holding the city division, can hold the name or the number of the district. 22.214.171.124.A.4.2.1. A1 Element As proposed in RFC 5139 [RFC5139], for the PIDF-LO element A1, the second part of ISO 3166-2 [refs.ISO3166-2] can be used. However, in Austria it is also common to write out the names of the states. Table 4 shows the possible values of the A1 element for Austrian states. +-------------------+--------------------------------++------------------------+--------------------------------+ | Bundesland | second part of ISO 3166-2 code | +-------------------+--------------------------------++------------------------+--------------------------------+ | Burgenland | 1 | | | | | KaerntenK=U+00E4rnten | 2 | | | | | NiederoesterreichNieder=U+00F6sterreich | 3 | | | | | OberoesterreichOber=U+00F6sterreich | 4 | | | | | Salzburg | 5 | | | | | Steiermark | 6 | | | | | Tirol | 7 | | | | | Vorarlberg | 8 | | | | | Wien | 9 | +-------------------+--------------------------------++------------------------+--------------------------------+ Table 4: A1 element format for Austria 126.96.36.199.(Note: values are shown in UTF-8, which is recommended to be used for PIDF-LO) A.4.2.2. A2 Element Names of the Austrian political districts are available at Statistik Austria [refs.bezirke]. These names, the unique code for the politcal district or both can be used for the A2 element. If the content of the A2 elment is numeric, obviously the code is provieded (there is no political district in Austria with a number in its name). In case both, the name and the code are provided, they are seperated 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> 188.8.131.52.A.4.2.3. A3 Element The element A3 holds the Gemeindename (commune name) or the identifier of the Gemeinde, or both separated by a semicolon (the name must be listed first). If the content of the A3 element consists of a number only, it is obvious that just the identifier is provided. Statistik Austria maintains a table with the Gemeindenamen and identifiers [refs.gemeinden], which must be used as the content 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> 5.4.3.A.4.2.4. A4 Element The element A4 holds the Ortschaftsname (village name), the Ortschaftskennziffer (the identifier), or both separated by a semicolon (the name must be listed first). If the content of the A4 element consists of a number only, it is obvious that just the identifier is provided since there are no Ortschaftsnamen in Austria which contain a number. Statistik Austria maintains a table with the Ortschaftsnamen and identifiers [refs.ortschaften], which must be used as the content for the A4 element, no other spelling is allowed. Sample: <A4>Wilfleinsdorf</A4> or <A4>03448</A4> or <A4>Wilfleinsdorf;03448</A4> 5.4.4.A.4.2.5. A5 Element The element A5 holds the Katastralgemeindename (cadastral municipality), the Katastralgemeindekennziffer (the identifier), or both separated by a semicolon (the name must be listed first). If the content of the A5 element consists of a number only, it is obvious that just the identifier is provided since there are no Katastragemeindenamen in Austria which contain a number. Sample (Vienna, Fuenfhaus): <A5>Oberbaumgarten</A5> or <A5>1208</A5> or <A5>Oberbaumgarten;1208</A5> 5.4.5.A.4.3. Road and Street Names The PIDF-LO element RD holds the complete street name, including the street suffix. No abbreviations are allowed. No other elements are needed for streets and must not be used. 5.4.6.A.4.4. House Numbers Statistik Austria lists 14 data fields related to the house number of a building plus another 5 fields for distinction of different usable units inside a building (including the floor, which has a separate element in PIDF-LO). Unfortunately, PIDF-LO only defines a single house number element (HNO, numeric part only) and a house number suffix element (HNS). Therefore, the rules of the HNO element have to be violatedelement (HNS). Therefore, this section defines a mapping in order to accomodate all data: All house number data is concatenate into a single HNO element, even though it is expected to hold numeric part only. If the location recipient does not needIn order to separate the data elements again, the house number parts may be simply concatenated with spaces in between (no spaces between the numeric partallow automatic procession of a house number and its related character). However, if the location recipient needs to get backthe original data,HNO Element, it is necessary to use a semicolon as delimiter symbol (Austrian house numbers do not contain semicolons). The house number parts MUST be provided in the order as they are listed by the Statistik Austria document [refs.merkmalskatalog]. For user interface representation, the semicolon separated format can be transformed by replacing semicolons by spaces (multiple spaces should be combined) and no space should be present between a numeric part of a house number part and its related character. It is recommended,not allowed to use the HNS element for Austrian addresses, since there are addresses that do not have just a single suffix. For example, the address Lazarettgasse 13A could be mapped by: <HNO>13</HNO> <HNS>A</HNS> However, the building at Lazarettgasse has theThe house number 13A - 13C. Consequently, just the HNO element should be used: <HNO>13A"vor 1 - 13C</HNO> And even for addresses with1A" (consisting of a house number consistingtext "vor", first part of a singlethe house number and a single prefix, just HNO should be used becausenumeric "1", "-" as the link of uniformity: <HNO>13A</HNO> Addresses with athe first and Bis part, "1" as house number text would look like: <HNO>vor 1 - 1A</HNO> with no HNS element. The same example with semicolonbis part numeric, "A" as delimiter symbolcharacter of the bis part) would look like:be mapped to: <HNO>vor;1;;-;1;A;;;;;;;;;;;</HNO> 5.4.7.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) 5.4.8.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 elements Lage and Stockwerk are concatenated if necessary. 5.4.9.A.4.7. Additional Code Element The element additional code may be used to hold the codes provided by Statistik Austria. There is an Adresscode, Adressubcode, Objektnummer and a Nutzungseinheitenlaufnummer. These unique codes identify the location. Actually, these codes alone would be enough, but requires that the location recipient has access to the database of Statistik Austria. If the additional code in a PIDF-LO document is going to hold the codes from Statistik Austria, the following format should be used: <ADDCODE>AdrCD=1234567;AdrsubCD=123;ObjNr=2333211;NtzLnr=0001</ADDCODE><ADDCODE>AdrCD=1234567;AdrsubCD=123; ObjNr=2333211;NtzLnr=0001</ADDCODE> It is not necessary to provide all codes, but there are some restrictions: The Adresssubcode cannot be used without an Adresscode. More restrictions are definded by Statistik Austria. By setting the country element to AT (see Section 4.1),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. 5.4.10.A.4.8. Other Elements The elements PC and PCN can hold the data form Statistik Austria, the POBOX can be used if the post assigned a post office box. At least the PC element should be present. PC: Postleitzahl (postal code) PCN: Postleitzahlengebiet (postal community name) POBOX: Postfach The elements UNIT, ROOM, SEAT, PLC and BLD may be used without further restriction. 5.4.11.A.4.9. Elements not to be used A6 STS HNS PRD POD RDBR RDSUBBR PRM POM 5.5.A.5. Example This section shows an example mapping of an Austrian address mappingto PIDF-LO element.PIDF-LO. Address: Bundesland: Wien Politischer Bezirk: Wien Gemeindename: Wien 9. Bezirk Strasse: Lazarettgasse Hausnummer - 1. Teil - Nummer: 13 Hausnummer - 1. Teil - Buchstabe: A Hausnummer - Verbindungszeichen Teil 1-Bis: - Hausnummer - Bis-Nummer: 13 Hausnummer - Bis-Buchstabe: C Postleitzahl: 1090 PIDF-LO: <?xml version="1.0" lang="de" 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="123456"> <status> <gp:geopriv> <gp:location-info> <cl:civicAddress> <cl:country>AT</country> <cl:A1>Wien</A1> <cl:A2>Wien</A2> <cl:A3>Wien</A3> <cl:A4>9</A4> <cl:RD>Lazarettgasse</RD> <cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</HNO> <cl:PC>1090<PC> </cl:civicAddress> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>yes</gp:retransmission-allowed> <gp:retention-expiry>2007-11-10T12:00:00Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2007-11-09T12:00:00Z</timestamp> </tuple> </presence> 6. Security & Privacy Considerations RFC 4119 contains general security considerations for handling PIDF- LOs. In addition to that, it has to be considered that data from the Austrian building and habitation unit registry are generally not public, so restrictions as imposed on the original data set MUST also be imposed onencoding="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="123456"> <status> <gp:geopriv> <gp:location-info> <cl:civicAddress> <cl:country>AT</country> <cl:A1>Wien</A1> <cl:A2>Wien</A2> <cl:A3>Wien</A3> <cl:A4>9</A4> <cl:RD>Lazarettgasse</RD> <cl:HNO>;13;A;-;13;C;;;;;;;;;;;;</HNO> <cl:PC>1090<PC> </cl:civicAddress> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>yes</gp:retransmission-allowed> <gp:retention-expiry>2009-11-10T12:00:00Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2009-02-09T12:00:00Z</timestamp> </tuple> </presence> A.6. IANA Registration Record <record> <country>AT</country> <serial> <!-- assigned by IANA --> </serial> <reference> <!-- RFC-Editor: the resulting PIDF-LO document. 7.URI to his RFC / --> </reference> <requesters> <xref type="person" data="Alexander_Mayrhofer"/> <xref type="person" data="Karl_Heinz_Wolf"/> </requesters> <status> <!-- assigned by IANA Considerations At this stage, this document contains no considerations for IANA.--> </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> 8. Acknowledgements The authors wish to thank Gregor Jaenin for contributing insights about the Austrian civic address data format. 9.References 184.108.40.206. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses 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. 9.2.[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006. 8.2. Informative References [refs.adrwarten] Statistik Austria, "Handbuch Adress-GWR-Online Teil A Theoretisches Handbuch Kapitel 2 Warten von Adressen im Adress-GWR-Online", Jan 2005. [refs.merkmalskatalog] Statistik Austria, "Handbuch Adress-GWR-Online Teil C Anhang 2 Merkmalskatalog", Sept 2004. [refs.ISO3166-1] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO Standard 3166- 1:1997, 1997. [refs.ISO3166-2] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code", ISO Standard 3166-2:1998, 1998. [refs.bezirke] Statistik Austria, "Politische Bezirke, Gebietsstand 2008", Feb 2008. [refs.gemeinden] Statistik Austria, "Gemeindeliste sortiert nach Gemeindekennziffer, Gebietsstand 2008", Feb 2008. [refs.ortschaften] Statistik Austria, "Gemeinden mit Ortschaften und Postleitzahlen, Gebietsstand 2008", Feb 2008. Authors' Addresses Karl Heinz Wolf nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria Phone: +43 1 5056416 37 Email: email@example.com URI: http://www.nic.at/ Alexander Mayrhofer nic.at GmbH Karlsplatz 1/2/9 Wien A-1010 Austria Phone: +43 1 5056416 34 Email: firstname.lastname@example.org URI: http://www.nic.at/ Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.