idnits 2.17.00 (12 Aug 2021)
/tmp/idnits40202/draft-rosen-geopriv-pidf-interior-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
https://trustee.ietf.org/license-info/)
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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 5, 2010) is 4453 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 (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 geopriv B. Rosen
3 Internet-Draft NeuStar
4 Intended status: Standards Track March 5, 2010
5 Expires: September 6, 2010
7 Interior Location in the Presence Information Data Format - Location
8 Object
9 draft-rosen-geopriv-pidf-interior-01
11 Abstract
13 RFC5139 defines explicit tags for interior building location such as
14 "BLD" (building), "UNIT", "ROOM". There is wide variation in how
15 interior spaces are named, and the rigid element names provided do
16 not allow accurate representation of interior spaces that don't use
17 the element tags defined. This memo provides an alternative
18 mechanism that provides an extensible flexible way to name spaces in
19 any kind of addressable location.
21 Status of this Memo
23 This Internet-Draft is submitted to IETF in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that
28 other groups may also distribute working documents as Internet-
29 Drafts.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 The list of current Internet-Drafts can be accessed at
37 http://www.ietf.org/ietf/1id-abstracts.txt.
39 The list of Internet-Draft Shadow Directories can be accessed at
40 http://www.ietf.org/shadow.html.
42 This Internet-Draft will expire on September 6, 2010.
44 Copyright Notice
46 Copyright (c) 2010 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the BSD License.
59 Table of Contents
61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 3. INT element . . . . . . . . . . . . . . . . . . . . . . . . . . 3
64 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 5. Civic Address Schema . . . . . . . . . . . . . . . . . . . . . 4
66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
68 7.1. XML Schema Registration . . . . . . . . . . . . . . . . . . 7
69 7.2. CAtype Registry Update . . . . . . . . . . . . . . . . . . 7
70 7.3. INT Name Registry . . . . . . . . . . . . . . . . . . . . . 7
71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
74 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 1. Terminology
79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
81 document are to be interpreted as described in [RFC2119].
83 2. Introduction
85 [RFC4119] provides a way to specify an addressable civic location,
86 naming the country, region, city, street name, etc. Within that
87 document is an element FLR (floor) which specifies location within
88 the addressable location. [RFC5139] extends the ability to locate
89 interior spaces by defining BLD (Building), UNIT, ROOM, and SEAT.
90 The problem with these elements is that there is very wide variation
91 in how interior spaces are named, and these fixed elements don't
92 allow one to specify interior location that matches signage, drawings
93 or other conventions that are needed to properly locate targets
94 within an addressable location. An example of where the BLD/FLR/
95 UNIT/ROOM doesn't work is an airport. Interior location may be given
96 as Terminal 2, Concourse A, Gate 27.
98 Additionally, since interior location may vary within a structure
99 (Terminal 2, Food Court, Store 13), and every building could have
100 different conventions, it is essential that a way to parse a sign,
101 drawing, or other representation of interior space to the elements
102 needed to specify that space in a PIDF, or the reverse: creating a
103 human readable string from a PIDF matching signage or drawings, it
104 must be possible to specify how the conversion from human readable to
105 PIDF and vice versa can be accomplished.
107 3. INT element
109 This memo introduces a new CAtype for PIDF-LO called "INT" (for
110 interior) which has two new attributes:
111 N The locally significant name of a "level" of interior space.
112 Examples include "Floor", "Concourse" and "Suite".
113 R An enumeration of how the name and value are represented in a
114 human readable form.
116 A PIDF-LO may have multiple INT elements. If there are more than
117 one, the order in which they appear in the PIDF can be significant.
119 The R attribute has the following values:
121 B The name is expressed before the value as in "Concourse A".
122 A The name is expressed after the value as in "Presidential
123 Suite".
125 If the R subelement is not present, the default value "B" is assumed.
127 An IANA registry of N values is established by this document. As the
128 names are only required to be locally significant, adding new values
129 to the registry should be simple.
131 While the existing BLD/FLR/UNIT/ROOM/SEAT elements are not deprecated
132 by this document, their use should be restricted to existing
133 implementations. New implementations SHOULD use INT. As always,
134 recipients of PIDF-LO should be liberal in what they accept, which
135 would mean both INT and BLD/FLR/UNIT/ROOM/SEAT.
137 4. Examples
139
141 AU
142 NSW
143 Wollongong
144 North Wollongong
145 FlindersStreet
146 Video Rental Store
147 2500
148 Westerns and Classics
149
151
153 US
154 PA
155 Findlay
156 AirportRD
157 1
158 A
159 37
160
162 5. Civic Address Schema
164
165
172
175
176
177
178
179
181
182
183
184
185
186
187
189
190
191
192
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
240
241
242
243
245 6. Security Considerations
247 The XML representation described in this document is designed for
248 inclusion in a PIDF-LO document. As such, it is subject to the same
249 security considerations as are described in [RFC4119].
250 Considerations relating to the inclusion of this representation in
251 other XML documents are outside the scope of this document.
253 This extension may make it possible to more precisely locate a
254 target, and thus raise more privacy concerns. However, since
255 [RFC5139] already can locate to a seat in a room, this concern does
256 not seem to be significant.
258 7. IANA Considerations
259 7.1. XML Schema Registration
261 This section registers an XML schema as per the procedures in
262 [RFC3688].
264 URI: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr
266 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
267 Brian Rosen (brian.rosen@neustar.biz).
269 The XML for this schema can be found as the entirety of Section 5.
270 of this document.
272 7.2. CAtype Registry Update
274 This document updates the civic address type registry established by
275 [RFC4776]. One additional value is added:
277 40 INT Interior Location
279 7.3. INT Name Registry
281 This document creates a new registry managed by IANA for the values
282 that may appear in an "N" attribute in an INT element.
284 The name of this registry is "INT Names"
286 Each entry in the registry includes the Name which can appear in the
287 N attribute (a text string).
289 The policy for this registry is "first come, first served"
291 The initial values for this registry are "Building", "Floor",
292 "Suite", "Room", "Seat", "Terminal", "Concourse" and "Gate".
294 8. Acknowledgements
296 The authors would like to acknowledge James Polk and Marc Linsner for
297 their contributions to this document.
299 9. References
301 9.1. Normative References
303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
304 Requirement Levels", BCP 14, RFC 2119, March 1997.
306 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
307 Format", RFC 4119, December 2005.
309 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location
310 Format for Presence Information Data Format Location
311 Object (PIDF-LO)", RFC 5139, February 2008.
313 9.2. Informative References
315 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
316 January 2004.
318 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
319 (DHCPv4 and DHCPv6) Option for Civic Addresses
320 Configuration Information", RFC 4776, November 2006.
322 Author's Address
324 Brian Rosen
325 NeuStar, Inc.
326 470 Conrad Dr
327 Mars, PA 16046
328 US
330 Email: br@brianrosen.net