idnits 2.17.1
draft-ietf-geopriv-revised-civic-lo-02.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 on line 621.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 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 (April 28, 2006) is 6573 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)
== Outdated reference: A later version (-06) exists of
draft-ietf-geopriv-location-types-registry-05
Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV WG M. Thomson
3 Internet-Draft J. Winterbottom
4 Expires: October 30, 2006 Andrew
5 April 28, 2006
7 Revised Civic Location Format for PIDF-LO
8 draft-ietf-geopriv-revised-civic-lo-02.txt
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 October 30, 2006.
35 Copyright Notice
37 Copyright (C) The Internet Society (2006).
39 Abstract
41 This document defines an XML format for the representation of civic
42 location. This format is designed for use with PIDF Location Object
43 (PIDF-LO) documents. The format is based on the civic address
44 definition in PIDF-LO, but adds several new elements based on the
45 civic types defined for DHCP, and adds a hierarchy to address complex
46 road identity schemes. The format also includes support for the
47 xml:lang language tag and restricts the types of elements where
48 appropriate.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5
55 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5
56 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 7
57 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 8
58 3.2.2. Directionals and other Qualifiers . . . . . . . . . . 8
59 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 9
60 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 9
61 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 9
62 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 10
63 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 11
64 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
67 7.1. URN sub-namespace registration for
68 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 15
69 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15
70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
72 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
75 Intellectual Property and Copyright Statements . . . . . . . . . . 20
77 1. Introduction
79 Since the publication of the original PIDF-LO civic specification, in
80 [I-D.ietf-geopriv-pidf-lo], it has been found that the specification
81 is lacking a number of additional parameters that can be used to more
82 precisely specify a civic location. These additional parameters have
83 been largely captured in [I-D.ietf-geopriv-dhcp-civil].
85 This document revises the GEOPRIV civic form to include the
86 additional civic parameters captured in [I-D.ietf-geopriv-dhcp-
87 civil]. The document also introduces a hierarchical structure for
88 thoroughfare (road) identification which is employed in some
89 countries. New elements are defined to allow for even more precision
90 in specifying a civic location.
92 2. Terminology
94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
96 document are to be interpreted as described in [RFC2119].
98 The term "thoroughfare" is used in this document to describe a road
99 or part of a road or other access route along which a final point is
100 identified. This is consistent with the definition used in [UPU-
101 S42].
103 3. Changes from PIDF-LO
105 3.1. Additional Civic Address Types
107 [I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that
108 may used to describe a civic location. Specifically [I-D.ietf-
109 geopriv-dhcp-civil] lists several civic address types (CAtypes) that
110 require support in the formal PIDF-LO definition that are not in
111 [I-D.ietf-geopriv-pidf-lo].
113 These changes include and new elements that are required to support
114 more complex structures for naming street addresses, this is
115 described in more detail in Section 3.2.
117 +--------------+--------+-----------------------------+-------------+
118 | New Civic | CAtype | Description | Example |
119 | Field | | | |
120 +--------------+--------+-----------------------------+-------------+
121 | BLD | 24 | Building (structure) | Hope |
122 | | | | Theatre |
123 | | | | |
124 | UNIT | 26 | Unit (apartment, suite) | 12a |
125 | | | | |
126 | ROOM | 28 | Room | 450F |
127 | | | | |
128 | PLC | 29 | Place-type | office |
129 | | | | |
130 | POBOX | 31 | Post office box (P.O. box) | U40 |
131 | | | | |
132 | ADDCODE | 32 | Additional Code | 13203000003 |
133 | | | | |
134 | SEAT | 33 | Seat (desk, cubicle, | WS 181 |
135 | | | workstation) | |
136 | | | | |
137 | RD | 34 | Primary road or street | Broadway |
138 | | | | |
139 | RDSEC | 35 | Road section | 14 |
140 | | | | |
141 | RDBR | 36 | Road branch | Lane 7 |
142 | | | | |
143 | RDSUBBR | 37 | Road sub-branch | Alley 8 |
144 | | | | |
145 | PRM | 38 | Road pre-modifier | Old |
146 | | | | |
147 | POM | 39 | Road post-modifier | Extended |
148 +--------------+--------+-----------------------------+-------------+
150 Table 1: New Civic PIDF-LO Types
152 Building: The "building" (BLD) conveys the name of a single building
153 if the street address includes more than one building or the
154 building name is helpful in identifying the location. (For
155 example, on university campuses, the house number is often not
156 displayed on buildings, while the building name is prominently
157 shown.)
159 Unit: The "unit" (UNIT) contains the name or number of a part of a
160 structure where there are separate administrative units, owners or
161 tenants, such as separate companies or families who occupy that
162 structure. Common examples include suite or apartment
163 designations.
165 Room: A "room" (ROOM) is the smallest identifiable subdivision of a
166 structure.
168 Place type: The "type of place" element (PLC) describes the type of
169 place described by the civic coordinates. For example, it
170 describes whether it is a home, office, street or other public
171 space. The values are drawn from the items in the location types
172 registry [I-D.ietf-geopriv-location-types-registry]. This
173 information makes it easy, for example, for the DHCP client to
174 then populate the presence information.
176 Post office box: The "post office box" element (POBOX) describes a
177 container, such as a pigeon hole, at a central mailing location,
178 where mail is held.
180 Additional code: The "additional code" item (ADDCODE) provides an
181 additional, country-specific code identifying the location. For
182 example, for Japan, it contains the Japan Industry Standard (JIS)
183 address code. The JIS address code provides a unique address
184 inside of Japan, down to the level of indicating the floor of the
185 building.
187 Seat: The "seat" element (SEAT) describes a single place where a
188 person might sit. Common examples include a seat in a theatre and
189 a cubicle in a cube farm.
191 Primary Road Name: The "primary road name" item (RD) is the name
192 given to the root road or street associated with the address. In
193 many cases this will the name of the road or street on which an
194 office or house exists, in some cases it will be the name of road
195 or street from which more granular information stems. In most
196 countries, this field should be used in preference to the "A6"
197 element, which was previously used for street information.
199 Road Section: The "road section" item (RDSEC) is an identifier that
200 represents a specific section or stretch of a primary road. This
201 is a new thoroughfare element and is useful where a primary road
202 reuses street numbering, or branch street names and there is no
203 other way to identify that this has occurred, such as a change in
204 municipality or suburb.
206 Branch Road Name: The "branch road name" item (RDBR) represents the
207 name or identifier of a road/street that intersects or is
208 associated with a primary road. The road branch is a new
209 thoroughfare element and is envisaged being used where branch
210 roads along a primary road reuse names and there is no other way,
211 other than the road section (RDSEC) identifier, to discern a
212 difference between them, such as a change in municipality or
213 suburb.
215 Sub-Branch Road Name: The "sub-branch road name" item (RDSUBBR)
216 represents the name or identifier of a road/street that intersects
217 or is associated with a branch road (RDBR). The road sub-branch
218 is a new thoroughfare element and is envisaged being used where
219 sub-branch roads reuse names and there is no way, other than the
220 road section (RDSEC) identifier, to discern a difference between
221 them, such as a change in municipality or suburb.
223 Road Pre-Modifier: The "road pre-modifier" item (PRM) is an optional
224 element of the complete street name. It is a word or phrase that
225 precedes all other elements of the street name and modifies it,
226 but is separated from the street name by a street name pre-
227 directional. An example is "Old" in "Old North First Street".
229 Road Post-Modifier: The "road post-modifier" item (POM) is an
230 optional element of the complete street name. It is a word or
231 phrase that follows all other elements of the street name and
232 modifies it, but is separated from the street name by a street
233 name post-directional and/or street suffix. An example is
234 "Extended" in "East End Avenue Extended".
236 3.2. New Thoroughfare Elements
238 In some countries a thoroughfare can be broken up into sections, and
239 it is not uncommon for street numbers to be repeated between
240 sections. A road section identifier is required to ensure that an
241 address is unique. For example, "West Alice Parade" has 5 sections,
242 each numbered from 1; unless the section is specified "7 West Alice
243 Parade" could exist in 5 different places. The "RDSEC" element is
244 used to specify the section.
246 Minor streets can share the same name, so that they can only be
247 distinguished by the major thoroughfare with which they intersect.
248 For example, both "West Alice Parade, Section 3" and "Bob Street"
249 could both be interested by a "Carol Lane". The "RDBR" element is
250 used to specify a road branch where the name of the branch does not
251 uniquely identify the road. Road branches MAY also be used where a
252 major thoroughfare is split into sections.
254 Similar to the way that a road branch is associated with a road, a
255 road sub-branch is associated with a road branch. The "RDSUBBR"
256 element is used to identify road sub-branches.
258 The "A6" element is retained for use in those countries that require
259 this level of detail. Where "A6" was previously used for street
260 names, it MUST NOT be used, the "RD" element MUST be used for
261 thoroughfare data.
263 The following example figure shows a fictional arrangement of roads
264 where these new thoroughfare elements are applicable.
266 | ||
267 | ---------------||
268 | Carol La. Carol La. || Bob
269 | || St.
270 | West Alice Pde. ||
271 ==========/=================/===============/==========||===========
272 Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5
273 | ||
274 ----------| Carol ||
275 Alley 2 | La. ||
276 | ||
278 3.2.1. Street Numbering
280 The introduction of new thoroughfare elements affects the
281 interpretation of several of more specific civic address data. In
282 particular, street numbering (the "HNO" element) applies to the most
283 specific road element specified. That is, the first specified
284 element from: "RDSUBBR", "RDBR", "RDSEC", or "RD".
286 3.2.2. Directionals and other Qualifiers
288 The "PRM", "POM", "PRD", "POD" and "STS" elements always apply to the
289 value of the "RD" element only. If road branches or sub-branches
290 require street suffixes or qualifiers, they MUST be included in the
291 "RDBR" or "RDSUBBR" element text.
293 3.3. Country Element
295 The "country" element differs from that defined in [I-D.ietf-geopriv-
296 pidf-lo] in that it now restricts the value space of the element to
297 two upper case characters, which correspond to the alpha-2 codes in
298 [ISO.3166-1].
300 3.4. A1 Element
302 The "A1" element is used for the top level subdivision within a
303 country. In the absence of a country-specific guide on how to use
304 the A-series of elements, the second part of the ISO 3166-2 code
305 [ISO.3166-2] for a country subdivision SHOULD be used. The ISO
306 3166-2 code is a formed of a country code and hyphen plus a code of
307 one, two or three characters or numerals. For the "A1" element, the
308 leading country code and hyphen are omitted and only the subdivision
309 code is included.
311 For example, the codes for Canada include CA-BC, CA-ON, CA-QC;
312 Luxembourg has just three single character codes: LU-D, LU-G and
313 LU-L; Australia uses both two and three character codes: AU-ACT, AU-
314 NSW, AU-NT; France uses numerical codes for mainland France and
315 letters for territories: FR-75, FR-NC. This results in the following
316 fragments:
318
See RFCXXXX.
490 491 492 END 494 7.2. XML Schema Registration 496 This section registers an XML schema as per the procedures in 497 [RFC3688]. 499 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 501 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 502 Martin Thomson (martin.thomson@andrew.com). 504 The XML for this schema can be found as the entirety of Section 4 505 of this document. 507 8. References 509 8.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [W3C.REC-xmlschema-2-20041028] 515 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 516 Second Edition", W3C REC REC-xmlschema-2-20041028, 517 October 2004. 519 [I-D.ietf-geopriv-dhcp-civil] 520 Schulzrinne, H., "Dynamic Host Configuration Protocol 521 (DHCPv4 and DHCPv6) Option for Civic Addresses 522 Configuration Information", 523 draft-ietf-geopriv-dhcp-civil-09 (work in progress), 524 January 2006. 526 [I-D.ietf-geopriv-location-types-registry] 527 Schulzrinne, H. and H. Tschofenig, "Location Types 528 Registry", draft-ietf-geopriv-location-types-registry-05 529 (work in progress), March 2006. 531 [ISO.3166-1] 532 International Organization for Standardization, "Codes for 533 the representation of names of countries and their 534 subdivisions - Part 1: Country codes", ISO Standard 3166- 535 1:1997, 1997, 536