idnits 2.17.1
draft-ietf-geopriv-revised-civic-lo-06.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 16.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 561.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 572.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 579.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 585.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC4119, but the
abstract doesn't seem to directly say this. It does mention RFC4119
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'MUST not' in this paragraph:
The "A6" element is retained for use in those countries that
require this level of detail. Where "A6" was previously used for street
names in [RFC4119], it MUST NOT be used, the "RD" element MUST be used
for thoroughfare data. However, without additional information these
fields MUST not be interchanged when converting between different civic
formats. Where civic address information is obtained from another
format, such as the DHCP form [RFC4776], the "A6" element MUST be copied
directly from the source format.
(Using the creation date from RFC4119, updated by this document, for
RFC5378 checks: 2004-01-14)
-- 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 (October 17, 2007) is 6036 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 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 Updates: 4119 (if approved) Andrew
5 Intended status: Standards Track October 17, 2007
6 Expires: April 19, 2008
8 Revised Civic Location Format for PIDF-LO
9 draft-ietf-geopriv-revised-civic-lo-06.txt
11 Status of this Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on April 19, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2007).
40 Abstract
42 This document defines an XML format for the representation of civic
43 location. This format is designed for use with PIDF Location Object
44 (PIDF-LO) documents and replaces the civic location format in RFC
45 4119. The format is based on the civic address definition in
46 PIDF-LO, but adds several new elements based on the civic types
47 defined for DHCP, and adds a hierarchy to address complex road
48 identity schemes. The format also includes support for the xml:lang
49 language tag and restricts the types of elements where appropriate.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
55 3. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 5
56 3.1. Additional Civic Address Types . . . . . . . . . . . . . . 5
57 3.2. New Thoroughfare Elements . . . . . . . . . . . . . . . . 6
58 3.2.1. Street Numbering . . . . . . . . . . . . . . . . . . . 7
59 3.2.2. Directionals and other Qualifiers . . . . . . . . . . 7
60 3.3. Country Element . . . . . . . . . . . . . . . . . . . . . 7
61 3.4. A1 Element . . . . . . . . . . . . . . . . . . . . . . . . 7
62 3.5. Languages and Scripts . . . . . . . . . . . . . . . . . . 8
63 3.5.1. Converting from the DHCP Format . . . . . . . . . . . 8
64 3.5.2. Combining Multiple Elements Based on Language
65 Preferences . . . . . . . . . . . . . . . . . . . . . 8
66 3.6. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 9
67 4. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 10
68 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
71 7.1. URN sub-namespace registration for
72 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 14
73 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 14
74 7.3. CAtype Registry Update . . . . . . . . . . . . . . . . . . 15
75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
77 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
80 Intellectual Property and Copyright Statements . . . . . . . . . . 19
82 1. Introduction
84 Since the publication of the original PIDF-LO civic specification, in
85 [RFC4119], it has been found that the specification is lacking a
86 number of additional parameters that can be used to more precisely
87 specify a civic location. These additional parameters have been
88 largely captured in [RFC4776].
90 This document revises the GEOPRIV civic form to include the
91 additional civic parameters captured in [RFC4776]. The document also
92 introduces a hierarchical structure for thoroughfare (road)
93 identification which is employed in some countries. New elements are
94 defined to allow for even more precision in specifying a civic
95 location.
97 2. Terminology
99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
101 document are to be interpreted as described in [RFC2119].
103 The term "thoroughfare" is used in this document to describe a road
104 or part of a road or other access route along which a final point is
105 identified. This is consistent with the definition used in
106 [UPU-S42].
108 3. Changes from PIDF-LO
110 3.1. Additional Civic Address Types
112 [RFC4776] provides a full set of parameters that may be used to
113 describe a civic location. Specifically [RFC4776] lists several
114 civic address types (CAtypes) that require support in the formal
115 PIDF-LO definition that are not in [RFC4119].
117 These changes include and new elements that are required to support
118 more complex structures for naming street addresses, this is
119 described in more detail in Section 3.2.
121 +-----------+--------+-------------------------------+--------------+
122 | New Field | CAtype | Description | Example |
123 +-----------+--------+-------------------------------+--------------+
124 | BLD | 25 | Building (structure) | Hope Theatre |
125 | | | | |
126 | UNIT | 26 | Unit (apartment, suite) | 12a |
127 | | | | |
128 | ROOM | 28 | Room | 450F |
129 | | | | |
130 | PLC | 29 | Place-type | office |
131 | | | | |
132 | PCN | 30 | Postal community name | Leonia |
133 | | | | |
134 | POBOX | 31 | Post office box (P.O. box) | U40 |
135 | | | | |
136 | ADDCODE | 32 | Additional Code | 13203000003 |
137 | | | | |
138 | SEAT | 33 | Seat (desk, cubicle, | WS 181 |
139 | | | workstation) | |
140 | | | | |
141 | RD | 34 | Primary road or street | Broadway |
142 | | | | |
143 | RDSEC | 35 | Road section | 14 |
144 | | | | |
145 | RDBR | 36 | Road branch | Lane 7 |
146 | | | | |
147 | RDSUBBR | 37 | Road sub-branch | Alley 8 |
148 | | | | |
149 | PRM | 38 | Road pre-modifier | Old |
150 | | | | |
151 | POM | 39 | Road post-modifier | Extended |
152 +-----------+--------+-------------------------------+--------------+
154 Table 1: New Civic PIDF-LO Types
156 A complete description of these types is included in [RFC4776].
158 3.2. New Thoroughfare Elements
160 In some countries a thoroughfare can be broken up into sections, and
161 it is not uncommon for street numbers to be repeated between
162 sections. A road section identifier is required to ensure that an
163 address is unique. For example, "West Alice Parade" has 5 sections,
164 each numbered from 1; unless the section is specified "7 West Alice
165 Parade" could exist in 5 different places. The "RDSEC" element is
166 used to specify the section.
168 Minor streets can share the same name, so that they can only be
169 distinguished by the major thoroughfare with which they intersect.
170 For example, both "West Alice Parade, Section 3" and "Bob Street"
171 could both be interested by a "Carol Lane". The "RDBR" element is
172 used to specify a road branch where the name of the branch does not
173 uniquely identify the road. Road branches MAY also be used where a
174 major thoroughfare is split into sections.
176 Similar to the way that a road branch is associated with a road, a
177 road sub-branch is associated with a road branch. The "RDSUBBR"
178 element is used to identify road sub-branches.
180 The "A6" element is retained for use in those countries that require
181 this level of detail. Where "A6" was previously used for street
182 names in [RFC4119], it MUST NOT be used, the "RD" element MUST be
183 used for thoroughfare data. However, without additional information
184 these fields MUST not be interchanged when converting between
185 different civic formats. Where civic address information is obtained
186 from another format, such as the DHCP form [RFC4776], the "A6"
187 element MUST be copied directly from the source format.
189 The following example figure shows a fictional arrangement of roads
190 where these new thoroughfare elements are applicable.
192 | ||
193 | ---------------||
194 | Carol La. Carol La. || Bob
195 | || St.
196 | West Alice Pde. ||
197 ==========/=================/===============/==========||===========
198 Sec.1 Sec.2 Sec.3 | Sec.4 || Sec.5
199 | ||
200 ----------| Carol ||
201 Alley 2 | La. ||
202 | ||
204 3.2.1. Street Numbering
206 The introduction of new thoroughfare elements affects the
207 interpretation of several of more specific civic address data. In
208 particular, street numbering (the "HNO" element) applies to the most
209 specific road element specified. That is, the first specified
210 element from: "RDSUBBR", "RDBR", "RDSEC", or "RD".
212 3.2.2. Directionals and other Qualifiers
214 The "PRM", "POM", "PRD", "POD" and "STS" elements always apply to the
215 value of the "RD" element only. If road branches or sub-branches
216 require street suffixes or qualifiers, they MUST be included in the
217 "RDBR" or "RDSUBBR" element text.
219 3.3. Country Element
221 The "country" element differs from that defined in [RFC4119] in that
222 it now restricts the value space of the element to two upper case
223 characters, which correspond to the alpha-2 codes in [ISO.3166-1].
225 3.4. A1 Element
227 The "A1" element is used for the top level subdivision within a
228 country. In the absence of a country-specific guide on how to use
229 the A-series of elements, the second part of the ISO 3166-2 code
230 [ISO.3166-2] for a country subdivision SHOULD be used. The ISO
231 3166-2 code is a formed of a country code and hyphen plus a code of
232 one, two or three characters or numerals. For the "A1" element, the
233 leading country code and hyphen are omitted and only the subdivision
234 code is included.
236 For example, the codes for Canada include CA-BC, CA-ON, CA-QC;
237 Luxembourg has just three single character codes: LU-D, LU-G and
238 LU-L; Australia uses both two and three character codes: AU-ACT, AU-
239 NSW, AU-NT; France uses numerical codes for mainland France and
240 letters for territories: FR-75, FR-NC. This results in the following
241 fragments:
243
See RFCXXXX.
450 451 452 END 454 7.2. XML Schema Registration 456 This section registers an XML schema as per the procedures in 457 [RFC3688]. 459 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr 461 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 462 Martin Thomson (martin.thomson@andrew.com). 464 The XML for this schema can be found as the entirety of Section 4 465 of this document. 467 7.3. CAtype Registry Update 469 This document updates the civic address type registry established by 470 [RFC4776]. The "PIDF" column of the CAtypes table has been updated 471 to include the types shown in the first column of Table 1. 473 8. References 475 8.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, March 1997. 480 [W3C.REC-xmlschema-2-20041028] 481 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 482 Second Edition", World Wide Web Consortium 483 Recommendation REC-xmlschema-2-20041028, October 2004, 484