idnits 2.17.1
draft-thomson-revised-civic-lo-01.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 411.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 388.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 395.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 401.
** 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 :
----------------------------------------------------------------------------
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 172: '... It is RECOMMENDED that each "civicA...'
RFC 2119 keyword, line 175: '...ddress" elements SHOULD be included in...'
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 (October 3, 2005) is 6772 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)
-- Looks like a reference, but probably isn't: '17' on line 142
== Outdated reference: A later version (-09) exists of
draft-ietf-geopriv-dhcp-civil-07
Summary: 4 errors (**), 0 flaws (~~), 3 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 Expires: April 6, 2006 Andrew
5 October 3, 2005
7 Revised Civic Location Format for PIDF-LO
8 draft-thomson-revised-civic-lo-01.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 April 6, 2006.
35 Copyright Notice
37 Copyright (C) The Internet Society (2005).
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. The format also includes support for
46 the xml:lang language tag and restricts the types of elements where
47 appropriate.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 2. Changes from PIDF-LO . . . . . . . . . . . . . . . . . . . . . 4
53 2.1. Additional Civic Address Types . . . . . . . . . . . . . . 4
54 2.2. Country Element . . . . . . . . . . . . . . . . . . . . . 5
55 2.3. Languages and Scripts . . . . . . . . . . . . . . . . . . 5
56 2.4. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6
57 3. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 7
58 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
61 6.1. URN sub-namespace registration for
62 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr' . . . . 11
63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
65 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
68 Intellectual Property and Copyright Statements . . . . . . . . . . 15
70 1. Introduction
72 Since the publication of the original PIDF-LO civic specification, in
73 [I-D.ietf-geopriv-pidf-lo], it has been found that the specification
74 is lacking a number of additional parameters that can be used to more
75 precisely specify a civic location. These additional parameters have
76 been suitably captured in [I-D.ietf-geopriv-dhcp-civil].
78 This document revises the GEOPRIV civic form to include the
79 additional civic parameters captured in [I-D.ietf-geopriv-dhcp-
80 civil]. New elements are also defined to allow for even more
81 precision in specifying location information.
83 2. Changes from PIDF-LO
85 2.1. Additional Civic Address Types
87 [I-D.ietf-geopriv-dhcp-civil] provides a full set of parameters that
88 may used to describe a civic location. Specifically [I-D.ietf-
89 geopriv-dhcp-civil] lists 6 civic address types (CAtypes) that
90 require support in the formal PIDF-LO definition that are not in
91 [I-D.ietf-geopriv-pidf-lo]. Two additional types are also added that
92 enable a more complete specification of location. These are listed
93 in the table below for completeness.
95 +--------------+--------+-----------------------------+-------------+
96 | New Civic | CAtype | Description | Example |
97 | Field | | | |
98 +--------------+--------+-----------------------------+-------------+
99 | BLD | 24 | Building (structure) | Hope |
100 | | | | Theatre |
101 | | | | |
102 | UNIT | 26 | Unit (apartment, suite) | 12a |
103 | | | | |
104 | ROOM | 28 | Room | 450F |
105 | | | | |
106 | SEAT | 33 | Seat (desk, cubicle, | WS 181 |
107 | | | workstation) | |
108 | | | | |
109 | PLC | 29 | Placetype | office |
110 | | | | |
111 | POBOX | 31 | Post office box (P.O. box) | U40 |
112 | | | | |
113 | ADDCODE | 32 | Additional Code | 13203000003 |
114 +--------------+--------+-----------------------------+-------------+
116 Table 1: New Civic PIDF-LO Types
118 Building: The "building" (BLD) conveys the name of a single building
119 if the street address includes more than one building or the
120 building name is helpful in identifying the location. (For
121 example, on university campuses, the house number is often not
122 displayed on buildings, while the building name is prominently
123 shown.)
125 Unit: The "unit" (UNIT) contains the name or number of a part of a
126 structure where there are separate administrative units, owners or
127 tenants, such as separate companies or families who occupy that
128 structure. Common examples include suite or apartment
129 designations.
131 Room: A "room" (ROOM) is the smallest identifiable subdivision of a
132 structure.
134 Seat: The "seat" element (SEAT) describes a single place where a
135 person might sit. Common examples include a seat in a theatre and
136 a cubicle in a cube farm.
138 Place type: The "type of place" element (PLC) describes the type of
139 place described by the civic coordinates. For example, it
140 describes whether it is a home, office, street or other public
141 space. The values are drawn from the items in the rich presence
142 [17] document. This information makes it easy, for example, for
143 the DHCP client to then populate the presence information.
145 Post office box: The "post office box" element (POBOX) describes a
146 container, such as a pigeon hole, at a central mailing location,
147 where mail is held.
149 Additional code: The "additional code" item (ADDCODE) provides an
150 additional, country-specific code identifying the location. For
151 example, for Japan, it contains the Japan Industry Standard (JIS)
152 address code. The JIS address code provides a unique address
153 inside of Japan, down to the level of indicating the floor of the
154 building.
156 2.2. Country Element
158 The "country" element differs from that defined in [I-D.ietf-geopriv-
159 pidf-lo] in that it now restricts the value space of the element to
160 two upper case characters, which more closely matches the definition
161 in [ISO.3166.1988].
163 2.3. Languages and Scripts
165 The XML schema defined for civic addresses allows for the addition of
166 the "xml:lang" attribute to all elements except "country" and "PLC",
167 which both contain enumerated values.
169 The "script" field defined in [I-D.ietf-geopriv-dhcp-civil] is
170 omitted in favour of using the "xml:lang" attribute.
172 It is RECOMMENDED that each "civicAddress" element use one language
173 only, or a combination of languages that is consistent. Where a
174 civic location is represented in multiple languages multiple
175 "civicAddress" elements SHOULD be included in the PIDF-LO document.
177 2.4. Whitespace
179 The XML schema [W3C.REC-xmlschema-2-20041028] defined in Section 3
180 uses a base type of "token" instead of "string" as used in [I-D.ietf-
181 geopriv-pidf-lo].
183 The "token" type ensures that whitespace within instance documents is
184 normalized and collapsed before being passed to a processor. This
185 ensures that the following fragments are considered equivalent by XML
186 processors:
188 New South Wales
190 New
191 South Wales
193
194 New South
195 Wales
197 Whitespace may still be included in values by using a character
198 reference, such as " ".
200 3. Civic Address Schema
202
203
210
213
214
215
216
217
219
220
221
222
223
224
225
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
256
257
258
259
261 4. Example
263
264
266 DE
267 Bayern Oberbayern
268
269 München
270
271 Marienplatz 8
272 Rathaus
273 80331
274 public
275 Postfach 1000
276
278 5. Security Considerations
280 The XML representation described in this document is designed for
281 inclusion in a PIDF-LO document. As such, it is subject to the same
282 security considerations as are described in
283 [I-D.ietf-geopriv-pidf-lo]. Considerations relating to the inclusion
284 of this representation in other XML documents are outside the scope
285 of this document.
287 6. IANA Considerations
289 This document calls for IANA to register a new XML namespace, as per
290 the guidelines in [RFC3688].
292 6.1. URN sub-namespace registration for
293 'urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr'
295 URI
296 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
298 Registrant Contact
299 IETF, GEOPRIV working group
300 Martin Thomson
302 XML
303 BEGIN
304
305
307
308
309 GEOPRIV Civic Address
310
311
312 Format for Distributing Civic Address in GEOPRIV
313 urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr
314 See RFCXXXX.
315
316
317 END
319 7. References
321 7.1. Normative References
323 [W3C.REC-xmlschema-2-20041028]
324 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
325 Second Edition", W3C REC REC-xmlschema-2-20041028,
326 October 2004.
328 [I-D.ietf-geopriv-dhcp-civil]
329 Schulzrinne, H., "Dynamic Host Configuration Protocol
330 (DHCPv4 and DHCPv6) Option for Civic Addresses
331 Configuration Information",
332 draft-ietf-geopriv-dhcp-civil-07 (work in progress),
333 September 2005.
335 [ISO.3166.1988]
336 International Organization for Standardization, "Codes for
337 the representation of names of countries, 3rd edition",
338 ISO Standard 3166, August 1988.
340 7.2. Informative References
342 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
343 January 2004.
345 [I-D.ietf-geopriv-pidf-lo]
346 Peterson, J., "A Presence-based GEOPRIV Location Object
347 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
348 September 2004.
350 Appendix A. Acknowledgements
352 The authors would like to thank Henning Schulzrinne for his research
353 and work on defining the additional civic address types. In addition
354 we would like to thank Jon Peterson for his work in defining the
355 PIDF-LO.
357 Authors' Addresses
359 Martin Thomson
360 Andrew
361 PO Box U40
362 Wollongong University Campus, NSW 2500
363 AU
365 Phone: +61 2 4221 2915
366 Email: martin.thomson@andrew.com
367 URI: http://www.andrew.com/
369 James Winterbottom
370 Andrew
371 PO Box U40
372 Wollongong University Campus, NSW 2500
373 AU
375 Phone: +61 2 4221 2938
376 Email: james.winterbottom@andrew.com
377 URI: http://www.andrew.com/
379 Intellectual Property Statement
381 The IETF takes no position regarding the validity or scope of any
382 Intellectual Property Rights or other rights that might be claimed to
383 pertain to the implementation or use of the technology described in
384 this document or the extent to which any license under such rights
385 might or might not be available; nor does it represent that it has
386 made any independent effort to identify any such rights. Information
387 on the procedures with respect to rights in RFC documents can be
388 found in BCP 78 and BCP 79.
390 Copies of IPR disclosures made to the IETF Secretariat and any
391 assurances of licenses to be made available, or the result of an
392 attempt made to obtain a general license or permission for the use of
393 such proprietary rights by implementers or users of this
394 specification can be obtained from the IETF on-line IPR repository at
395 http://www.ietf.org/ipr.
397 The IETF invites any interested party to bring to its attention any
398 copyrights, patents or patent applications, or other proprietary
399 rights that may cover technology that may be required to implement
400 this standard. Please address the information to the IETF at
401 ietf-ipr@ietf.org.
403 Disclaimer of Validity
405 This document and the information contained herein are provided on an
406 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
407 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
408 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
409 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
410 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
411 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
413 Copyright Statement
415 Copyright (C) The Internet Society (2005). This document is subject
416 to the rights, licenses and restrictions contained in BCP 78, and
417 except as set forth therein, the authors retain all their rights.
419 Acknowledgment
421 Funding for the RFC Editor function is currently provided by the
422 Internet Society.