idnits 2.17.1
draft-ietf-geopriv-civic-address-recommendations-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 15.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 1145.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1156.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1163.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1169.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (Oct 27, 2008) is 5658 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV K. Wolf
3 Internet-Draft A. Mayrhofer
4 Expires: April 30, 2009 nic.at
5 Oct 27, 2008
7 Considerations for Civic Addresses in PIDF-LO
8 draft-ietf-geopriv-civic-address-recommendations-00
10 Status of this Memo
12 By submitting this Internet-Draft, each author represents that any
13 applicable patent or other IPR claims of which he or she is aware
14 have been or will be disclosed, and any of which he or she becomes
15 aware will be disclosed, in accordance with Section 6 of BCP 79.
17 Internet-Drafts are working documents of the Internet Engineering
18 Task Force (IETF), its areas, and its working groups. Note that
19 other groups may also distribute working documents as Internet-
20 Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six months
23 and may be updated, replaced, or obsoleted by other documents at any
24 time. It is inappropriate to use Internet-Drafts as reference
25 material or to cite them other than as "work in progress."
27 The list of current Internet-Drafts can be accessed at
28 http://www.ietf.org/ietf/1id-abstracts.txt.
30 The list of Internet-Draft Shadow Directories can be accessed at
31 http://www.ietf.org/shadow.html.
33 This Internet-Draft will expire on April 30, 2009.
35 Abstract
37 This document provides a guideline for creating civic address
38 consideration documents for individual countries, as required by RFC
39 4776. Since civic addresses may have a different format in
40 individual countries, such address considerations are necessary in
41 order to map the civic address fields to the PIDF Location Object
42 (PIDF-LO) elements.
44 Table of Contents
46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
50 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
52 4. Specifying PIDF-LO Element Usage . . . . . . . . . . . . . . . 4
53 4.1. Country . . . . . . . . . . . . . . . . . . . . . . . . . 6
54 4.2. Country Subdivisions A1-A6 . . . . . . . . . . . . . . . . 6
55 4.3. Road and Street Names . . . . . . . . . . . . . . . . . . 7
56 4.4. House Numbers . . . . . . . . . . . . . . . . . . . . . . 7
57 4.5. Local Names . . . . . . . . . . . . . . . . . . . . . . . 8
58 4.6. Floors . . . . . . . . . . . . . . . . . . . . . . . . . . 9
59 4.7. Address Codes . . . . . . . . . . . . . . . . . . . . . . 9
60 4.8. Other Elements . . . . . . . . . . . . . . . . . . . . . . 10
62 5. Austria Example . . . . . . . . . . . . . . . . . . . . . . . 11
63 5.1. Civic Address Format in Austria . . . . . . . . . . . . . 11
64 5.2. Sample Addresses . . . . . . . . . . . . . . . . . . . . . 16
65 5.3. Address Codes in Austria . . . . . . . . . . . . . . . . . 17
66 5.4. Austrian Addresses in PIDF-LO . . . . . . . . . . . . . . 17
67 5.4.1. Country . . . . . . . . . . . . . . . . . . . . . . . 17
68 5.4.2. Country Subdivisions A1-A6 . . . . . . . . . . . . . . 17
69 5.4.3. A4 Element . . . . . . . . . . . . . . . . . . . . . . 20
70 5.4.4. A5 Element . . . . . . . . . . . . . . . . . . . . . . 20
71 5.4.5. Road and Street Names . . . . . . . . . . . . . . . . 20
72 5.4.6. House Numbers . . . . . . . . . . . . . . . . . . . . 20
73 5.4.7. Local Names . . . . . . . . . . . . . . . . . . . . . 22
74 5.4.8. Floors . . . . . . . . . . . . . . . . . . . . . . . . 22
75 5.4.9. Additional Code Element . . . . . . . . . . . . . . . 22
76 5.4.10. Other Elements . . . . . . . . . . . . . . . . . . . . 22
77 5.4.11. Elements not to be used . . . . . . . . . . . . . . . 23
78 5.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 23
80 6. Security & Privacy Considerations . . . . . . . . . . . . . . 24
82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25
88 9.2. Informative References . . . . . . . . . . . . . . . . . . 25
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
91 Intellectual Property and Copyright Statements . . . . . . . . . . 27
93 1. Introduction
95 The "Presence Information Data Format Location Object" (PIDF-LO)
96 [RFC4119] is an an object format for carrying geographical
97 information on the Internet. PIDF-LO can be used to carry civic
98 address information, and supports a range of "civic address types"
99 (CATypes) to describe individual attributes of an civic address (see
100 Section 2.2.1 of RFC 4119 and Section 3.1 of RFC 5139, the revised
101 set of CATypes).
103 In many use cases, PIDF-LOs are populated with data from long-
104 established sources, like postal or governmental building registers,
105 line information databases and yellow / white pages of infrastructure
106 providers, or official residents registers. The structure and format
107 of data from these sources is almost always different from PIDF-LO's
108 CAtypes definition - additionally, structure and format of those
109 sources differs from country to country.
111 To make use of such existing data sources, instructions for
112 transposing such data into PIDF-LO format (element mapping) is
113 required. Preferrably, those mapping operations are reversable, so
114 that location receipients like public safety answering points (PSAPs)
115 can reconcile such PIDF-LOs with the original data source.
116 Additionally, for any data source just a single mapping should exist
117 in order to reduce the risk of ambiguous interpretation.
119 Therefore, civic address considerations are necessary for individual
120 countries to ensure uniform usage of PIDF-LO elements. RFC 4776
121 explicitly asks for such documents. This guideline aims to support
122 the creation of such civic address considerations. For some
123 countries RFC4776 already has some considerations on the
124 administrative sub-divisions in Section 3.4. Note that these
125 examples are not compliant to RFC 5139 [RFC5139], since the A6
126 element is not used for street names any more.
128 This guideline document is based on the experience of writing such a
129 civic address considerations document for Austria. Since there were
130 some difficulties when trying to define a mapping for Austrian civic
131 address fields to PIDF-LO, this document summarizes important
132 experience and issues to consider. Even though every country has
133 it's own address format and therefore other problems will occur, this
134 guideline should help to identify difficulties. As examples,
135 Austrian addresses are used.
137 2. Terminology
139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141 document are to be interpreted as described in RFC 2119 [RFC2119].
143 3. Requirements
145 The following requirements apply to defining address mapping
146 considerations:
147 o For any data source, all elements must be considered (even if some
148 of those fields are to be left out of the mapping, the document
149 must describe that).
150 o Any CAtype field registered by the time the document is produced
151 must be considered, and if it is not being used, that fact must be
152 mentioned. In case the set of CAtypes is revised by the IETF, the
153 address consideration document should be updated. Until then, the
154 old mapping procedure must be used.
155 o Address mappings should be reversible, so that location recepients
156 can identify the original records if they have access to the
157 original source
158 o For any element used, at least one example must be provided.
160 4. Specifying PIDF-LO Element Usage
162 The purpose of the civic address consideration document for an
163 individual country is to specify the list of PIDF-LO elements to be
164 used, and the mapping between these elements and the fields of the
165 respective local data source.
167 The motivation for such a civic address consideration is to ensure
168 interoperability. Location recipients certainly want to rely on
169 finding civic address parts in defined elements of PIDF-LO for
170 further processing. Especially when it comes to emergency calling,
171 location information is a critical data where misinterpretation has
172 to be avoided. Therefore, a consistent mapping scheme is required.
173 Since it is not possible to have global PIDF-LO elements which can be
174 unambiguously used in every country in the world, the mapping must be
175 defined on an national level. It has to be ensured, that the mapping
176 is used for all civic addresses in this country.
178 Is is important to identify the civic address fields that can be
179 mapped directly to the corresponding PIDF-LO elements and which civic
180 address parts need special consideration. PIDF-LO elements that are
181 not needed in a specific country, can simply be omitted. The civic
182 address consideration document has to specify clearly that those
183 elements must not be used for representing civic addresses in this
184 country.
186 Even though the list of CAtypes could be extended, it is no feasible
187 to add new elements for any new field in any data source in any
188 country. Therefore, unless new CAtypes are specified by the IETF,
189 just the existing elements can be used. That leaves the following
190 two options in case the CAtypes do not provide a perfect fit for
191 local civic address data (especially in case the local data contains
192 more fields than PIDF-LO provides):
193 1. Concatenate several civic address fields into a single PIDF-LO
194 element (define delimiters if applicable and make sure the
195 separate civic address parts can be retrieved again)
196 2. Use a PIDF-LO element that is unused so far
198 All existing civic address parts must find a place in the PIDF-LO.
199 Even exotic addresses, that might be very rare, must be considered.
200 Civic addresses can be very complex in some countries. So it is very
201 important to identify the data source that is representing all the
202 possible civic addresses in a country. Perhaps this database is
203 maintained by a governmental company, by an authority, or the post.
204 Moreover, it is important, that this data format is accepted by
205 Public Safety Answering Point (PSAP) operators and they have access
206 to the data source. Even PSAPs within a country may be organized
207 differently and use different data bases for civic addresses. It is
208 crucial to define the PIDF-LO mapping in a way that all PSAPs can use
209 it. It is disireable to have PSAP operators involved in the process
210 of developing civic address considerations, so that their needs are
211 especially considered.
213 Although the mapping is defined in a national way and the actual
214 meaning of several PIDF-LO elements may not be clear to an outsider,
215 at least the country element tells in what context this PIDF-LO was
216 created. In case of emergency calls, a PIDF-LO would just be passed
217 to a PSAP in the same country as the location generator anyway.
218 However, in border region there might be exceptions and the PIDF-LO
219 is sent to a neighboring country. The PIDF-LO can still be passed on
220 to a PSAP in the right country because of the country element or the
221 PSAP knows the mapping of the neighbor country.
223 A consistent mapping is also very important for checking if two
224 PIDF-LO documents describe the same location. When civic address
225 fields are put into different PIDF-LO elements, it may be difficult
226 to recognize two equal addresses.
228 The following sections discuss individual PIDF-LO elements and
229 describe what to consider when defining civic address considerations.
231 4.1. Country
233 The country element must hold the alpha-2 codes from ISO 3166-1
234 [refs.ISO3166-1] in upper case characters as clarified in Section 3.3
235 of RFC 5139 [RFC5139].
237 This element cannot be redefined on a national basis since it
238 identifies the country itself. This element is used to identify
239 which national mapping for civic addresses has been used in a
240 specific PIDF-LO.
242 Example for Austria: AT
244 4.2. Country Subdivisions A1-A6
246 The elements A1 to A6 are used to hold national subdivision
247 identifiers, with A1 holding the top-level subdivision identifier.
248 A1 may either contain the second part of ISO 3166-2 [refs.ISO3166-2]
249 (see section 3.4 of RFC 5139 [RFC5139]), or values as described in
250 the address consideration document for that country. Elements "A2"
251 to "A6" may contain additional levels of subdivisions (see section
252 2.2.1 of RFC 4119).
254 For A1, an address consideration document for a country should state
255 whether ISO 3166-2 codes are to be used, alternatively it should
256 define a list of valid values to be used (for example, subdivision
257 names). In either case, A1 must not be redefined for any other use
258 than describing top level subdivisions.
260 The document should also specify for each of the A2 - A6 elements
261 whether they are required, optional, or not allowed. For each
262 element that is required or optional, it should define the set of
263 valid values, either by listing them, or referring to such a list.
265 For countries which are already discussed in section 3.4 of RFC 4776,
266 it is recommended to follow those mappings.
268 Example for Austria
270 A1 province (Bundesland)
271 A2 political district name or identifier (politscher Bezirk)
272 A3 commune name or identifier (Gemeinde)
273 A4 village name or identifier (Ortschaft)
274 A5 cadastral municipality name or identifier (Katastralgemeindename
275 or Katastralgemeindenummer)
277 A6 must not be used. For more details see the example in
278 Section 5.4.2.
280 4.3. Road and Street Names
282 PIDF-LO contains the following elements related to road names: RD,
283 RDSEC, RDBR, RDSUBADDR, PRM, POM (section 3.1 and 3.2 of RFC 5139
284 [RFC5139]) and PRD, POD, STS (section 3.4 of [RFC4776]). Note that
285 the use of the A6 element for street names is not valid (Section 3.2
286 of RFC 5139 [RFC5139]).
288 An address considerations document for a country should specify which
289 of those nine elements are required, optional or not allowed. If
290 neccessary, the document may also describe more complicated
291 dependencies (for example, "RD is optional, but required if any other
292 road name element is used").
294 For any required or optional element, it should describe the relation
295 of those elements to elements of the data source used. If special
296 considerations apply to certain elements, they should be described.
297 Also focus on the element STS, the street suffix. It must be assured
298 that this suffix is used in a consistent way. In case no suffixes
299 are known in a country or it is common to write the street name and
300 the suffix together, it is allowed to forbid the usage of the STS
301 element completely. Suffixes may also be abbreviated. Define the
302 common abbreviations.
304 Example for Austria:
306 RD: street name
308 All other road elements must not be used, street suffix is already
309 included in RD element. Street suffixes must not be abbreviated.
311 4.4. House Numbers
313 PIDF-LO specifies two elements related to house numbers: "house
314 number" (HNO, numeric part only) and "house number suffix" (HNS) (see
315 section 3.4 of RFC 4776). However, in many countries house numbers
316 have a more complex format. In any case, a clear definition on
317 mapping national house numbers to PIDF-LO is needed to minimize
318 confusion potential.
320 An address consideration document for a country should provide the
321 following information with regards to house numbers: If the structure
322 of house numbers in that country fits the HNO/HNS structure, the
323 document must mandate to use those fields as described in RFC 4776.
324 If the structure of house numbers does not directly fit into those
325 two elements, the document must propose rules on how to map origin
326 data into PIDF-LO elements. Besides HNO and HNS, LOC and BLD could
327 be considered for carrying house number information.
329 The document should describe whether abbreviations of house number
330 elements are valid or not. If abbreviations are used, they must be
331 clearly defined. If the house number consists of more than one
332 number or multiple prefixes and suffixes may coexist, a delimiter
333 symbol and a clear rule on how to concatenate all this data into the
334 HNO and HNS element might be necessary. Whenever concatenating data
335 into one field, keep in mind that the location recipient might want
336 to separate the data again.
338 Example from Austria:
340 HNO: concatenate all the data elements of Austrian house numbers into
341 this single PIDF-LO element in a defined order with delimiter symbols
342 (see Section 5.4.6 for the complete definition).
344 HNS: not recommended to be used since there may be multiple suffixes
345 for the different parts of the house number.
347 4.5. Local Names
349 PIDF-LO contains three elements to reflect local names: LMK, LOC, NAM
350 (section 3.4 of RFC 4776). Such local names may be of importance for
351 the identification of a location, and may either coexist with a valid
352 civic address or (in some cases) no address may be assigned so that
353 the local names itself identify the location. In rural regions for
354 example, a farm name may be more common than a street address to
355 identify a location. Therefore, local names may either assist in
356 finding a "street name" type addess, but they might also be the
357 authoritative (and only) location information.
359 Address consideration documents for individual countries should state
360 for each of the LMK, LOC, NAM elements whether they are required,
361 optional, or not to be used. For any required or optional field, it
362 should state potential values (source data) for the element. In case
363 that multiple values for an element may occur, a concatenation /
364 selection strategy should be described. Concatenation using ";" as
365 seperator is recommended.
367 If local name information and "common" address information is both
368 available and used, the document should discuss the relation between
369 those two address information types, and expected behaviour of
370 location receipients.
372 Example from Austria:
374 NAM: contains the "Vulgoname" (local name), multiple local names are
375 separated by a semicolon (if applicable)
376 LMK: contains the farm name (just one name possible) (if applicable)
378 LOC: can be used without restriction for additional location
379 information (as per RFC 4119)
381 The "Vulgoname" is useful to identify the location within its
382 locality, since official addresses especially in rural regions might
383 not be well known.
385 4.6. Floors
387 PIDF-LO defines the element FLR to hold the floor information, but
388 does not further specify its content. Section 2.1 of RFC 3825
389 provides guidance about floor numbering, but is not directly related
390 to PIDF-LO.
392 An address consideration document for a country should clearly
393 specify how to express floors using the FLR element. Following the
394 above mentioned guidance is recommended, however, local nomenclature
395 might require a completely different system. The document should
396 specify whether only numbers, text, or both are allowed in the FLR
397 element. If there are standard values for certain floors, they
398 should be listed. Abbreviations should be avoided, unless they are
399 the primary way of identifying floors.
401 Example from Austria:
403 Numbers and text allowed. The first floor (1) is the
404 first "full" floor above the floor at street level. The floor at
405 street level is EG or 0. There might be
406 intermediate floors, especially between the floor at street level and
407 the "first floor". Such intermediate floors have names like
408 "Mezzanine", "Erster Halbstock" ("first half floor"), "Zweiter
409 Halbstock" ("second half floor").
411 4.7. Address Codes
413 Address codes are available in several countries in different forms
414 (for estates, buildings or usable units for example). These codes
415 identify an address record, and can be placed in the ADDCODE element
416 in PIDF-LO. Address codes can help the location recipient to
417 determine the location, and to identify the original record in the
418 data source. Depending on the type of code, the code alone may be
419 sufficient as location information within a country.
421 The PIDF-LO country element can be used to identify the name space in
422 which the address code elements are valid. Countries may have more
423 than one type of address codes (multiple namespaces), so it might be
424 necessary to choose the code that is most widely accepted (by PSAPs)
425 or to have identifiers for the different codes.
427 A PIDF-LO containing just the country and ADDCODE elements might
428 provide enough information to retrieve a civic address, given the
429 location recipient has access to the respective source database.
431 A civic address considerations document for a country should specify
432 whether and in which applications the use of ADDCODE elements is
433 allowed. If ADDCODE is used, its relation to the remaining elements
434 must be clearly stated. If several namespaces for address codes
435 exist in a country, a mechanism to distinguish the different code
436 spaces must be described.
438 Examples from Austria:
440 Statistik Austria provides 4 codes: Adresscode (AdrCD), Adresssubcode
441 (AdrsubCD), Objektnummer (ObjNr) and Nutzungseinheitenlaufnummer
442 (NtzLnr).
444 The following format should be used:
446 AdrCD=1234567;AdrsubCD=123;ObjNr=2333211;NtzLnr=0001
448 4.8. Other Elements
450 This section lists all the other PIDF-LO elements, that are not
451 considered so far.
453 To specify the location inside a building, the following elements can
454 be useful:
456 UNIT
458 ROOM
460 SEAT
462 The following elements are related to postal codes:
464 PC
466 PCN
468 POBOX
470 To describe the place-type or the building, the following elements
471 are available:
473 PLC - Place-type (see RFC 4589)
475 BLD - Building (structure)
477 The xml:lang attribute should be present in PIDF-LO XML documents.
479 An address considerations document should specify for any of those
480 elements whether they are required, optional, or must not be used.
481 For any element that is required or optional, the semantics of its
482 contents must be described, if it differs from the PIDF-LO base
483 documents.
485 5. Austria Example
487 The Austrian "Gebaeude- und Wohnungsregistergesetz" (building and
488 habitation registry law) is the legal basis for the obligation to
489 provide a registry of civic addresses, buildings and their usable
490 units (subdivisions of buildings). The registry is operated by
491 "Statistik Austria GmbH", a fully governmental owned company.
492 Responsibility for keeping records in the registry up to date is an
493 obligation to the local administration of the individual townships.
495 The data format definition for the individual records is publicly
496 available (data access itself is however restricted). Hence, an
497 uniform address data base for whole Austria is available.
498 Unfortunately, Austrian civic addresses use a much more complex
499 format compared to civic addresses in PIDF-LO. A detailed
500 description of the Austrian civic address data format is contained in
501 section Section 5.1.
503 A guideline of how to use PIDF-LO for Austrian addresses is necessary
504 in order to avoid misinterpretations. This is especially important
505 if the PIDF-LO is conveyed during an emergency call to a Public
506 Safety Answering Point (PSAP). A precise location information is
507 needed in case of emergency to send out responders without any delay
508 to the correct location of the caller. If every data-provider uses
509 its own address mapping to PIDF-LO, confusion and misunderstandings
510 are bound to happen. However, ideally any PSAP should have full
511 access to the data by Statistik Austria. PSAPs must be able to rely
512 that location information is always provided the same way by all
513 data-providers. To address the idiosyncrasies in Austria, the civic
514 address elements are discussed subsequently.
516 5.1. Civic Address Format in Austria
518 Statistik Austria data describes estates, buildings and usable units
519 [refs.merkmalskatalog]. On a single estate there may be any number
520 of buildings. Apartment houses that have more than one staircase,
521 are split up in separate buildings at every staircase. In every
522 building, there may be several usable units. For example, an
523 apartment house may have several apartments, counting as separate
524 usable units. Moreover, one building may have more than one address,
525 but at least one address. Below, the address elements for estates
526 (Table 1), buildings (Table 2) and usable units (Table 3) are shown.
528 +-------------------------+-------------------------------+---------+
529 | Statistik Austria name | Explaination | PIDF-LO |
530 | | | Element |
531 +-------------------------+-------------------------------+---------+
532 | Adresscode | address identifier | ADDCODE |
533 | | | |
534 | Gemeindename, | commune name and identifier | A3 |
535 | Gemeindekennziffer | | |
536 | | | |
537 | Ortschaftsname, | village name and identifier | A4 |
538 | Ortschaftskennziffer | | |
539 | | | |
540 | Strassenname, | street name and identifier | RD |
541 | Strassenkennziffer | | |
542 | | | |
543 | Katastralgemeindename, | cadastral municipality and | A5 |
544 | Katastralgemeindenummer | identifier | |
545 | | | |
546 | Hausnummerntext | text in front of the house | HNO |
547 | | number | |
548 | | | |
549 | Hausnummer - 1. Teil - | first part of the house | HNO |
550 | Nummer | number, numeric | |
551 | | | |
552 | Hausnummer - 1. Teil - | first part of the house | HNO |
553 | Buchstabe | number, character | |
554 | | | |
555 | Hausnummer - | links first and Bis part of | HNO |
556 | Verbindungszeichen Teil | house number | |
557 | 1 -> Bis | | |
558 | | | |
559 | Hausnummer - Bis-Nummer | number of bis part of house | HNO |
560 | | number | |
561 | | | |
562 | Hausnummer - | character of bis part of | HNO |
563 | Bis-Buchstabe | house number | |
564 | | | |
565 | Hausnummernbereich | indicates if all house | HNO |
566 | | numbers specified or just odd | |
567 | | or even numbers are stated | |
568 | | | |
569 | Postleitzahl | postal code | PC |
570 | | | |
571 | Postleitzahlengebiet | postal community code | PCN |
572 | | | |
573 | Vulgoname | local name | NAM |
574 | | | |
575 | Hofname | farm name | LMK |
576 +-------------------------+-------------------------------+---------+
578 Table 1: Civic Address Elements for Estates
580 +------------------------+--------------------------------+---------+
581 | Statistik Austria name | Explaination | PIDF-LO |
582 | | | Element |
583 +------------------------+--------------------------------+---------+
584 | Adressubcode | address subcode | ADDCODE |
585 | | | |
586 | Objektnummer | object code | ADDCODE |
587 | | | |
588 | Hausnummer - | links Bis and second part of | HNO |
589 | Verbindungszeichen | house number | |
590 | Teil Bis -> Teil 2 | | |
591 | | | |
592 | Hausnummer - 2. Teil - | second part of the house | HNO |
593 | Nummer | number, numeric | |
594 | | | |
595 | Hausnummer - 2. Teil - | second part of the house | HNO |
596 | Buchstabe | number, character | |
597 | | | |
598 | Hausnummer - | links second and third part of | HNO |
599 | Verbindungszeichen | house number | |
600 | Teil 2-> Teil 3 | | |
601 | | | |
602 | Hausnummer - 3. Teil - | third part of the house | HNO |
603 | Nummer | number, numeric | |
604 | | | |
605 | Hausnummer - 3. Teil - | third part of the house | HNO |
606 | Buchstabe | number, character | |
607 | | | |
608 | Gebaeudeunterscheidung | for differentiation of | HNO |
609 | | buildings, e.g. Maierweg 27 | |
610 | | Hotel vers. Maierweg 27 | |
611 | | Appartmenthaus | |
612 | | | |
613 +------------------------+--------------------------------+---------+
615 Table 2: Additional Civic Address Elements for Buildings
617 +-----------------------------+---------------------------+---------+
618 | Statistik Austria name | Explaination | PIDF-LO |
619 | | | Element |
620 +-----------------------------+---------------------------+---------+
621 | Nutzungseinheitenlaufnummer | usable unit code | ADDCODE |
622 | | | |
623 | Tuernummer | door number | HNO |
624 | | | |
625 | Topnummer | unit number | HNO |
626 | | | |
627 | Lagebeschreibung | for verbal description | HNO |
628 | | | |
629 | Lage | describes if the usable | FLR |
630 | | unit is in the basement, | |
631 | | mezzanine, attic floor, | |
632 | | ... (but not the floor | |
633 | | number) | |
634 | | | |
635 | Stockwerk | floor | FLR |
636 | | | |
637 +-----------------------------+---------------------------+---------+
639 Table 3: Additional Civic Address Elements for usable units
641 Note: "Floors" in Austria (as in most parts of Europe) are counted
642 differently compared to the US. The "1st floor" in Austria is
643 actually the floor above the floor at street level (2nd floor in US),
644 not considering the fact that in old buildings there might be even
645 more floors between street level and 1st floor, like "mezzanine",
646 "2nd mezzanine". So, an Austrian "1st floor" could well be the "4th
647 floor" according to US nomenclature.
649 According to Statistik Austria [refs.adrwarten], 81.5% of Austrian
650 addresses are of the simple type Musterstrasse 1 (Musterstrasse is an
651 example street name). 5% of all addresses have an additional
652 character, like Musterstrasse 1b. 1% of Austrian addresses look like
653 Musterstrasse 21A - 23A. For 8% of addresses, an additional separator
654 is necessary, like Musterstrasse 10 Haus 1 Stiege 2 or Musterstrasse
655 20 Gruppe A Reihe 1 Parzelle 13 or Musterstrasse 30 Weg 1 Parzelle
656 10. Very seldom, there are so called special addresses (0.03%), for
657 example Musterstrasse gegenueber 3a, meaning this address is actually
658 vis-a-vis of house number 3A. Rather surprisingly, 4.47% of Austrian
659 addresses contain the identifier of the estate since no house number
660 is assigned at all, for example: Musterstrasse GNR 1234, or
661 Musterstrasse GNR .12/4 Kirche (this type of addresses is common for
662 churches) or a real example in Stockerau: Kolomaniwoerth GNR 1583.
663 This identifier is stored by Statistik Austria as Hausnummerntext.
664 Otherwise one could misinterpret this number as a house number, what
665 would be definitely wrong.
667 5.2. Sample Addresses
669 In order to clarify the Austrian civic address format, this section
670 provides some exemplary addresses:
672 1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1
673 Postleitzahl: 1234
674 Stadt: Musterstadt
675 Strasse: Hauptstrasse
676 Hausnummer - 1. Teil - Nummer: 1
677 Hausnummer - 1. Teil - Buchstabe: a
678 Hausnummer - Verbindungszeichen Teil 1 -> Bis: -
679 Hausnummer - 2. Teil - Nummer: 5
680 Hausnummer - 2. Teil - Buchstabe: a
681 Hausnummer - Verbindungszeichen Teil Bis -> Teil 2: Block
682 Hausnummer - 2. Teil - Nummer: 1
683 Hausnummer - 2. Teil - Buchstabe: b
684 Hausnummer - Verbindungszeichen Teil 2-> Teil 3: Haus
685 Hausnummer - 3. Teil - Nummer: 2
686 Hausnummer - 3. Teil - Buchstabe: c
687 Gebaeudeunterscheidung: Stiege 1
689 1234 Musterstadt, Musterstrasse 13 Hotel
690 Postleitzahl: 1234
691 Stadt: Musterstadt
692 Strasse: Musterstrasse
693 Hausnummer - 1. Teil - Nummer: 13
694 Gebaeudeunterscheidung: Hotel
696 6020 Innsbruck, Anichstrasse vor 35
697 Postleitzahl: 6020
698 Stadt: Innsbruck
699 Strasse: Anichstrasse
700 Hausnummerntext: vor ("in front of")
701 Hausnummer: 35
703 6173 Oberperfuss, Riedl 3097 (Pfarrkirche)
704 Postleitzahl: 6173
705 Stadt: Oberperfuss
706 Strasse: Riedl
707 Hausnummerntext: 3097
708 (since the estate identifier is 81305 3097 where 81305 is the
709 Katastralgemeindenummer (cadastral municipality) and no house
710 number is assigned)
711 Vulgoname: Pfarrkirche
713 5.3. Address Codes in Austria
715 Statistik Austria registers 4 codes: Adresscode, Adresssubcode,
716 Objektnummer and the Nutzungseinheitenlaufnummer. The Adresscode (7
717 digits) is a unique code for an address in Austria. The
718 Adressregister maps the Adresscode to the civic address. If there is
719 a building located at an address, there is also an Adresssubcode (3
720 digits) assigned. Every building at an address has its own
721 Adresssubcode (assigned sequentially starting with 001, 002, 003 and
722 so on) in order to distinguish between buildings at the same address.
723 Furthermore, every building located in Austria has its own unique
724 code, the Objektnummer (7 digits). This code identifies the building
725 independent of the Adresscode. That's because addresses are subject
726 to change while the building may persist. To differ multiple usable
727 units inside a building, the Nutzungseinheitenlaufnummer (4 digits)
728 is used. This code is also assigned in sequential order for each
729 building.
731 Besides, every address and building is geocoded by Statistik Austria.
732 Hence, if every PIDF-LO location object would carry data in the
733 format of Statistik Austria and every PSAP would use the database of
734 Statistik Austria for mapping, a time saving, definite mapping
735 without irregularities could be achieved.
737 Besides these codes, Statistik Austria maintains reference numbers
738 for communes, localities or streets, to mention just a few.
740 5.4. Austrian Addresses in PIDF-LO
742 A good number of Austrian addresses do not fit into the PIDF-LO
743 format, as described above. So the following subsection define the
744 mapping procedure.
746 5.4.1. Country
748 The country element for Austria must be set to AT, since this is the
749 ISO 3166-1 [refs.ISO3166-1] alpha-2 code for Austria.
751 AT
753 The usage of the ISO 3166 code is demanded by RFC 4119 [RFC4119] and
754 RFC 5139 [RFC5139] proposes to use upper case characters only.
756 5.4.2. Country Subdivisions A1-A6
757 A1 province (Bundesland), Section 5.4.2.1
758 A2 political district name or identifier (politscher Bezirk),
759 Section 5.4.2.2
760 A3 commune name or identifier (Gemeinde), Section 5.4.2.3
761 A4 village name or identifier (Ortschaft), Section 5.4.2.4
762 A5 cadastral municipality name or identifier (Katastralgemeindename
763 or Katastralgemeindenummer), Section 5.4.2.5
765 Element A6 must not be used.
767 Last, there is an exception to mention concerning the Austrian
768 capital Vienna (Wien). The city of Vienna is equal to its political
769 district and even the province is called Vienna. Nevertheless,
770 Vienna is separated in 23 districts within the same political
771 district. Consequently, an address in Vienna would look like:
773 AT
774 Wien
775 Wien
776 Wien
777 Favoriten or 10
778 Inzersdorf Stadt
780 The element A4, holding the city division, can hold the name or the
781 number of the district.
783 5.4.2.1. A1 Element
785 As proposed in RFC 5139 [RFC5139], for the PIDF-LO element A1, the
786 second part of ISO 3166-2 [refs.ISO3166-2] can be used. However, in
787 Austria it is also common to write out the names of the states.
788 Table 4 shows the possible values of the A1 element for Austrian
789 states.
791 +-------------------+--------------------------------+
792 | Bundesland | second part of ISO 3166-2 code |
793 +-------------------+--------------------------------+
794 | Burgenland | 1 |
795 | | |
796 | Kaernten | 2 |
797 | | |
798 | Niederoesterreich | 3 |
799 | | |
800 | Oberoesterreich | 4 |
801 | | |
802 | Salzburg | 5 |
803 | | |
804 | Steiermark | 6 |
805 | | |
806 | Tirol | 7 |
807 | | |
808 | Vorarlberg | 8 |
809 | | |
810 | Wien | 9 |
811 +-------------------+--------------------------------+
813 Table 4: A1 element format for Austria
815 5.4.2.2. A2 Element
817 Names of the Austrian political districts are available at Statistik
818 Austria [refs.bezirke]. These names, the unique code for the
819 politcal district or both can be used for the A2 element. If the
820 content of the A2 elment is numeric, obviously the code is provieded
821 (there is no political district in Austria with a number in its
822 name). In case both, the name and the code are provided, they are
823 seperated by a semicolon, and the name must be listed first.
825 The district of "Bruck an der Leitha" could be represented by:
827 Bruck an der Leitha or 307 or
828 Bruck an der Leitha;307
830 5.4.2.3. A3 Element
832 The element A3 holds the Gemeindename (commune name) or the
833 identifier of the Gemeinde, or both separated by a semicolon (the
834 name must be listed first). If the content of the A3 element
835 consists of a number only, it is obvious that just the identifier is
836 provided. Statistik Austria maintains a table with the Gemeindenamen
837 and identifiers [refs.gemeinden], which must be used as the content
838 for the A3 element, no other spelling is allowed.
840 Sample:
842 Neusiedl am See
843 or
844 10713
845 or
846 Neusiedl am See;10713
848 5.4.3. A4 Element
850 The element A4 holds the Ortschaftsname (village name), the
851 Ortschaftskennziffer (the identifier), or both separated by a
852 semicolon (the name must be listed first). If the content of the A4
853 element consists of a number only, it is obvious that just the
854 identifier is provided since there are no Ortschaftsnamen in Austria
855 which contain a number. Statistik Austria maintains a table with the
856 Ortschaftsnamen and identifiers [refs.ortschaften], which must be
857 used as the content for the A4 element, no other spelling is allowed.
859 Sample:
861 Wilfleinsdorf or 03448 or Wilfleinsdorf;03448
863 5.4.4. A5 Element
865 The element A5 holds the Katastralgemeindename (cadastral
866 municipality), the Katastralgemeindekennziffer (the identifier), or
867 both separated by a semicolon (the name must be listed first). If
868 the content of the A5 element consists of a number only, it is
869 obvious that just the identifier is provided since there are no
870 Katastragemeindenamen in Austria which contain a number.
872 Sample (Vienna, Fuenfhaus):
874 Oberbaumgarten or 1208 or
875 Oberbaumgarten;1208
877 5.4.5. Road and Street Names
879 The PIDF-LO element RD holds the complete street name, including the
880 street suffix. No abbreviations are allowed. No other elements are
881 needed for streets and must not be used.
883 5.4.6. House Numbers
885 Statistik Austria lists 14 data fields related to the house number of
886 a building plus another 5 fields for distinction of different usable
887 units inside a building (including the floor, which has a separate
888 element in PIDF-LO). Unfortunately, PIDF-LO only defines a single
889 house number element (HNO, numeric part only) and a house number
890 suffix element (HNS). Therefore, the rules of the HNO element have
891 to be violated in order to accomodate all data: All house number data
892 is concatenate into a single HNO element, even though it is expected
893 to hold numeric part only.
895 If the location recipient does not need to separate the data elements
896 again, the house number parts may be simply concatenated with spaces
897 in between (no spaces between the numeric part of a house number and
898 its related character). However, if the location recipient needs to
899 get back the original data, it is necessary to use a semicolon as
900 delimiter symbol (Austrian house numbers do not contain semicolons).
901 The house number parts MUST be provided in the order as they are
902 listed by the Statistik Austria document [refs.merkmalskatalog]. For
903 user interface representation, the semicolon separated format can be
904 transformed by replacing semicolons by spaces (multiple spaces should
905 be combined) and no space should be present between a numeric part of
906 a house number part and its related character.
908 It is recommended, not to use the HNS element for Austrian addresses,
909 since there are addresses that do not have just a single suffix. For
910 example, the address Lazarettgasse 13A could be mapped by:
912 13 A
914 However, the building at Lazarettgasse has the house number 13A -
915 13C. Consequently, just the HNO element should be used:
917 13A - 13C
919 And even for addresses with a house number consisting of a single
920 number and a single prefix, just HNO should be used because of
921 uniformity:
923 13A
925 Addresses with a house number text would look like:
927 vor 1 - 1A
929 with no HNS element.
931 The same example with semicolon as delimiter symbol would look like:
933 vor;1;;-;1;A;;;;;;;;;;;
935 5.4.7. Local Names
937 NAM: contains the Vulgoname (local name), multiple local names are
938 separated by a semicolon (if applicable)
940 LMK: contains the farm name (just one name possible) (if applicable)
942 LOC: can be used without restriction for additional location
943 information (as per RFC 4119)
945 5.4.8. Floors
947 The floor element may contain numbers or text describing the floor.
948 The first floor (1) is the floor above the floor at street
949 level. The floor at street level is EG or 0.
950 Other floors may have names like mezzanine, for example. The
951 Statistik Austria data elements Lage and Stockwerk are concatenated
952 if necessary.
954 5.4.9. Additional Code Element
956 The element additional code may be used to hold the codes provided by
957 Statistik Austria. There is an Adresscode, Adressubcode,
958 Objektnummer and a Nutzungseinheitenlaufnummer. These unique codes
959 identify the location. Actually, these codes alone would be enough,
960 but requires that the location recipient has access to the database
961 of Statistik Austria.
963 If the additional code in a PIDF-LO document is going to hold the
964 codes from Statistik Austria, the following format should be used:
966 AdrCD=1234567;AdrsubCD=123;ObjNr=2333211;NtzLnr=0001
968 It is not necessary to provide all codes, but there are some
969 restrictions: The Adresssubcode cannot be used without an Adresscode.
970 More restrictions are definded by Statistik Austria. By setting the
971 country element to AT (see Section 4.1), indicating an Austrian
972 address, the Additional Code element is expected to hold codes from
973 Statistik Austria only. When creating PIDF-LO documents using
974 address codes by Statistik Austria, the country and ADDCODE elements
975 are mandatory.
977 5.4.10. Other Elements
979 The elements PC and PCN can hold the data form Statistik Austria, the
980 POBOX can be used if the post assigned a post office box. At least
981 the PC element should be present.
983 PC: Postleitzahl (postal code)
985 PCN: Postleitzahlengebiet (postal community name)
987 POBOX: Postfach
989 The elements UNIT, ROOM, SEAT, PLC and BLD may be used without
990 further restriction.
992 5.4.11. Elements not to be used
994 A6
995 STS
996 HNS
997 PRD
998 POD
999 RDBR
1000 RDSUBBR
1001 PRM
1002 POM
1004 5.5. Example
1006 This section shows an example mapping of an Austrian address mapping
1007 to PIDF-LO element.
1009
1010
1014
1015
1016
1017
1018
1019 AT
1020 Wien
1021 Wien
1022 Wien
1023 9
1024 Lazarettgasse
1025 ;13;A;-;13;C;;;;;;;;;;;;
1026 1090
1027
1028
1029
1030 yes
1031 2007-11-10T12:00:00Z
1032
1033
1034
1035 2007-11-09T12:00:00Z
1036
1037
1039 6. Security & Privacy Considerations
1041 RFC 4119 contains general security considerations for handling PIDF-
1042 LOs. In addition to that, it has to be considered that data from the
1043 Austrian building and habitation unit registry are generally not
1044 public, so restrictions as imposed on the original data set MUST also
1045 be imposed on the resulting PIDF-LO document.
1047 7. IANA Considerations
1049 At this stage, this document contains no considerations for IANA.
1051 8. Acknowledgements
1053 The authors wish to thank Gregor Jaenin for contributing insights
1054 about the Austrian civic address data format.
1056 9. References
1058 9.1. Normative References
1060 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1061 Requirement Levels", BCP 14, RFC 2119, March 1997.
1063 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
1064 Format", RFC 4119, December 2005.
1066 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
1067 (DHCPv4 and DHCPv6) Option for Civic Addresses
1068 Configuration Information", RFC 4776, November 2006.
1070 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
1071 Format for Presence Information Data Format Location
1072 Object (PIDF-LO)", RFC 5139, February 2008.
1074 9.2. Informative References
1076 [refs.adrwarten]
1077 Statistik Austria, "Handbuch Adress-GWR-Online Teil A
1078 Theoretisches Handbuch Kapitel 2 Warten von Adressen im
1079 Adress-GWR-Online", Jan 2005.
1081 [refs.merkmalskatalog]
1082 Statistik Austria, "Handbuch Adress-GWR-Online Teil C
1083 Anhang 2 Merkmalskatalog", Sept 2004.
1085 [refs.ISO3166-1]
1086 International Organization for Standardization, "Codes for
1087 the representation of names of countries and their
1088 subdivisions - Part 1: Country codes", ISO Standard 3166-
1089 1:1997, 1997.
1091 [refs.ISO3166-2]
1092 International Organization for Standardization, "Codes for
1093 the representation of names of countries and their
1094 subdivisions - Part 2: Country subdivision code", ISO
1095 Standard 3166-2:1998, 1998.
1097 [refs.bezirke]
1098 Statistik Austria, "Politische Bezirke, Gebietsstand
1099 2008", Feb 2008.
1101 [refs.gemeinden]
1102 Statistik Austria, "Gemeindeliste sortiert nach
1103 Gemeindekennziffer, Gebietsstand 2008", Feb 2008.
1105 [refs.ortschaften]
1106 Statistik Austria, "Gemeinden mit Ortschaften und
1107 Postleitzahlen, Gebietsstand 2008", Feb 2008.
1109 Authors' Addresses
1111 Karl Heinz Wolf
1112 nic.at GmbH
1113 Karlsplatz 1/2/9
1114 Wien A-1010
1115 Austria
1117 Phone: +43 1 5056416 37
1118 Email: karlheinz.wolf@nic.at
1119 URI: http://www.nic.at/
1121 Alexander Mayrhofer
1122 nic.at GmbH
1123 Karlsplatz 1/2/9
1124 Wien A-1010
1125 Austria
1127 Phone: +43 1 5056416 34
1128 Email: alexander.mayrhofer@nic.at
1129 URI: http://www.nic.at/
1131 Full Copyright Statement
1133 Copyright (C) The IETF Trust (2008).
1135 This document is subject to the rights, licenses and restrictions
1136 contained in BCP 78, and except as set forth therein, the authors
1137 retain all their rights.
1139 This document and the information contained herein are provided on an
1140 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1141 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1142 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1143 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1144 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1145 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1147 Intellectual Property
1149 The IETF takes no position regarding the validity or scope of any
1150 Intellectual Property Rights or other rights that might be claimed to
1151 pertain to the implementation or use of the technology described in
1152 this document or the extent to which any license under such rights
1153 might or might not be available; nor does it represent that it has
1154 made any independent effort to identify any such rights. Information
1155 on the procedures with respect to rights in RFC documents can be
1156 found in BCP 78 and BCP 79.
1158 Copies of IPR disclosures made to the IETF Secretariat and any
1159 assurances of licenses to be made available, or the result of an
1160 attempt made to obtain a general license or permission for the use of
1161 such proprietary rights by implementers or users of this
1162 specification can be obtained from the IETF on-line IPR repository at
1163 http://www.ietf.org/ipr.
1165 The IETF invites any interested party to bring to its attention any
1166 copyrights, patents or patent applications, or other proprietary
1167 rights that may cover technology that may be required to implement
1168 this standard. Please address the information to the IETF at
1169 ietf-ipr@ietf.org.