idnits 2.17.1 draft-jones-geopriv-sigpos-survey-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 24 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 09, 2013) is 4002 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) == Unused Reference: 'RFC2617' is defined on line 2365, but no explicit reference was found in the text == Unused Reference: 'RFC4122' is defined on line 2379, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-held-measurements-07 == Outdated reference: A later version (-08) exists of draft-ietf-geopriv-relative-location-04 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geographic Location/Privacy K. Jones 3 Internet-Draft C. Steger 4 Intended status: Standards Track Skyhook Wireless 5 Expires: November 10, 2013 May 09, 2013 7 Indoor Signal Position Conveyance 8 draft-jones-geopriv-sigpos-survey-02 10 Abstract 12 Location Information Servers rely on signal surveys to create a 13 signal map allowing for subsequent device location determination. 14 This document describes a method by which a Survey Device is able to 15 provide indoor location related measurement data to a LIS for 16 positioning purposes. Location related measurement information 17 comprises observations concerning properties related to the position 18 of a Survey Device and the radio, electromagnetic, and other 19 observable environmental measures as perceived by the Survey Device. 20 These measurements could be data about Wi-Fi signals, Bluetooth 21 signals, barometric pressure, or any other environmental measurement 22 which could sent to a LIS for subsequent processing to help determine 23 the location of devices that later enter the venue. A basic set of 24 location-related measurements, data rights disclosure and location 25 types are defined. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 10, 2013. 44 Copyright Notice 46 Copyright (c) 2013 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 Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Using PIDF-LO Location . . . . . . . . . . . . . . . . . . . 9 67 5.1. Device Orientation . . . . . . . . . . . . . . . . . . . 10 68 6. Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1.1. Venue Name/Address . . . . . . . . . . . . . . . . . 13 71 6.1.2. Licensor . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1.3. Data Rights Management . . . . . . . . . . . . . . . 14 73 6.1.3.1. License Expiry . . . . . . . . . . . . . . . . . 15 74 6.1.3.2. License URI . . . . . . . . . . . . . . . . . . . 15 75 6.1.3.3. License Type . . . . . . . . . . . . . . . . . . 15 76 6.1.4. Map Metadata . . . . . . . . . . . . . . . . . . . . 17 77 6.2. Survey Device . . . . . . . . . . . . . . . . . . . . . . 18 78 6.2.1. Configuration Object . . . . . . . . . . . . . . . . 18 79 6.2.2. Example Device Configuration . . . . . . . . . . . . 20 80 6.3. Survey Data . . . . . . . . . . . . . . . . . . . . . . . 21 81 6.3.1. Ground Truth . . . . . . . . . . . . . . . . . . . . 22 82 6.3.1.1. PIDF-LO Location . . . . . . . . . . . . . . . . 23 83 6.3.1.2. Raw Location Data . . . . . . . . . . . . . . . . 28 84 6.3.2. Beacons . . . . . . . . . . . . . . . . . . . . . . . 31 85 6.3.3. Signal Measurements . . . . . . . . . . . . . . . . . 31 86 6.3.3.1. WiFi Measurements . . . . . . . . . . . . . . . . 32 87 6.3.3.2. Bluetooth Measurements . . . . . . . . . . . . . 34 88 6.3.3.3. Other Signal Measurements . . . . . . . . . . . . 34 89 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 35 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 91 8.1. Assuring That the Proper LIS Has Been Contacted . . . . . 40 92 8.2. Protecting Responses from Modification . . . . . . . . . 41 93 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 94 9.1. Example of a WiFi Access Point Location Survey . . . . . 41 95 9.2. Example of a WiFi Signal Survey . . . . . . . . . . . . . 45 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 98 11.1. URN Sub-Namespace Registration for 99 urn:ietf:params:xml:ns:geopriv:sigpos . . . . . . . . . 49 100 11.2. XML Schema Registration . . . . . . . . . . . . . . . . 49 101 11.3. MIME Media Type Registration for 102 'application/sigpos+xml' . . . . . . . . . . . . . . . . 50 103 11.4. IANA Registry for Data License Types . . . . . . . . . . 51 104 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 105 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 106 12.2. Informative References . . . . . . . . . . . . . . . . . 53 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 109 1. Introduction 111 This document describes a format for the expression of the 112 measurements and locations of signals (SigPos) within a venue for 113 purposes of providing location services. 115 The format includes a venue description, signal information, and data 116 usage specifications. 118 A venue is defined as an area of interest for providing location 119 services. Examples of a venue include a campus, a building, or a 120 room. A venue should have a single administrative contact for 121 purposes of this document. 123 A positioning beacon (hereafter referred to as a beacon) is a fixed 124 wireless device whose location and signal information may be used for 125 the purpose of positioning other wireless devices. 127 Signal information is inclusive of the specific description and 128 measures of the signal (e.g. 802.11 Wi-Fi signals), a description 129 the device used to measure the signals, as well as the location and 130 orientation of the device. 132 Multiple methods for providing location are defined including civic 133 locations, geodetic locations, absolute locations, relative 134 locations, and locations with error estimates. 136 In addition to the signal information, an optional section provides 137 the ability to specify the data usage rights to be conferred to 138 another entity. One right would be to grant a Location Information 139 Service (LIS) rights to make use of the signal information to provide 140 location services. 142 This document describes the use of HTTP/TLS as transport for the 143 survey data. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Overview 153 This document describes a common method to record, distribute and 154 grant or constrain rights on signal location information related to 155 the geospatial measurement of wireless RF signals. The document sets 156 forth the motivation behind the effort, the basic design of the data 157 format, the reasoning and technical approach for managing the rights 158 of usage for the information, and provides various usage scenarios to 159 further describe the architecture. 161 The primary motivation for this work is in providing a common 162 framework for capturing and sharing information related to the 163 geospatial measurement of RF and environmental signals for purposes 164 of providing locative services based on the transmitters associated 165 with these signals. There may be other uses such as network 166 optimization and interference analysis that could be provided via 167 this specification but these are not the primary goal. 169 Historically, each vendor or entity interested in using sensors 170 (WiFi, cellular, sound ranging) to determine the location of a device 171 has been required to know the geospatial location and attributes 172 associated with a set of transmitters in order to provide location 173 services based on these transmitters. If the locations of the 174 transmitters were not known, the entity would need to 'map' these 175 transmitters and their associated signals through various means and 176 assign them a set of geospatial coordinates and some estimate of the 177 signal map and signal properties of each transmitter. 179 The problem has grown in scale as the number of mobile devices has 180 rapidly expanded along with the proliferation of location-based or 181 location-enhanced applications. This problem can largely be solved 182 for outdoor and coarse indoor positioning using a number of 183 techniques such as drive scanning and end-user device reported 184 information combined with GPS. These techniques have enabled a large 185 portion of the global WiFi signal set to be modeled and used for end- 186 user positioning. 188 However, these methods, even when based on GPS information, have 189 limits on the accuracy to which they can determine the location of a 190 device solely on these signals. The problem is further exacerbated 191 and compounded by the desire to provide indoor positioning with 192 accuracy below 10 meters. 194 Outdoor scanning via vehicles and end-user devices is possible due to 195 the reliable and global reach of GPS. Signals captured in open-air 196 environments can be assigned geospatial coordinates based on the 197 availability of a reliable GPS reading. However, the ability to 198 leverage an existing positioning technology is severely limited when 199 the scanning equipment moves indoors. The availability of GPS is 200 reduced and in many places eliminated. This requires that the 201 scanning equipment use some other means to determine the relative or 202 absolute geospatial position within a building in order to associate 203 the signal measurement with the location in the building. 205 This problem has been addressed by various means in what is generally 206 referred to as a 'site survey'. Specialized hardware with 207 professional grade GPS systems, highly calibrated sensors for dead 208 reckoning, laser range finders or other techniques have often been 209 deployed to accomplish these site surveys. These techniques provide 210 a professional surveyor with the tools and capability to produce a 211 highly accurate signal map of a given building. Unfortunately this 212 process has several drawbacks: 214 o the use of specialized hardware by highly trained engineers is 215 expensive. Scalability is reduced by requiring the design and 216 manufacture of specialized hardware as well as trained individuals 217 to operate the hardware 219 o the process is, in general, a proprietary venture. The resulting 220 information is in a proprietary format and is intended to work 221 with a specific vendor provided location system 223 o it doesn't account for changes. Venues change, the radio, visual, 224 and acoustical environment changes and the transmitters themselves 225 are moved and replaced over time. Coping with this level of 226 entropy and maintaining an up-to-date signal map is both time 227 consuming and costly 229 o the value is locked to a vendor. The value that is obtained from 230 the effort to create a signal map may be realized by the vendor 231 and not the venue owner. Even if the vendor made a portion of the 232 investment, the venue owner may be excluded from additional value 233 in the future 235 o high quality venue maps have not been readily accessible. Having 236 location is an important part of the puzzle, but having the 237 ability to lock the location to a map enables a wide range of 238 applications 240 o mobile devices and applications have traditionally been locked to 241 the vendor who performed the site survey. This made it nearly 242 impossible to scale across different applications and mobile 243 platforms 245 o context is generally more important for indoor positioning than 246 latitude, longitude, and altitude. In other words, it is more 247 important from a user perspective to identify the floor, the room, 248 the aisle, etc. than it is to provide only x, y, z coordinates 250 o there is no common way to convey the information to a LIS 252 The goal of this specification is to reduce these friction points and 253 provide a common method for specifying, encoding, conveying, and 254 granting usage rights to signal survey information. 256 3. Open Issues 258 This document contains a number of open issues that need to be 259 addressed or items that need further refinement, including: 261 1. Survey Device Configuration Specification - this needs continued 262 refinement 264 2. Bluetooth Measurements - these need to be added to the HELD 265 Measurements specification 267 3. Specification of Licensing Options - are there more objections to 268 including these 270 4. Complete xsd definition - a partial XSD is included in this 271 draft, a complete specification is still needed 273 5. Explore use of draft-jennings-senml-10 (Media Types for Sensor 274 Markup Language (SENML)) for sensor data encoding 276 6. Update 802.11 to use 802.11-2012 spec for country code 278 4. Description 279 The basic premise for the SigPos data container is to record a 280 'survey session'. A survey session generally represents a set of 281 contiguous location and sensor scan records that were gathered by a 282 given device. For example, this could represent a survey of the 283 floor of a building, a single point survey, or a survey of a room. 285 This document defines a container for the conveyance of location- 286 related measurement parameters or specifications related to beacon 287 locations and their related signal patterns within an indoor venue. 288 This is an XML container that identifies parameters by type and 289 allows the Device to provide the results of any measurement it is 290 able to perform. A set of measurement schemas are also defined that 291 can be carried in the generic container. Lastly, it allows for the 292 manual specification of both the beacons and their locations. 294 A number of additional concepts are included in this standard such as 295 the identification of the equipment conducting the survey and the 296 inclusion of both explicit and implicit location information. These 297 will be detailed further in following sections. 299 The interpretation of the survey data is left to the implementer of 300 the location service and is not explicitly part of this 301 specification. For example, how to correlate a particular WiFi 302 signal sample with an interpolated location, or how much time lapse 303 between a WiFi signal reading and a GPS sample is permissible. These 304 are choices that are decoupled from the data gathering and 305 transmission, but every attempt has been made to provide the facility 306 to include sufficient information in this standard to enable 307 downstream algorithms to make appropriate choices. 309 This document also describes the use of HTTP/TLS as transport for the 310 survey container. 312 Each capture document corresponds to a 'session'. Each session can 313 have a 'venue' section, a 'survey device' section, and a 'survey' 314 section. The venue describes the venue, the location of the venue, 315 the licensor organization as well as the data rights applicable to 316 the survey. The Venue Section (Section 6.1) describes the venue or 317 location of the survey, and the Survey Device section (Section 6.2) 318 describes the device being used to capture the survey data. 320 The Survey Data section (Section 6.3) describes a method for the 321 actual survey data to be formatted in a standardized format. Each 322 capture session is meant to take place within a single building or 323 structure corresponding to the venue described in the venue section. 324 A session may be composed of many 'survey points'. Each survey point 325 can have a location description, location elements, WiFi keys, WiFi 326 readings and 'other' sensor readings. 328 Note, where possible, location-info objects as described within PIDF- 329 LO and extensions are used to express location information. 331 An overview of the document structure is provided in the following 332 figure. 334 +---------------+ 335 __| Name | 336 | |_______________| 337 | 338 +-----------+ | +---------------+ 339 __| Venue |__|_| Address | 340 | |___________| | |_______________+ +--------------+ 341 | | _| Name | 342 | | +---------------+ | |______________| 343 | |_| Licensor |__| 344 | | |_______________| | +--------------+ 345 | | |_| Address | 346 | | +---------------+ |______________| 347 | |_| License | 348 | |_______________| 349 +---------+ | 350 | Session | -| 351 |_________| | 352 | +---------------+ 353 | __| Configuration | 354 | | |_______________| 355 | | 356 | +-----------+ | +---------------+ +--------------+ 357 |_| Survey |__|_| Survey |____| Sensor |__ 358 | | Device | | Sensors | |______________| 359 | |___________| |_______________| 360 | 361 | +--------------+ 362 | __| Ground Truth |__ 363 | | |______________| 364 | | 365 | +-----------+ +---------------+ | +--------------+ 366 +-| Survey |____| Survey Point |__|_| Beacons |__ 367 |___________| |_______________| | |______________| 368 | 369 | +--------------+ 370 |_| Measurements |__ 371 |______________| 373 Document structure overview. 375 Figure 1 377 5. Using PIDF-LO Location 379 All location information in this container is specified using the 380 GEOPRIV Presence Information Data Format Location Object. This 381 includes the basic definition of the PIDF-LO [RFC4119] object, PIDF- 382 LO Clarification [RFC5491], Revised Civic Location Format [RFC5139], 383 Dynamic Extensions to PIDF-LO [RFC5962], PIDF-LO Relative Location 384 [I-D.ietf-geopriv-relative-location], and Civic Address Extensions 385 [RFC6848]. 387 The PIDF-LO object provides a variety of mechanisms to indicate 388 position. This may refer to the location of the venue, the location 389 of a beacon or the location of the survey device itself. Several of 390 the capabilities of the PIDF-LO object are discussed in this section. 391 For a full specifications refer to the relevant RFCs and Internet 392 Drafts. 394 The PIDF-LO object allows for specification of elements that 395 encompass: 397 o Position 399 o Timestamp 401 o Provider 403 o Uncertainty 405 o Bearing 407 o Speed 409 o Orientation 411 For purposes of signal positioning survey, we define several classes 412 of PIDF-LO objects: 414 o Manual geolocation - human manipulation or specification of a 415 geolocation 417 o Integrated geolocation - system generated geolocation (e.g. via 418 GPS) 420 o Relative location - geolocation based on a defined reference point 422 Each of these methods of providing location can be encoded within the 423 constructs provided by the PIDF-LO structure when combined with the 424 necessary extensions mentioned above and described in more detail in 425 subsequent sections. 427 5.1. Device Orientation 428 The optional orientation elements allows the surveyor to provide 429 precise information with respect to the orientation of the scanning 430 device at the time the readings were made. This orientation 431 information can be used to differentiate signal information when the 432 device is held at different angles at each survey point. 434 From the "Dynamic Extensions to the Presence Information Data Format 435 Location Object (PIDF-LO)" [RFC5962], we find: 437 "The element describes the spatial orientation of the 438 presentity -- the direction that the object is pointing. For a 439 device, this orientation might depend on the type of device." 441 This proposed extension to the PIDF-LO object allows for the 442 inclusion of device orientation within each PIDF-LO object. 444 An example specifying device orientation: 446 453 454 455 456 457 -3 12 458 24 459 278 460 461 462 463 gps 464 465 2009-06-22T20:57:29Z 466 mac:1234567890ab 467 468 470 6. Session 472 The session element creates a container for the other elements of the 473 survey. There should be a single survey per document. 475 The session tag includes two required attributes: the sessionID and 476 the sessionDate. 478 SessionID: contains an opaque string which provides a Universally 479 Unique Identifier (UUID) identifier for this survey as defined by 480 RFC4122 [RFC4122]A Universally Unique IDentifier (UUID) URN 481 Namespace. 483 SessionDate: contains the date the survey was completed. 485 486 ... 487 489 6.1. Venue 491 The venue section describes the venue itself and also provides for 492 two additional elements: the definition of the licensor and the 493 definition of the policy for the included data. 495 +----------------+ 496 | Venue xCard | 497 __| Name/Address | 498 | |________________| 499 | 500 +-----------+ | +----------------+ 501 | Venue |__|_| Licensor xCard | 502 |___________| | | Name/Address | 503 | |________________| 504 | 505 | +----------------+ 506 |_| License | 507 | |________________| 508 | 509 | +----------------+ 510 |_| Map Metadata | 511 |________________| 513 Venue structure overview. 515 Figure 2 517 The venue section of the document provides for the ability to 518 identify the venue in which the survey took place as well as the 519 location of the venue. 521 6.1.1. Venue Name/Address 523 This optional element provides the ability to specify the name and 524 address of the venue for identification purposes. This element uses 525 the xCard [RFC6351] XML format to provide the necessary structure for 526 these elements. 528 529 530 531 Example Building 532 533 534 work 535 Example Building 536 1 South Boston Street 537 Boston, MA USA 02210 538 539 540 541 1 South Boston Street 542 Boston 543 MAs 544 02210 545 USA 546 547 548 550 6.1.2. Licensor 552 The optional licensor section allows for the definition of the 553 organization or individual that has the right to grant another 554 individual or entity a license to the data. The licensor section 555 also makes use of the xCard [RFC6351] format for encoding information 556 about the name and address of the licensor entity. 558 559 560 561 Robert Builder 562 563 Builder 564 Robert 565 566 567 568 569 570 571 work 572 Robert Builder 573 1 South Boston Street 574 Boston, MA USA 02210 575 576 577 578 1 South Boston Street 579 Boston 580 MA 581 02210 582 USA 583 584 585 586 587 work 588 voice 589 590 591 tel:+1-555-555-1212;ext=102 592 593 594 595 work 596 597 robert.builder@example.com 598 599 600 602 6.1.3. Data Rights Management 604 The license object allows the licensor the ability to manage and 605 grant usage rights to the survey data. This document includes a 606 mechanism for including licensing terms. The licensing models are 607 described in more detail below. 609 The object is optional. If missing, the license type is 610 assumed to be 'unrestricted' with a default expiration. 612 6.1.3.1. License Expiry 614 The optional License Expiry tag allows the surveyor to set time 615 limits on the usage granted by the License Type. By default the data 616 license expires 30 days after the date identified in the sessionDate. 618 2008-04-29T14:33:58 620 6.1.3.2. License URI 622 The License URI provides an optional element to identify the terms of 623 a 'Private' license type. This allows the incorporation of 624 additional information relating to the definition of the license 625 terms. 627 6.1.3.3. License Type 629 The optional policy element is intended to allow the licensor of the 630 data gathered for a given venue to provide granular control over the 631 use and subsequent derivative works based on the data. In the event 632 that no policy is specified, it is assumed that the data is released 633 using the unrestricted policy. 635 There are eight pre-defined Data License Types grouped into three 636 categories. 638 6.1.3.3.1. Unrestricted License 640 The unrestricted policy allows for the use and unrestricted 641 derivative products based on the data set. If the data expires, the 642 original data can no longer be used, but any derivative products that 643 were generated during the granted use of the data remain valid. 645 Example of an unrestricted license delcaration: 647 648 2008-04-29T14:33:58 649 unrestricted 650 652 6.1.3.3.2. Creative Commons License 654 The Creative Commons [CC] provide a number of licensing options 655 which, in some cases, permit the licensor of the data to restrict 656 commercial use and/or derivative works. Derivative use of survey 657 data refers to the ability to build or improve a location system 658 based on survey data. Survey data at a high quality could be used to 659 'seed' a location system, allowing an organization to bootstrap a 660 location database over time. At some point, the original data could 661 be removed but the derived database would allow the system to 662 continue to be functional. For data licensors who wish to protect 663 from this, the notion of derivative rights is included in the license 664 structure. 666 Valid Creative Common license types for this specification include 667 the following. 669 For non-commercial use: 671 o Attribution-NonCommercial-ShareAlike CC BY-NC-SA - This license 672 lets others remix, tweak, and build upon the licensor's work non- 673 commercially, as long as they credit the licensor and license 674 their new creations under the identical terms. 676 o Attribution-NonCommercial CC BY-NC - This license lets others 677 remix, tweak, and build upon the licensor's work non-commercially, 678 and although their new works must also acknowledge the licensor 679 and be non-commercial, they don't have to license their derivative 680 works on the same terms. 682 o Attribution-NonCommercial-NoDerivs CC BY-NC-ND - This license only 683 allows others to use the licensor's works and share them with 684 others as long as they credit the licensor, but they can't change 685 them in any way or use them commercially. 687 For commercial use: 689 o Attribution CC BY - This license lets others distribute, remix, 690 tweak, and build upon the licensor's work, even commercially, as 691 long as they credit the licensor for the original creation. 693 o Attribution-NoDerivs CC BY-ND - This license allows for 694 redistribution, commercial and non-commercial, as long as it is 695 passed along unchanged and in whole, with credit to the licensor. 697 o Attribution-ShareAlike CC BY-SA - This license lets others remix, 698 tweak, and build upon the licensor's work even for commercial 699 purposes, as long as they credit the licensor and license their 700 new creations under the identical terms. 702 703 2008-04-29T14:33:58 704 CC BY-ND 705 707 6.1.3.3.3. Private License 709 The private license is intended to provide full control over the 710 usage and derivative usage of the data. Any use of the data would be 711 governed under a separate agreement between the licensor and the 712 party wishing to make use of the data. By default, no rights are 713 granted for private data. 715 For example, suppose a venue owner wishes to provide location 716 services within their venue, but only for their own application. The 717 arrangment for providing this service could be managed separately 718 from the protocol. However, the data itself is fully transportable 719 and allows for the venue owner to reprovision the service with a 720 different provider if they so desire. Service providers without an 721 arrangement could automatically determine that this data cannot be 722 used. 724 725 private 726 http://www.example.com/mylicense.html 727 2008-04-29T14:33:58 728 730 6.1.4. Map Metadata 732 The optional "map" URL can be used to provide a user or system with a 733 visual reference for the location information. This URL 734 specification is based on that provided in Section 4.11 of PIDF-LO 735 Relative Location [I-D.ietf-geopriv-relative-location] specification. 736 For purposes of the overall Venue map, the offset SHOULD provide the 737 offset to the starting location on the map for the survey. 739 740 741 http://example.com/map.jpg 742 743 200 210 744 68 745 2.90 -2.90 746 748 6.2. Survey Device 750 The specification includes elements to describe the capabilities of 751 the hardware and software of the scanning device as well as the 752 hardware and software for the sensors that were used to capture the 753 scan data. This can allow further downstream processing by 754 discriminating source data based on capabilities and known device/ 755 sensor profiles and behaviors. 757 The Survey Device section SHOULD contain one device configuration 758 record. It MAY contain 0-n sensor configuration elements. 760 _+-------------+ +-----------------+ 761 | | Hardware |____|| Configuration || 762 | |_____________| ||_______________|| 763 | 764 |_+-------------+ +-----------------+ 765 | | Software |____|| Configuration || 766 | |_____________| ||_______________|| 767 +---------+ | 768 | Survey |__| 769 | Device | | 770 |_________| | +-------------+ +-------------+ +-----------------+ 771 |_| Sensor (0-n)|____| Hardware |___|| Configuration || 772 |_____________| | |_____________| ||_______________|| 773 | 774 | +-------------+ +-----------------+ 775 |_| Software |___|| Configuration || 776 |_____________| ||_______________|| 778 Survey Device structure overview. 780 Figure 3 782 6.2.1. Configuration Object 784 +-----------------+ 785 __| Type | 786 | |_________________| 787 | 788 | +-----------------+ 789 |_| Id | 790 | |_________________| 791 | 792 | +-----------------+ 793 |_| Name | 794 | |_________________| 796 +-----------------+ | 797 | Configuration |__| +-----------------+ 798 |_________________| |_| Manufacturer | 799 | |_________________| 800 | 801 | +-----------------+ 802 |_| Model | 803 | |_________________| 804 | 805 | +-----------------+ 806 |_| Version | 807 | |_________________| 808 | 809 | +-----------------+ 810 |_| Vendor | 811 | |_________________| 812 | 813 | +-----------------+ 814 |_| Capability | 815 |_________________| 817 Survey Device Configuration structure overview. 819 Figure 4 821 The configuration object allows for the description of a various 822 hardware components used to perform the survey. This allows for the 823 description of the survey device itself as well as any sensors or 824 radio components that are used in performing the survey. 826 The configuration object can contain various elements as described 827 below. Required items are noted. 829 o id - (required) - provides a locally unique identifier for the 830 component being described. For example, this could be the MAC 831 address if describing a WiFi Network Interface Card. 833 o name - (required) - the name of the device/sensor 835 o vendor - (0-1) - a human readable description of the component 836 vendor 838 o model - (0-1) -the model and model number of the component 840 o capability - (0-n) - a name/value pair to allow arbitrary 841 configuration and capability declarations for each configuration 842 object. 844 6.2.2. Example Device Configuration 846 An example object is shown below. 848 849 850 851 device 852 mapit 853 1.2 855 abc 856 900 857 Intel Q965 858 12 volt 859 860 861 862 863 software 864 Centos6 865 2.6.18-308.1.1.el5 #1 SMP x86_64 GNU 866 867 868 869 870 871 000FFA9870BC 872 External WiFi 873 1.23 874 atheros 875 omni-directional 876 10 877 atheros 878 a,b,g,n 879 1-13 880 881 882 883 884 885 atheros driver 886 ath9k 887 888 889 890 891 892 893 gps 894 gm39211 895 4.23a 896 unknown 897 combined 898 qualcomm 899 900 901 902 904 6.3. Survey Data 906 The survey section represents all of the scanned or input data 907 gathered about the venue in this session. Within a 'survey', there 908 may be 0-n 'readings' which will contain a complete set of 909 information about a subset of the survey. For example, a single room 910 could be captured within a 'readings' segment. 912 This document defines location-related measurement data types for a 913 range of common sensor types. 915 All included measurement data definitions allow for arbitrary 916 extension in the corresponding schema. As new parameters that are 917 applicable to location determination are added, these can be added as 918 new XML elements in a unique namespace. Though many of the 919 underlying protocols support extension, creation of specific XML- 920 based extensions to the measurement format is favored over 921 accommodating protocol-specific extensions in generic containers. 923 Note, the "time" attribute records the time that the measurement or 924 observation was made. This time can be different from the time that 925 the measurement information was reported. Time information can be 926 used to populate a timestamp on each ground truth element and to the 927 root "measurement" element. If it is necessary to provide multiple 928 sets of measurement data with different times, multiple "measurement" 929 elements SHOULD be provided. 931 +--------------+ 932 __| Ground Truth |__ 933 | |______________| 934 | 935 +-------------+ +---------------+ | +--------------+ 936 -| Survey Data |___| Survey Point |__|_| Beacons |__ 937 |_____________| |_______________| | |______________| 938 | 939 | +--------------+ 940 |_| Measurements |__ 941 |______________| 943 Document structure overview. 945 Figure 5 947 Survey Points describe a subset of the survey information and 948 potentially include Ground Truth, Beacon IDs, and Signal 949 Measurements. These categories of information are detailed further 950 in the following sections. 952 6.3.1. Ground Truth 954 Ground truth is a term that describes the location of the Survey 955 Device. 957 The 'ground truth' element is designed to allow the specification and 958 recording of the location at which the survey point was captured. To 959 encompass various survey and usage scenarios, there are currently 960 three GroundTruth types available for each survey point. These 961 include PIDF-LO location object, a Contextual Location object, and/or 962 a Raw Location object. These are described further below. 964 Multiple Ground Truth objects are allowed for interpolation between a 965 starting point and an endpoint without explicitly declaring each scan 966 position. The interpolation of the survey data is left to the 967 downstream processor such as an LIS server. 969 groundTruth MUST have at least 1 SurveyPoint object as defined below. 971 +----------------+ +----------+ 972 _| Basic Location |- -| Civic | 973 | |________________| | Location | 974 +-------------+ | |__________| 975 | GroundTruth |___| +----------------+ 976 |_____________| |_| Raw Location | 977 | Data | 978 |________________| 980 Groundtruth structure overview. 982 Figure 6 984 6.3.1.1. PIDF-LO Location 986 This section describes the primary PIDF-LO method types that are 987 supported by this specification. While all PIDF-LO location 988 'methods' are possible, the following are the only methods that MUST 989 be supported. 991 o GPS 993 o A-GPS 995 o Trilateration 997 o Cell 999 o Manual 1001 In addition, support MUST be provided for relative locations as 1002 described below for each of the above PIDF-LO location methods. 1004 6.3.1.1.1. Basic Location 1006 Basic location represents a location as provided by the Survey 1007 Device. This could be from a location API, WiFi positioning, an 1008 integrated GPS, or any other mechanism that computes or determines 1009 the location of the survey device. To encompass this variety of 1010 locative technologies, the structure of the object provides numerous 1011 constructs. 1013 An example of an integrated GPS location including dynamic 1014 orientation extensions is shown below. More examples of encodings 1015 can be found in PIDF-LO Usage [RFC5491]. 1017 1023 1024 1025 1026 1027 1028 42.5463 -73.2512 26.3 1029 1030 7.7156 1031 1032 1033 3.31 1034 1035 1036 28.7 1037 1038 1039 90 1040 1041 1042 -3 12 1043 24 1044 278 1045 1046 1047 1048 1049 gps 1050 1051 1052 2009-06-22T20:57:29Z 1053 1054 1055 1057 6.3.1.1.2. Relative Location 1059 A relative location is based on the topology of the venue and is 1060 specified by first declaring one or more anchors that contain a 1061 geospatial reference. 1063 Relative Location MUST be defined using "Internet Draft Relative 1064 Location Representation" [I-D.ietf-geopriv-relative-location]. 1066 An example of a PIDF-LO geopriv object with relative location 1067 extensions included is shown below. 1069 1075 1076 1077 1078 1079 1080 -34.407 150.883 1081 1082 50.0 1083 1084 1085 1086 1087 1088 -34.407 150.883 1089 1090 1091 1092 1094 500.0 750.0 1095 1096 5.0 1097 1098 1099 1100 1101 1102 https://www.example.com/flrpln/123South/flr-2 1103 2670.0 1124.0 1022.0 1104 67.00 1105 10 1106 1107 1108 1109 Triangulation 1110 1111 2007-06-22T20:57:29Z 1112 1113 1114 1116 6.3.1.1.3. Manual Location 1118 The manual location object allows the surveyor to specify the 1119 geospatial coordinate and/or a civic address to be associated with 1120 the 'readings' data. 1122 This element contains any valid location, using the rules for a 1123 "location-info" element, as described in RFC 5491 [RFC5491]. 1125 Location information in a survey may be described in a geospatial 1126 manner based on a subset of Geography Markup Language (GML) 3.1.1 1127 [OGC-GML3.1.1] or as civic location information RFC 5139 [RFC5139] 1128 and refined in RFC 5774 [RFC5774]. An OGC GML [OGC-GML3.1.1] profile 1129 for expressing geodetic shapes in a PIDF-LO is described in GML 1130 GeoShape Application Schema [GeoShape]. 1132 Below are several examples of manual location objects. 1134 1140 1141 1142 1143 1144 1145 -43.5723 153.21760 1146 1147 1148 1149 2007-06-22T20:57:29Z 1150 1151 1152 1154 Sample manual location using a point. 1156 1162 1163 1164 1165 1166 1167 42.5463 -73.2512 1168 1169 5.24 1170 1171 1173 1174 1175 2007-06-22T20:57:29Z 1176 1177 1178 1180 Sample manual location using a circle with a radius to represent 1181 error estimate. 1183 6.3.1.1.4. Civic Location 1185 To support adding contextual information to survey points during the 1186 survey process, this specification includes the ability to add 1187 extended civic addresses as defined by the optional Contextual 1188 Location object. This object enables the capture of contextual 1189 information with resepect to a survey point. 1191 For example, an office building may have floors, wings, rooms, and 1192 cubes while an amusement park will have rides, booths, food stands 1193 and arcades. The civic address extensions provide a mechanism for 1194 extending these attributes and maintaining interoperability. 1196 Example of civic location: 1198 1204 1205 1206 1207 1208 1209 -43.5723 153.21760 1210 1211 1215 US 1216 CA 1217 2471 1218 AQ-374-4(c) 1219 LAX 1220 Tom Bradley 1221 G 1222 36B 1223 1224 1225 1226 2007-06-22T20:57:29Z 1227 1228 1229 1231 The optional civicAddress object can be included in any of the PIDF- 1232 LO objects defined above. 1234 6.3.1.2. Raw Location Data 1236 To support the capture and conveyance of underlying raw location 1237 data, a common optional container is defined for the expression of 1238 this location measurement data. 1240 Currently only the 'GNSS' raw location type has been defined. Global 1241 Navigation Satellite System (GNSS) readings provide location 1242 measurements based on satellite navigation systems such as that 1243 provided by GPS. 1245 Rather than decomposing GNSS output during the survey, the sentences 1246 from the GNSS systems are transported as is allowing full downstream 1247 processing of the data. 1249 The type attribute specifies the GNSS system type which is 1250 responsible for the reading, e.g. GPS. 1252 The GPS system generally uses the NMEA 0183 [NMEA0183] protocol for 1253 output and many systems have been built to handle this type of 1254 output. To provide the most transparent transport mechanism, the 1255 NMEA sentences are packaged as-is. 1257 The possible sentence names are described below. 1259 The REQUIRED set of sentences include: 1261 $GPGGA - Global Positioning System Fix Data (required) 1262 $GPGSA - GPS DOP and Active Satellites (recommended) 1263 $GPRMC - Recommended Minimum Specific GPS/TRANSIT Data (recommended) 1265 The remaining OPTIONAL sentences are detailed below: 1267 $GPAAM - Waypoint Arrival Alarm 1268 $GPALM - GPS Almanac Data< 1269 $GPAPA - Autopilot Sentence "A" 1270 $GPAPB - Autopilot Sentence "B" 1271 $GPASD - Autopilot System Data 1272 $GPBEC - Bearing & Distance to Waypoint, Dead Reckoning 1273 $GPBOD - Bearing, Origin to Destination 1274 $GPBWC - Bearing & Distance to Waypoint, Great Circle 1275 $GPBWR - Bearing & Distance to Waypoint, Rhumb Line 1276 $GPBWW - Bearing, Waypoint to Waypoint 1277 $GPDBT - Depth Below Transducer 1278 $GPDCN - Decca Position 1279 $GPDPT - Depth 1280 $GPFSI - Frequency Set Information 1281 $GPGLC - Geographic Position, Loran-C 1282 $GPGLL - Geographic Position, Latitude/Longitude 1283 $GPGSV - GPS Satellites in View 1284 $GPGXA - TRANSIT Position 1285 $GPHDG - Heading, Deviation & Variation 1286 $GPHDT - Heading, True 1287 $GPHSC - Heading Steering Command 1288 $GPLCD - Loran-C Signal Data 1289 $GPMTA - Air Temperature (to be phased out) 1290 $GPMTW - Water Temperature 1291 $GPMWD - Wind Direction 1292 $GPMWV - Wind Speed and Angle 1293 $GPOLN - Omega Lane Numbers 1294 $GPOSD - Own Ship Data 1295 $GPR00 - Waypoint active route (not standard) 1296 $GPRMA - Recommended Minimum Specific Loran-C Data 1297 $GPRMB - Recommended Minimum Navigation Information 1298 $GPROT - Rate of Turn 1299 $GPRPM - Revolutions 1300 $GPRSA - Rudder Sensor Angle 1301 $GPRSD - RADAR System Data 1302 $GPRTE - Routes 1303 $GPSFI - Scanning Frequency Information 1304 $GPSTN - Multiple Data ID 1305 $GPTRF - Transit Fix Data 1306 $GPTTM - Tracked Target Message 1307 $GPVBW - Dual Ground/Water Speed 1308 $GPVDR - Set and Drift 1309 $GPVHW - Water Speed and Heading 1310 $GPVLW - Distance Traveled through the Water 1311 $GPVPW - Speed, Measured Parallel to Wind 1312 $GPVTG - Track Made Good and Ground Speed 1313 $GPWCV - Waypoint Closure Velocity 1314 $GPWNC - Distance, Waypoint to Waypoint 1315 $GPWPL - Waypoint Location 1316 $GPXDR - Transducer Measurements 1317 $GPXTE - Cross-Track Error, Measured 1318 $GPXTR - Cross-Track Error, Dead Reckoning 1319 $GPZDA - Time & Date 1320 $GPZFO - UTC & Time from Origin Waypoint 1321 $GPZTG - UTC & Time to Destination Waypoint 1323 The sentences contain the name of the sentence in the content so 1324 there is no reason to add additional identifying information beyond 1325 the sentence itself. 1327 The GPS configuration may optionally be detailed in the device sensor 1328 descriptions section. 1330 Example: 1332 1333 1334 1335 GPGGA 1336 1337 $GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76 1338 1339 GPGSA 1340 1341 $GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A 1342 1343 GPSV 1344 1345 $GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70 1346 1347 GPSV 1348 1349 $GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79 1350 1351 GPRMC 1352 1353 $GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43 1354 1355 1356 1357 1359 6.3.2. Beacons 1361 The intent of the object is to allow the surveyor to 1362 identify individual beacons and specify the location of that beacon. 1363 In other words, in a site survey where beacon A is located at x1, y1 1364 and beacon B is located at x2, y2, this construct would allow for 1365 that. This is for those instances where exact beacon position is 1366 useful for the LIS to compute device locations. 1368 Beacon Identification 1370 1372 The beacon object allows the identification of a specific set of 1373 beacons. A beacon is specified as an object to be used for 1374 positioning which can be identified by a unique identifier. For 1375 example in an Infrastructure WiFi network, the basic service set 1376 identifier (bssid) is the 48 bit MAC address of the access point. 1377 This specification allows for the possibility of manually identifying 1378 beacons and including that information in the survey. 1380 The type attribute is required. 1382 1383 1384 003200A475C5 1385 1386 1388 The elements include: 1390 o id (required) - indicates the key(s) necessary to uniquely 1391 identify the beacon of the given type 1393 6.3.3. Signal Measurements 1395 Signal-Related Measurement Data Types 1397 A common container is defined for the expression of location 1398 measurement data, as well as a simple means of identifying specific 1399 types of measurement data for the purposes of requesting them. 1401 The following example shows a measurement container with measurement 1402 time included. A WiFi measurement is enclosed. 1404 1407 1408 1409 00-12-F0-A0-80-EF 1410 wlan-home 1411 1412 1413 1415 The "measurement" element is used to encapsulate measurement data 1416 that is collected at a certain point in time. It contains time-based 1417 attributes that are common to all forms of measurement data, and 1418 permits the inclusion of arbitrary measurement data. 1420 6.3.3.1. WiFi Measurements 1422 WiFi Measurements are based on the proposed measurements defined in 1423 the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements] 1424 document. 1426 In WiFi, or 802.11 [IEEE.80211.2007], networks a Device might be able 1427 to provide information about the access point (AP) that it is 1428 attached to, or other WiFi points it is able to see. This is 1429 provided using the "wifi" element, as shown in Figure 6, which shows 1430 a single complete measurement for a single access point. 1432 WiFi scan elements contain a single record for each Access Point 1433 which was scanned for each time stamp that that AP was scanned. 1435 APs should be scanned as rapidly as feasible to obtain as many 1436 samples as possible. 1438 1440 1441 Intel(r)PRO/Wireless 2200BG 1442 1443 AB-CD-EF-AB-CD-EF 1444 example 1445 5 1446 1447 1448 -34.4 150.8 1449 1450 1451 a/g 1452 5 1453 2 1454 2 1455 2.56e-9 1456 1457 23 1458 5 1459 -59 1460 23 1461 1462 1463 10 1464 9 1465 -98.5 1466 7.5 1467 1468 1469 1470 1472 802.11 WiFi Measurement Example 1474 A wifi element is made up of one or more access points, and an 1475 optional "nicType" element. Each access point is described using the 1476 "ap" element, which is comprised of the following fields: 1478 Required: 1480 o bssid: The basic service set identifier. In an Infrastructure BSS 1481 network, the bssid is the 48 bit MAC address of the access point. 1482 The "verified" attribute of this element describes whether the 1483 device has verified the MAC address or it authenticated the access 1484 point or the network operating the access point (for example, a 1485 captive portal accessed through the access point has been 1486 authenticated). This attributes defaults to a value of "false" 1487 when omitted. 1489 o rcpi: The received channel power indicator for the access point 1490 signal, as measured by the Device. This value SHOULD be in units 1491 of dBm (with RMS error in dB). If power is measured in a 1492 different fashion, the "dBm" attribute MUST be set to "false". 1493 Signal strength reporting on current hardware uses a range of 1494 different mechanisms; therefore, the value of the "nicType" 1495 element SHOULD be included if the units are not known to be in dBm 1496 and the value reported by the hardware should be included without 1497 modification. This element includes optional "rmsError" and 1498 "samples" attributes. 1500 Optional (as defined in the IETF I-D Held Measurements 1501 [I-D.ietf-geopriv-held-measurements] document. 1503 o ssid 1505 o channel 1507 o location 1509 o type 1511 o band 1513 o regclass 1515 o antenna 1517 o flightTime 1519 o apSignal 1521 6.3.3.2. Bluetooth Measurements 1523 Note: these need to be clarified and added to held-measurements. 1525 Bluetooth devices provide an alternative method for determining 1526 location. The bluetooth object provides a method to capture 1527 measurements related to bluetooth devices discovered during the 1528 survey. 1530 o Address/UUID - 48-bit unique identifier 1532 o Name 1534 o Version 1536 o Manufacturer 1538 o Features 1540 o Class 1542 o Signal Strength 1544 o Link Quality 1546 6.3.3.3. Other Signal Measurements 1547 The container allows for the definition of other measurements to be 1548 captured. These could include measurements of such things as sound 1549 ranging or echolocation signals, cellular signals, or other 1550 electromagnetic signal measurement. 1552 7. XML Schema 1554 This section gives the XML Schema Definition [W3C.REC- 1555 xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the 1556 "application/held+xml" format. This is presented as a formal 1557 definition of the "application/sigpos+xml" format. Note that the XML 1558 Schema Definition is not intended to be used with on-the-fly 1559 validation of the presence XML document. Whitespaces are included in 1560 the schema to conform to the line length restrictions of the RFC 1561 format without having a negative impact on the readability of the 1562 document. Any conforming processor should remove leading and 1563 trailing white spaces. 1565 The XML schema depicted below supports the Beacon Location mode of 1566 SigPos Survey data only. 1568 1569 1582 1583 1584 This document defines SigPos messages. 1585 (draft-jones-geopriv-sigpos-survey) 1586 1587 1589 1592 1595 1598 1599 1600 1601 1602 1604 1606 1607 1608 1609 1610 1611 1613 1614 1615 1616 1617 1618 1619 1620 1622 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1646 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1665 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1678 1680 1682 1684 1686 1687 1688 1689 1692 1695 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1715 1716 1717 1718 1719 1720 1721 1723 1724 1725 1726 1727 1728 1729 1730 1731 1733 1735 1737 1738 1740 1741 1742 1743 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1759 1760 1762 1763 1764 1766 1767 1768 1769 1770 1771 1772 1773 1775 1776 1777 1778 1779 1780 1782 SigPos Partial XML Schema 1784 8. Security Considerations 1786 Location-related measurement data can be as privacy sensitive as 1787 location information. 1789 Survey data is effectively equivalent to location information if the 1790 contextual knowledge necessary to generate one from the other is 1791 readily accessible. Even where contextual knowledge is difficult to 1792 acquire, there can be no assurance that an authorized recipient of 1793 the contextual knowledge is also authorized to receive location 1794 information. 1796 In order to protect the privacy of the subject of location-related 1797 survey data, this implies that survey data is protected with a 1798 similar degree of protection as location information. 1800 Survey Data Privacy Model 1802 In general, survey data represents a smaller privacy risk than 1803 personal location information. It does however represent potential 1804 privacy risks especially with respect to venues which have security 1805 risks or wish to maintain control over the exposure of detailed 1806 location information. 1808 No entity is permitted to redistribute survey data except as 1809 specified in the data license. The Device directs other entities in 1810 how survey data is used and retained. 1812 8.1. Assuring That the Proper LIS Has Been Contacted 1813 This document assumes that the LIS to be contacted is identified 1814 either by an IP address or a domain name, as is the case for a LIS 1815 discovered as described in LIS Discovery [RFC5986]. As the SigPos 1816 transaction is conducted using TLS [RFC5246], the LIS can 1817 authenticate its identity, either as a domain name or as an IP 1818 address, to the client by presenting a certificate containing that 1819 identifier as a subjectAltName (i.e., as an iPAddress or dNSName, 1820 respectively). In the case of the HTTP binding described above, this 1821 is exactly the authentication described by TLS [RFC2818]. If the 1822 client has external information as to the expected identity or 1823 credentials of the proper LIS (e.g., a certificate fingerprint), 1824 these checks MAY be omitted. Any binding of SigPos MUST be capable 1825 of being transacted over TLS so that the client can request the above 1826 authentication, and a LIS implementation for a binding MUST include 1827 this feature. Note that in order for the presented certificate to be 1828 valid at the client, the client must be able to validate the 1829 certificate. In particular, the validation path of the certificate 1830 must end in one of the client's trust anchors, even if that trust 1831 anchor is the LIS certificate itself. 1833 8.2. Protecting Responses from Modification 1835 In order to prevent a response from being modified en route, messages 1836 must be transmitted over an integrity-protected channel. When the 1837 transaction is being conducted over TLS (a required feature per 1838 Section 11.1), the channel will be integrity protected by appropriate 1839 ciphersuites. When TLS is not used, this protection will vary 1840 depending on the binding; in most cases, without protection from TLS, 1841 the response will not be protected from modification en route. 1843 9. Examples 1845 The following sections provide examples of basic HTTP/HTTPS, a simple 1846 location request, and a location request for multiple location types, 1847 along with the relevant location responses. To focus on important 1848 portions of messages, the examples in Sections 10.2 and 10.3 do not 1849 show HTTP/HTTPS headers or the XML prologue. In addition, sections 1850 of XML not relevant to the example are replaced with comments. 1852 9.1. Example of a WiFi Access Point Location Survey 1854 The examples in this section show example HTTPS messages that include 1855 the SigPos submission or response document. 1857 POST /location HTTP/1.1 1858 Host: sigpos.example.com:49152 1859 Content-Type: application/sigpos+xml;charset=utf-8 1860 Content-Length: nnn 1861 1863 A simple example of a small survey composed of two survey points is 1864 illustrated by the example message below. This uses the static 1865 beacon key survey model. 1867 1868 1877 1878 1879 1880 Example Building 1881 1882 1883 work 1884 Example Building 1885 1 South Boston Street 1886 Boston, MA USA 02210 1887 1888 1889 1890 1 South Boston Street 1891 Boston 1892 MA 1893 02210 1894 USA 1895 1896 1897 1898 1899 Rober Builder 1900 1901 Builder 1902 Robert 1903 1904 1905 1906 1907 1908 1909 work 1910 Rober Builder 1911 1 South Boston Street 1912 Boston, MA USA 02210 1913 1914 1915 1916 1 South Boston Street 1917 Boston 1918 MA 1919 02210 1920 USA 1921 1922 1923 1924 1925 work 1926 voice 1927 1928 1929 tel:+1-555-555-1212;ext=102 1930 1931 1932 1933 work 1934 1935 reober.builder@example.com 1936 1937 1938 1939 1940 CC BY 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 -34.4 150.8 1953 1954 1955 US 1956 CA 1957 LAX 1958 Tom Bradley 1959 G 1960 36B 1961 1962 1963 1964 2012-02-21T14:33:58:05 1965 1966 1967 1968 1969 1970 FF00FF723CBA 1971 FF00FF723CBB 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 -34.35 150.83 1983 1984 1985 1986 2012-02-21T14:33:58:06 1987 1988 1989 1990 1991 1992 FF00FF723A00 1993 1994 1995 1996 1997 1998 2000 802.11 WiFi Beacon Survey 2002 9.2. Example of a WiFi Signal Survey 2004 A simple example of wifi scan data conveyance using gps for ground 2005 truth is illustrated by the example message below. 2007 2008 2017 2018 2019 2020 Example Building 2021 2022 2023 work 2024 Example Building 2025 1 South Boston Street 2026 Boston, MA USA 02210 2027 2028 2029 2030 1 South Boston Street 2031 Boston 2032 MA 2033 02210 2034 USA 2035 2036 2037 2038 2039 Rober Builder 2040 2041 Builder 2042 Robert 2043 2044 2045 2046 2047 2048 2049 work 2050 Rober Builder 2051 1 South Boston Street 2052 Boston, MA USA 02210 2053 2054 2055 2056 1 South Boston Street 2057 Boston 2058 MA 2059 02210 2060 USA 2061 2062 2063 2064 2065 work 2066 voice 2067 2068 2069 tel:+1-555-555-1212;ext=102 2070 2071 2072 2073 work 2074 2075 reober.builder@example.com 2076 2077 2078 2079 2080 unrestricted 2081 2012-10-29T14:33:58 2082 2083 2084 2085 2086 00EFDA7200B004 2087 lumina 2088 smartphone 2089 900 2090 1.2 2091 2092 2093 2094 wifi 2095 ath0 2096 omni-directional 2097 aetheros 2098 newco 2099 2100 a,b,g,n 2101 1-13 2102 2103 2104 2105 2106 2107 gps 2108 gps3210 2109 combined 2110 qualcomm 2111 newco 2112 2113 standard 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 -34.35 150.83 2128 2129 2130 2131 2012-02-21T14:33:58:06 2132 2133 2134 2135 2136 2137 2138 GPGGA 2139 2140 $GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76 2141 2142 GPGSA 2143 2144 $GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A 2145 2146 GPSV 2147 2148 $GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70 2149 2150 GPSV 2151 2152 $GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79 2153 2154 GPRMC 2155 2156 $GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43 2157 2158 2159 2160 2161 2162 2164 2165 2166 00-12-F0-A0-80-EF 2167 wlan-home 2168 -85 2169 2170 2171 00-11-F0-A0-80-EF 2172 wlan-other 2173 -92 2174 2175 2176 2177 2178 2179 2180 2181 2183 802.11 WiFi Signal Scan Survey 2185 10. Acknowledgements 2187 This template was derived from an initial version written by Pekka 2188 Savola and contributed by him to the xml2rfc project. Thanks to 2189 Richard Barnes and Stephane Terrenoir, Adam Roach, Robin Wilton, and 2190 Martin Thompson for initial reviews and valuable feedback. 2192 11. IANA Considerations 2194 This section creates a registry for Data License types 2195 (Section 6.1.3.3) and registers the namesapces and schema defined in 2196 the Schemas (Section 7) secction. 2198 11.1. URN Sub-Namespace Registration for 2199 urn:ietf:params:xml:ns:geopriv:sigpos 2201 This section registers a new XML namespace, 2202 "urn:ietf:params:xml:ns:geopriv:sigpos", per the guidelines in 2203 [RFC3688]. 2205 URI: urn:ietf:params:xml:ns:geopriv:sigpos 2207 Registrant Contact: IETF, . 2209 XML 2211 BEGIN 2212 2213 2215 2216 2217 SigPos Messages 2218 2219 2220

Namespace for SigPos Messages

2221

urn:ietf:params:xml:ns:geopriv:sigpos

2222

See draft-jones-geopriv-sigpos-survey

2223 2224 2225 END 2227 11.2. XML Schema Registration 2229 This section registers an XML schema as per the guidelines in 2230 [RFC3688]. 2232 URI: urn:ietf:params:xml:schema:geopriv:sigpos 2234 Registrant Contact: IETF, . 2236 Schema: The XML for this schema can be found as the entirety of 2237 Section 9 of this document. 2239 11.3. MIME Media Type Registration for 'application/sigpos+xml' 2241 This section registers the "application/sigpos+xml" MIME type. 2243 To: ietf-types@iana.org 2245 Subject: Registration of MIME media type application/sigpos+xml 2247 MIME media type name: application 2249 MIME subtype name: sigpos+xml 2251 Required parameters: (none) 2253 Optional parameters: charset 2255 Same as the charset parameter of "application/xml" as specified in 2256 RFC 3023 [RFC3023], Section 3.2. 2258 Encoding considerations: Same as the encoding considerations of 2259 "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. 2261 Security considerations: This content type is designed to carry 2262 protocol data related to the location of signal beacons, which could 2263 include information that is considered private. Appropriate 2264 precautions should be taken to limit disclosure of this information. 2266 Interoperability considerations: This content type provides a basis 2267 for a protocol. There are multiple interoperable implementations of 2268 this protocol. 2270 Published specification: 2272 Applications which use this media type: Location information 2273 surveyors and service providers. 2275 Additional Information: 2277 Magic Number(s): (none) 2279 File extension(s): .heldxml 2281 Macintosh File Type Code(s): "TEXT" 2283 Person & email address to contact for further information: 2285 Mary Barnes Intended usage: LIMITED USE 2286 Author/Change controller: The IETF 2288 Other information: This media type is a specialization of application 2289 /xml [RFC3023], and many of the considerations described there also 2290 apply to application/held+xml. 2292 11.4. IANA Registry for Data License Types 2294 This document establishes a new IANA registry for the for Data 2295 License types (Section 6.1.3.3). This reegistry includes tokens for 2296 the Data License type. Referring to the [RFC5226], this registry 2297 operates under "Specification Required" rules. The IESG will appoint 2298 an Expert Review who will advice IANA promptly on each request for a 2299 new or updated Data License type. 2301 Each entry in the registry requires the following information: 2303 o Data License name: the name of the data license 2305 o Brief Description: a brief description of the data license 2307 o URI: optional URI to the license definition 2309 This section pre-registers 8 new 'licenseType' tokens associated with 2310 the 'licenseType' 2312 1. unrestricted: this license allows for the use and unrestricted 2313 derivative products based on the data set 2315 2. CC BY: this license lets others distribute, remix, tweak, and 2316 build upon your work, even commercially, as long as they credit 2317 you for the original creation. 2319 3. CC BY-ND: this license allows for redistribution, commercial and 2320 non-commercial, as long as it is passed along unchanged and in 2321 whole, with credit to you. 2323 4. CC BY-NC-SA: this license lets others remix, tweak, and build 2324 upon your work non-commercially, as long as they credit you and 2325 license their new creations under the identical terms. 2327 5. CC BY-SA: this license lets others remix, tweak, and build upon 2328 your work even for commercial purposes, as long as they credit 2329 you and license their new creations under the identical terms. 2331 6. CC BY-NC: this license lets others remix, tweak, and build upon 2332 your work even for commercial purposes, as long as they credit 2333 you and license their new creations under the identical terms. 2335 7. CC BY-NC-ND: this license is the most restrictive of our six main 2336 licenses, only allowing others to download your works and share 2337 them with others as long as they credit you, but they can't 2338 change them in any way or use them commercially. 2340 8. private: this license is intended to provide full control over 2341 the usage and derivative usage of the data. Any use of the data 2342 would be governed under a separate agreement between the licensor 2343 and the party wishing to make use of the data. By default, no 2344 rights are granted for private data. 2346 12. References 2348 12.1. Normative References 2350 [I-D.ietf-geopriv-held-measurements] 2351 Thomson, M. and J. Winterbottom, "Using Device-provided 2352 Location-Related Measurements in Location Configuration 2353 Protocols", draft-ietf-geopriv-held-measurements-07 (work 2354 in progress), April 2013. 2356 [I-D.ietf-geopriv-relative-location] 2357 Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. 2358 Thomson, "Relative Location Representation", draft-ietf- 2359 geopriv-relative-location-04 (work in progress), March 2360 2013. 2362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2363 Requirement Levels", BCP 14, RFC 2119, March 1997. 2365 [RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, 2366 S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP 2367 Authentication: Basic and Digest Access Authentication", 2368 RFC 2617, June 1999. 2370 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 2371 Types", RFC 3023, January 2001. 2373 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2374 January 2004. 2376 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 2377 Format", RFC 4119, December 2005. 2379 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2380 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2381 2005. 2383 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 2384 Format for Presence Information Data Format Location 2385 Object (PIDF-LO)", RFC 5139, February 2008. 2387 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2388 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2390 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 2391 Presence Information Data Format Location Object (PIDF-LO) 2392 Usage Clarification, Considerations, and Recommendations", 2393 RFC 5491, March 2009. 2395 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 2396 Thomson, "Dynamic Extensions to the Presence Information 2397 Data Format Location Object (PIDF-LO)", RFC 5962, 2398 September 2010. 2400 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 2401 Location Information Server (LIS)", RFC 5986, September 2402 2010. 2404 [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 2405 6351, August 2011. 2407 [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and 2408 R. George, "Specifying Civic Address Extensions in the 2409 Presence Information Data Format Location Object (PIDF- 2410 LO)", RFC 6848, January 2013. 2412 12.2. Informative References 2414 [CC] Creative Commons, "Creative Commons LIcenses", 2012, 2415 . 2417 [GeoShape] 2418 , "GML GeoShape Application Schema for use in internet 2419 standards developed by the IETF", 2006, . 2422 [IEEE.80211.2007] 2423 , "Information technology - Telecommunications and 2424 information exchange between systems - Local and 2425 metropolitan area networks - Specific requirements - Part 2426 11: Wireless LAN Medium Access Control (MAC) and Physical 2427 Layer (PHY) specifications", 2007, . 2430 [NMEA0183] 2431 , "NMEA 0183", 2007, 2432 . 2434 [OGC-GML3.1.1] 2435 , "Geography Markup Language (GML) 3.1.1", 2003, 2436 . 2438 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2440 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2441 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2442 May 2008. 2444 [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic 2445 Addresses in the Presence Information Data Format Location 2446 Object (PIDF-LO): Guidelines and IANA Registry 2447 Definition", BCP 154, RFC 5774, March 2010. 2449 Authors' Addresses 2451 Kipp Jones 2452 Skyhook Wireless 2453 34 Farnsworth Street 2454 Boston 02210 2455 US 2457 Phone: +1 (617) 314-9802 2458 Email: kjones@skyhookwireless.com 2460 Christopher Steger 2461 Skyhook Wireless 2462 34 Farnsworth Street 2463 Boston 2464 US 2466 Phone: +1 (617) 314-9802 2467 Email: csteger@skyhookwireless.com