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