Geographic Location/Privacy K. Jones Internet-Draft C. Steger Intended status: Standards Track Skyhook Wireless Expires: November 10, 2013 May 09, 2013 Indoor Signal Position Conveyance draft-jones-geopriv-sigpos-survey-02 Abstract Location Information Servers rely on signal surveys to create a signal map allowing for subsequent device location determination. This document describes a method by which a Survey Device is able to provide indoor location related measurement data to a LIS for positioning purposes. Location related measurement information comprises observations concerning properties related to the position of a Survey Device and the radio, electromagnetic, and other observable environmental measures as perceived by the Survey Device. These measurements could be data about Wi-Fi signals, Bluetooth signals, barometric pressure, or any other environmental measurement which could sent to a LIS for subsequent processing to help determine the location of devices that later enter the venue. A basic set of location-related measurements, data rights disclosure and location types are defined. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 10, 2013. Jones & Steger Expires November 10, 2013 [Page 1] Internet-Draft Signal Position Survey May 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Using PIDF-LO Location . . . . . . . . . . . . . . . . . . . 9 5.1. Device Orientation . . . . . . . . . . . . . . . . . . . 10 6. Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Venue Name/Address . . . . . . . . . . . . . . . . . 13 6.1.2. Licensor . . . . . . . . . . . . . . . . . . . . . . 13 6.1.3. Data Rights Management . . . . . . . . . . . . . . . 14 6.1.3.1. License Expiry . . . . . . . . . . . . . . . . . 15 6.1.3.2. License URI . . . . . . . . . . . . . . . . . . . 15 6.1.3.3. License Type . . . . . . . . . . . . . . . . . . 15 6.1.4. Map Metadata . . . . . . . . . . . . . . . . . . . . 17 6.2. Survey Device . . . . . . . . . . . . . . . . . . . . . . 18 6.2.1. Configuration Object . . . . . . . . . . . . . . . . 18 6.2.2. Example Device Configuration . . . . . . . . . . . . 20 6.3. Survey Data . . . . . . . . . . . . . . . . . . . . . . . 21 6.3.1. Ground Truth . . . . . . . . . . . . . . . . . . . . 22 6.3.1.1. PIDF-LO Location . . . . . . . . . . . . . . . . 23 6.3.1.2. Raw Location Data . . . . . . . . . . . . . . . . 28 6.3.2. Beacons . . . . . . . . . . . . . . . . . . . . . . . 31 6.3.3. Signal Measurements . . . . . . . . . . . . . . . . . 31 6.3.3.1. WiFi Measurements . . . . . . . . . . . . . . . . 32 6.3.3.2. Bluetooth Measurements . . . . . . . . . . . . . 34 6.3.3.3. Other Signal Measurements . . . . . . . . . . . . 34 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 8.1. Assuring That the Proper LIS Has Been Contacted . . . . . 40 Jones & Steger Expires November 10, 2013 [Page 2] Internet-Draft Signal Position Survey May 2013 8.2. Protecting Responses from Modification . . . . . . . . . 41 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 9.1. Example of a WiFi Access Point Location Survey . . . . . 41 9.2. Example of a WiFi Signal Survey . . . . . . . . . . . . . 45 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 11.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:sigpos . . . . . . . . . 49 11.2. XML Schema Registration . . . . . . . . . . . . . . . . 49 11.3. MIME Media Type Registration for 'application/sigpos+xml' . . . . . . . . . . . . . . . . 50 11.4. IANA Registry for Data License Types . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 12.1. Normative References . . . . . . . . . . . . . . . . . . 52 12.2. Informative References . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 1. Introduction This document describes a format for the expression of the measurements and locations of signals (SigPos) within a venue for purposes of providing location services. The format includes a venue description, signal information, and data usage specifications. A venue is defined as an area of interest for providing location services. Examples of a venue include a campus, a building, or a room. A venue should have a single administrative contact for purposes of this document. A positioning beacon (hereafter referred to as a beacon) is a fixed wireless device whose location and signal information may be used for the purpose of positioning other wireless devices. Signal information is inclusive of the specific description and measures of the signal (e.g. 802.11 Wi-Fi signals), a description the device used to measure the signals, as well as the location and orientation of the device. Multiple methods for providing location are defined including civic locations, geodetic locations, absolute locations, relative locations, and locations with error estimates. Jones & Steger Expires November 10, 2013 [Page 3] Internet-Draft Signal Position Survey May 2013 In addition to the signal information, an optional section provides the ability to specify the data usage rights to be conferred to another entity. One right would be to grant a Location Information Service (LIS) rights to make use of the signal information to provide location services. This document describes the use of HTTP/TLS as transport for the survey data. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Overview This document describes a common method to record, distribute and grant or constrain rights on signal location information related to the geospatial measurement of wireless RF signals. The document sets forth the motivation behind the effort, the basic design of the data format, the reasoning and technical approach for managing the rights of usage for the information, and provides various usage scenarios to further describe the architecture. The primary motivation for this work is in providing a common framework for capturing and sharing information related to the geospatial measurement of RF and environmental signals for purposes of providing locative services based on the transmitters associated with these signals. There may be other uses such as network optimization and interference analysis that could be provided via this specification but these are not the primary goal. Historically, each vendor or entity interested in using sensors (WiFi, cellular, sound ranging) to determine the location of a device has been required to know the geospatial location and attributes associated with a set of transmitters in order to provide location services based on these transmitters. If the locations of the transmitters were not known, the entity would need to 'map' these transmitters and their associated signals through various means and assign them a set of geospatial coordinates and some estimate of the signal map and signal properties of each transmitter. The problem has grown in scale as the number of mobile devices has rapidly expanded along with the proliferation of location-based or location-enhanced applications. This problem can largely be solved for outdoor and coarse indoor positioning using a number of techniques such as drive scanning and end-user device reported Jones & Steger Expires November 10, 2013 [Page 4] Internet-Draft Signal Position Survey May 2013 information combined with GPS. These techniques have enabled a large portion of the global WiFi signal set to be modeled and used for end- user positioning. However, these methods, even when based on GPS information, have limits on the accuracy to which they can determine the location of a device solely on these signals. The problem is further exacerbated and compounded by the desire to provide indoor positioning with accuracy below 10 meters. Outdoor scanning via vehicles and end-user devices is possible due to the reliable and global reach of GPS. Signals captured in open-air environments can be assigned geospatial coordinates based on the availability of a reliable GPS reading. However, the ability to leverage an existing positioning technology is severely limited when the scanning equipment moves indoors. The availability of GPS is reduced and in many places eliminated. This requires that the scanning equipment use some other means to determine the relative or absolute geospatial position within a building in order to associate the signal measurement with the location in the building. This problem has been addressed by various means in what is generally referred to as a 'site survey'. Specialized hardware with professional grade GPS systems, highly calibrated sensors for dead reckoning, laser range finders or other techniques have often been deployed to accomplish these site surveys. These techniques provide a professional surveyor with the tools and capability to produce a highly accurate signal map of a given building. Unfortunately this process has several drawbacks: o the use of specialized hardware by highly trained engineers is expensive. Scalability is reduced by requiring the design and manufacture of specialized hardware as well as trained individuals to operate the hardware o the process is, in general, a proprietary venture. The resulting information is in a proprietary format and is intended to work with a specific vendor provided location system o it doesn't account for changes. Venues change, the radio, visual, and acoustical environment changes and the transmitters themselves are moved and replaced over time. Coping with this level of entropy and maintaining an up-to-date signal map is both time consuming and costly o the value is locked to a vendor. The value that is obtained from the effort to create a signal map may be realized by the vendor and not the venue owner. Even if the vendor made a portion of the Jones & Steger Expires November 10, 2013 [Page 5] Internet-Draft Signal Position Survey May 2013 investment, the venue owner may be excluded from additional value in the future o high quality venue maps have not been readily accessible. Having location is an important part of the puzzle, but having the ability to lock the location to a map enables a wide range of applications o mobile devices and applications have traditionally been locked to the vendor who performed the site survey. This made it nearly impossible to scale across different applications and mobile platforms o context is generally more important for indoor positioning than latitude, longitude, and altitude. In other words, it is more important from a user perspective to identify the floor, the room, the aisle, etc. than it is to provide only x, y, z coordinates o there is no common way to convey the information to a LIS The goal of this specification is to reduce these friction points and provide a common method for specifying, encoding, conveying, and granting usage rights to signal survey information. 3. Open Issues This document contains a number of open issues that need to be addressed or items that need further refinement, including: 1. Survey Device Configuration Specification - this needs continued refinement 2. Bluetooth Measurements - these need to be added to the HELD Measurements specification 3. Specification of Licensing Options - are there more objections to including these 4. Complete xsd definition - a partial XSD is included in this draft, a complete specification is still needed 5. Explore use of draft-jennings-senml-10 (Media Types for Sensor Markup Language (SENML)) for sensor data encoding 6. Update 802.11 to use 802.11-2012 spec for country code 4. Description Jones & Steger Expires November 10, 2013 [Page 6] Internet-Draft Signal Position Survey May 2013 The basic premise for the SigPos data container is to record a 'survey session'. A survey session generally represents a set of contiguous location and sensor scan records that were gathered by a given device. For example, this could represent a survey of the floor of a building, a single point survey, or a survey of a room. This document defines a container for the conveyance of location- related measurement parameters or specifications related to beacon locations and their related signal patterns within an indoor venue. This is an XML container that identifies parameters by type and allows the Device to provide the results of any measurement it is able to perform. A set of measurement schemas are also defined that can be carried in the generic container. Lastly, it allows for the manual specification of both the beacons and their locations. A number of additional concepts are included in this standard such as the identification of the equipment conducting the survey and the inclusion of both explicit and implicit location information. These will be detailed further in following sections. The interpretation of the survey data is left to the implementer of the location service and is not explicitly part of this specification. For example, how to correlate a particular WiFi signal sample with an interpolated location, or how much time lapse between a WiFi signal reading and a GPS sample is permissible. These are choices that are decoupled from the data gathering and transmission, but every attempt has been made to provide the facility to include sufficient information in this standard to enable downstream algorithms to make appropriate choices. This document also describes the use of HTTP/TLS as transport for the survey container. Each capture document corresponds to a 'session'. Each session can have a 'venue' section, a 'survey device' section, and a 'survey' section. The venue describes the venue, the location of the venue, the licensor organization as well as the data rights applicable to the survey. The Venue Section (Section 6.1) describes the venue or location of the survey, and the Survey Device section (Section 6.2) describes the device being used to capture the survey data. The Survey Data section (Section 6.3) describes a method for the actual survey data to be formatted in a standardized format. Each capture session is meant to take place within a single building or structure corresponding to the venue described in the venue section. A session may be composed of many 'survey points'. Each survey point can have a location description, location elements, WiFi keys, WiFi readings and 'other' sensor readings. Jones & Steger Expires November 10, 2013 [Page 7] Internet-Draft Signal Position Survey May 2013 Note, where possible, location-info objects as described within PIDF- LO and extensions are used to express location information. An overview of the document structure is provided in the following figure. Jones & Steger Expires November 10, 2013 [Page 8] Internet-Draft Signal Position Survey May 2013 +---------------+ __| Name | | |_______________| | +-----------+ | +---------------+ __| Venue |__|_| Address | | |___________| | |_______________+ +--------------+ | | _| Name | | | +---------------+ | |______________| | |_| Licensor |__| | | |_______________| | +--------------+ | | |_| Address | | | +---------------+ |______________| | |_| License | | |_______________| +---------+ | | Session | -| |_________| | | +---------------+ | __| Configuration | | | |_______________| | | | +-----------+ | +---------------+ +--------------+ |_| Survey |__|_| Survey |____| Sensor |__ | | Device | | Sensors | |______________| | |___________| |_______________| | | +--------------+ | __| Ground Truth |__ | | |______________| | | | +-----------+ +---------------+ | +--------------+ +-| Survey |____| Survey Point |__|_| Beacons |__ |___________| |_______________| | |______________| | | +--------------+ |_| Measurements |__ |______________| Document structure overview. Figure 1 5. Using PIDF-LO Location All location information in this container is specified using the GEOPRIV Presence Information Data Format Location Object. This Jones & Steger Expires November 10, 2013 [Page 9] Internet-Draft Signal Position Survey May 2013 includes the basic definition of the PIDF-LO [RFC4119] object, PIDF- LO Clarification [RFC5491], Revised Civic Location Format [RFC5139], Dynamic Extensions to PIDF-LO [RFC5962], PIDF-LO Relative Location [I-D.ietf-geopriv-relative-location], and Civic Address Extensions [RFC6848]. The PIDF-LO object provides a variety of mechanisms to indicate position. This may refer to the location of the venue, the location of a beacon or the location of the survey device itself. Several of the capabilities of the PIDF-LO object are discussed in this section. For a full specifications refer to the relevant RFCs and Internet Drafts. The PIDF-LO object allows for specification of elements that encompass: o Position o Timestamp o Provider o Uncertainty o Bearing o Speed o Orientation For purposes of signal positioning survey, we define several classes of PIDF-LO objects: o Manual geolocation - human manipulation or specification of a geolocation o Integrated geolocation - system generated geolocation (e.g. via GPS) o Relative location - geolocation based on a defined reference point Each of these methods of providing location can be encoded within the constructs provided by the PIDF-LO structure when combined with the necessary extensions mentioned above and described in more detail in subsequent sections. 5.1. Device Orientation Jones & Steger Expires November 10, 2013 [Page 10] Internet-Draft Signal Position Survey May 2013 The optional orientation elements allows the surveyor to provide precise information with respect to the orientation of the scanning device at the time the readings were made. This orientation information can be used to differentiate signal information when the device is held at different angles at each survey point. From the "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)" [RFC5962], we find: "The element describes the spatial orientation of the presentity -- the direction that the object is pointing. For a device, this orientation might depend on the type of device." This proposed extension to the PIDF-LO object allows for the inclusion of device orientation within each PIDF-LO object. An example specifying device orientation: -3 12 24 278 gps 2009-06-22T20:57:29Z mac:1234567890ab Jones & Steger Expires November 10, 2013 [Page 11] Internet-Draft Signal Position Survey May 2013 6. Session The session element creates a container for the other elements of the survey. There should be a single survey per document. The session tag includes two required attributes: the sessionID and the sessionDate. SessionID: contains an opaque string which provides a Universally Unique Identifier (UUID) identifier for this survey as defined by RFC4122 [RFC4122]A Universally Unique IDentifier (UUID) URN Namespace. SessionDate: contains the date the survey was completed. ... 6.1. Venue The venue section describes the venue itself and also provides for two additional elements: the definition of the licensor and the definition of the policy for the included data. +----------------+ | Venue xCard | __| Name/Address | | |________________| | +-----------+ | +----------------+ | Venue |__|_| Licensor xCard | |___________| | | Name/Address | | |________________| | | +----------------+ |_| License | | |________________| | | +----------------+ |_| Map Metadata | |________________| Venue structure overview. Figure 2 Jones & Steger Expires November 10, 2013 [Page 12] Internet-Draft Signal Position Survey May 2013 The venue section of the document provides for the ability to identify the venue in which the survey took place as well as the location of the venue. 6.1.1. Venue Name/Address This optional element provides the ability to specify the name and address of the venue for identification purposes. This element uses the xCard [RFC6351] XML format to provide the necessary structure for these elements. Example Building work Example Building 1 South Boston Street Boston, MA USA 02210 1 South Boston Street Boston MAs 02210 USA 6.1.2. Licensor The optional licensor section allows for the definition of the organization or individual that has the right to grant another individual or entity a license to the data. The licensor section also makes use of the xCard [RFC6351] format for encoding information about the name and address of the licensor entity. Robert Builder Builder Jones & Steger Expires November 10, 2013 [Page 13] Internet-Draft Signal Position Survey May 2013 Robert work Robert Builder 1 South Boston Street Boston, MA USA 02210 1 South Boston Street Boston MA 02210 USA work voice tel:+1-555-555-1212;ext=102 work robert.builder@example.com 6.1.3. Data Rights Management The license object allows the licensor the ability to manage and grant usage rights to the survey data. This document includes a mechanism for including licensing terms. The licensing models are described in more detail below. The object is optional. If missing, the license type is assumed to be 'unrestricted' with a default expiration. Jones & Steger Expires November 10, 2013 [Page 14] Internet-Draft Signal Position Survey May 2013 6.1.3.1. License Expiry The optional License Expiry tag allows the surveyor to set time limits on the usage granted by the License Type. By default the data license expires 30 days after the date identified in the sessionDate. 2008-04-29T14:33:58 6.1.3.2. License URI The License URI provides an optional element to identify the terms of a 'Private' license type. This allows the incorporation of additional information relating to the definition of the license terms. 6.1.3.3. License Type The optional policy element is intended to allow the licensor of the data gathered for a given venue to provide granular control over the use and subsequent derivative works based on the data. In the event that no policy is specified, it is assumed that the data is released using the unrestricted policy. There are eight pre-defined Data License Types grouped into three categories. 6.1.3.3.1. Unrestricted License The unrestricted policy allows for the use and unrestricted derivative products based on the data set. If the data expires, the original data can no longer be used, but any derivative products that were generated during the granted use of the data remain valid. Example of an unrestricted license delcaration: 2008-04-29T14:33:58 unrestricted 6.1.3.3.2. Creative Commons License The Creative Commons [CC] provide a number of licensing options which, in some cases, permit the licensor of the data to restrict commercial use and/or derivative works. Derivative use of survey data refers to the ability to build or improve a location system based on survey data. Survey data at a high quality could be used to Jones & Steger Expires November 10, 2013 [Page 15] Internet-Draft Signal Position Survey May 2013 'seed' a location system, allowing an organization to bootstrap a location database over time. At some point, the original data could be removed but the derived database would allow the system to continue to be functional. For data licensors who wish to protect from this, the notion of derivative rights is included in the license structure. Valid Creative Common license types for this specification include the following. For non-commercial use: o Attribution-NonCommercial-ShareAlike CC BY-NC-SA - This license lets others remix, tweak, and build upon the licensor's work non- commercially, as long as they credit the licensor and license their new creations under the identical terms. o Attribution-NonCommercial CC BY-NC - This license lets others remix, tweak, and build upon the licensor's work non-commercially, and although their new works must also acknowledge the licensor and be non-commercial, they don't have to license their derivative works on the same terms. o Attribution-NonCommercial-NoDerivs CC BY-NC-ND - This license only allows others to use the licensor's works and share them with others as long as they credit the licensor, but they can't change them in any way or use them commercially. For commercial use: o Attribution CC BY - This license lets others distribute, remix, tweak, and build upon the licensor's work, even commercially, as long as they credit the licensor for the original creation. o Attribution-NoDerivs CC BY-ND - This license allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to the licensor. o Attribution-ShareAlike CC BY-SA - This license lets others remix, tweak, and build upon the licensor's work even for commercial purposes, as long as they credit the licensor and license their new creations under the identical terms. 2008-04-29T14:33:58 CC BY-ND Jones & Steger Expires November 10, 2013 [Page 16] Internet-Draft Signal Position Survey May 2013 6.1.3.3.3. Private License The private license is intended to provide full control over the usage and derivative usage of the data. Any use of the data would be governed under a separate agreement between the licensor and the party wishing to make use of the data. By default, no rights are granted for private data. For example, suppose a venue owner wishes to provide location services within their venue, but only for their own application. The arrangment for providing this service could be managed separately from the protocol. However, the data itself is fully transportable and allows for the venue owner to reprovision the service with a different provider if they so desire. Service providers without an arrangement could automatically determine that this data cannot be used. private http://www.example.com/mylicense.html 2008-04-29T14:33:58 6.1.4. Map Metadata The optional "map" URL can be used to provide a user or system with a visual reference for the location information. This URL specification is based on that provided in Section 4.11 of PIDF-LO Relative Location [I-D.ietf-geopriv-relative-location] specification. For purposes of the overall Venue map, the offset SHOULD provide the offset to the starting location on the map for the survey. http://example.com/map.jpg 200 210 68 2.90 -2.90 Jones & Steger Expires November 10, 2013 [Page 17] Internet-Draft Signal Position Survey May 2013 6.2. Survey Device The specification includes elements to describe the capabilities of the hardware and software of the scanning device as well as the hardware and software for the sensors that were used to capture the scan data. This can allow further downstream processing by discriminating source data based on capabilities and known device/ sensor profiles and behaviors. The Survey Device section SHOULD contain one device configuration record. It MAY contain 0-n sensor configuration elements. _+-------------+ +-----------------+ | | Hardware |____|| Configuration || | |_____________| ||_______________|| | |_+-------------+ +-----------------+ | | Software |____|| Configuration || | |_____________| ||_______________|| +---------+ | | Survey |__| | Device | | |_________| | +-------------+ +-------------+ +-----------------+ |_| Sensor (0-n)|____| Hardware |___|| Configuration || |_____________| | |_____________| ||_______________|| | | +-------------+ +-----------------+ |_| Software |___|| Configuration || |_____________| ||_______________|| Survey Device structure overview. Figure 3 6.2.1. Configuration Object +-----------------+ __| Type | | |_________________| | | +-----------------+ |_| Id | | |_________________| | | +-----------------+ |_| Name | | |_________________| Jones & Steger Expires November 10, 2013 [Page 18] Internet-Draft Signal Position Survey May 2013 +-----------------+ | | Configuration |__| +-----------------+ |_________________| |_| Manufacturer | | |_________________| | | +-----------------+ |_| Model | | |_________________| | | +-----------------+ |_| Version | | |_________________| | | +-----------------+ |_| Vendor | | |_________________| | | +-----------------+ |_| Capability | |_________________| Survey Device Configuration structure overview. Figure 4 The configuration object allows for the description of a various hardware components used to perform the survey. This allows for the description of the survey device itself as well as any sensors or radio components that are used in performing the survey. The configuration object can contain various elements as described below. Required items are noted. o id - (required) - provides a locally unique identifier for the component being described. For example, this could be the MAC address if describing a WiFi Network Interface Card. o name - (required) - the name of the device/sensor o vendor - (0-1) - a human readable description of the component vendor o model - (0-1) -the model and model number of the component o capability - (0-n) - a name/value pair to allow arbitrary configuration and capability declarations for each configuration object. Jones & Steger Expires November 10, 2013 [Page 19] Internet-Draft Signal Position Survey May 2013 6.2.2. Example Device Configuration An example object is shown below. device mapit 1.2 abc 900 Intel Q965 12 volt software Centos6 2.6.18-308.1.1.el5 #1 SMP x86_64 GNU 000FFA9870BC External WiFi 1.23 atheros omni-directional 10 atheros a,b,g,n 1-13 atheros driver ath9k Jones & Steger Expires November 10, 2013 [Page 20] Internet-Draft Signal Position Survey May 2013 gps gm39211 4.23a unknown combined qualcomm 6.3. Survey Data The survey section represents all of the scanned or input data gathered about the venue in this session. Within a 'survey', there may be 0-n 'readings' which will contain a complete set of information about a subset of the survey. For example, a single room could be captured within a 'readings' segment. This document defines location-related measurement data types for a range of common sensor types. All included measurement data definitions allow for arbitrary extension in the corresponding schema. As new parameters that are applicable to location determination are added, these can be added as new XML elements in a unique namespace. Though many of the underlying protocols support extension, creation of specific XML- based extensions to the measurement format is favored over accommodating protocol-specific extensions in generic containers. Note, the "time" attribute records the time that the measurement or observation was made. This time can be different from the time that the measurement information was reported. Time information can be used to populate a timestamp on each ground truth element and to the root "measurement" element. If it is necessary to provide multiple sets of measurement data with different times, multiple "measurement" elements SHOULD be provided. +--------------+ __| Ground Truth |__ | |______________| | +-------------+ +---------------+ | +--------------+ -| Survey Data |___| Survey Point |__|_| Beacons |__ Jones & Steger Expires November 10, 2013 [Page 21] Internet-Draft Signal Position Survey May 2013 |_____________| |_______________| | |______________| | | +--------------+ |_| Measurements |__ |______________| Document structure overview. Figure 5 Survey Points describe a subset of the survey information and potentially include Ground Truth, Beacon IDs, and Signal Measurements. These categories of information are detailed further in the following sections. 6.3.1. Ground Truth Ground truth is a term that describes the location of the Survey Device. The 'ground truth' element is designed to allow the specification and recording of the location at which the survey point was captured. To encompass various survey and usage scenarios, there are currently three GroundTruth types available for each survey point. These include PIDF-LO location object, a Contextual Location object, and/or a Raw Location object. These are described further below. Multiple Ground Truth objects are allowed for interpolation between a starting point and an endpoint without explicitly declaring each scan position. The interpolation of the survey data is left to the downstream processor such as an LIS server. groundTruth MUST have at least 1 SurveyPoint object as defined below. +----------------+ +----------+ _| Basic Location |- -| Civic | | |________________| | Location | +-------------+ | |__________| | GroundTruth |___| +----------------+ |_____________| |_| Raw Location | | Data | |________________| Groundtruth structure overview. Figure 6 Jones & Steger Expires November 10, 2013 [Page 22] Internet-Draft Signal Position Survey May 2013 6.3.1.1. PIDF-LO Location This section describes the primary PIDF-LO method types that are supported by this specification. While all PIDF-LO location 'methods' are possible, the following are the only methods that MUST be supported. o GPS o A-GPS o Trilateration o Cell o Manual In addition, support MUST be provided for relative locations as described below for each of the above PIDF-LO location methods. 6.3.1.1.1. Basic Location Basic location represents a location as provided by the Survey Device. This could be from a location API, WiFi positioning, an integrated GPS, or any other mechanism that computes or determines the location of the survey device. To encompass this variety of locative technologies, the structure of the object provides numerous constructs. An example of an integrated GPS location including dynamic orientation extensions is shown below. More examples of encodings can be found in PIDF-LO Usage [RFC5491]. 42.5463 -73.2512 26.3 7.7156 Jones & Steger Expires November 10, 2013 [Page 23] Internet-Draft Signal Position Survey May 2013 3.31 28.7 90 -3 12 24 278 gps 2009-06-22T20:57:29Z 6.3.1.1.2. Relative Location A relative location is based on the topology of the venue and is specified by first declaring one or more anchors that contain a geospatial reference. Relative Location MUST be defined using "Internet Draft Relative Location Representation" [I-D.ietf-geopriv-relative-location]. An example of a PIDF-LO geopriv object with relative location extensions included is shown below. Jones & Steger Expires November 10, 2013 [Page 24] Internet-Draft Signal Position Survey May 2013 -34.407 150.883 50.0 -34.407 150.883 500.0 750.0 5.0 https://www.example.com/flrpln/123South/flr-2 2670.0 1124.0 1022.0 67.00 10 Triangulation 2007-06-22T20:57:29Z 6.3.1.1.3. Manual Location The manual location object allows the surveyor to specify the geospatial coordinate and/or a civic address to be associated with the 'readings' data. This element contains any valid location, using the rules for a "location-info" element, as described in RFC 5491 [RFC5491]. Jones & Steger Expires November 10, 2013 [Page 25] Internet-Draft Signal Position Survey May 2013 Location information in a survey may be described in a geospatial manner based on a subset of Geography Markup Language (GML) 3.1.1 [OGC-GML3.1.1] or as civic location information RFC 5139 [RFC5139] and refined in RFC 5774 [RFC5774]. An OGC GML [OGC-GML3.1.1] profile for expressing geodetic shapes in a PIDF-LO is described in GML GeoShape Application Schema [GeoShape]. Below are several examples of manual location objects. -43.5723 153.21760 2007-06-22T20:57:29Z Sample manual location using a point. 42.5463 -73.2512 5.24 Jones & Steger Expires November 10, 2013 [Page 26] Internet-Draft Signal Position Survey May 2013 2007-06-22T20:57:29Z Sample manual location using a circle with a radius to represent error estimate. 6.3.1.1.4. Civic Location To support adding contextual information to survey points during the survey process, this specification includes the ability to add extended civic addresses as defined by the optional Contextual Location object. This object enables the capture of contextual information with resepect to a survey point. For example, an office building may have floors, wings, rooms, and cubes while an amusement park will have rides, booths, food stands and arcades. The civic address extensions provide a mechanism for extending these attributes and maintaining interoperability. Example of civic location: -43.5723 153.21760 US CA 2471 AQ-374-4(c) LAX Jones & Steger Expires November 10, 2013 [Page 27] Internet-Draft Signal Position Survey May 2013 Tom Bradley G 36B 2007-06-22T20:57:29Z The optional civicAddress object can be included in any of the PIDF- LO objects defined above. 6.3.1.2. Raw Location Data To support the capture and conveyance of underlying raw location data, a common optional container is defined for the expression of this location measurement data. Currently only the 'GNSS' raw location type has been defined. Global Navigation Satellite System (GNSS) readings provide location measurements based on satellite navigation systems such as that provided by GPS. Rather than decomposing GNSS output during the survey, the sentences from the GNSS systems are transported as is allowing full downstream processing of the data. The type attribute specifies the GNSS system type which is responsible for the reading, e.g. GPS. The GPS system generally uses the NMEA 0183 [NMEA0183] protocol for output and many systems have been built to handle this type of output. To provide the most transparent transport mechanism, the NMEA sentences are packaged as-is. The possible sentence names are described below. The REQUIRED set of sentences include: $GPGGA - Global Positioning System Fix Data (required) $GPGSA - GPS DOP and Active Satellites (recommended) $GPRMC - Recommended Minimum Specific GPS/TRANSIT Data (recommended) The remaining OPTIONAL sentences are detailed below: Jones & Steger Expires November 10, 2013 [Page 28] Internet-Draft Signal Position Survey May 2013 $GPAAM - Waypoint Arrival Alarm $GPALM - GPS Almanac Data< $GPAPA - Autopilot Sentence "A" $GPAPB - Autopilot Sentence "B" $GPASD - Autopilot System Data $GPBEC - Bearing & Distance to Waypoint, Dead Reckoning $GPBOD - Bearing, Origin to Destination $GPBWC - Bearing & Distance to Waypoint, Great Circle $GPBWR - Bearing & Distance to Waypoint, Rhumb Line $GPBWW - Bearing, Waypoint to Waypoint $GPDBT - Depth Below Transducer $GPDCN - Decca Position $GPDPT - Depth $GPFSI - Frequency Set Information $GPGLC - Geographic Position, Loran-C $GPGLL - Geographic Position, Latitude/Longitude $GPGSV - GPS Satellites in View $GPGXA - TRANSIT Position $GPHDG - Heading, Deviation & Variation $GPHDT - Heading, True $GPHSC - Heading Steering Command $GPLCD - Loran-C Signal Data $GPMTA - Air Temperature (to be phased out) $GPMTW - Water Temperature $GPMWD - Wind Direction $GPMWV - Wind Speed and Angle $GPOLN - Omega Lane Numbers $GPOSD - Own Ship Data $GPR00 - Waypoint active route (not standard) $GPRMA - Recommended Minimum Specific Loran-C Data $GPRMB - Recommended Minimum Navigation Information $GPROT - Rate of Turn $GPRPM - Revolutions $GPRSA - Rudder Sensor Angle $GPRSD - RADAR System Data $GPRTE - Routes $GPSFI - Scanning Frequency Information $GPSTN - Multiple Data ID $GPTRF - Transit Fix Data $GPTTM - Tracked Target Message $GPVBW - Dual Ground/Water Speed $GPVDR - Set and Drift $GPVHW - Water Speed and Heading $GPVLW - Distance Traveled through the Water $GPVPW - Speed, Measured Parallel to Wind $GPVTG - Track Made Good and Ground Speed $GPWCV - Waypoint Closure Velocity $GPWNC - Distance, Waypoint to Waypoint Jones & Steger Expires November 10, 2013 [Page 29] Internet-Draft Signal Position Survey May 2013 $GPWPL - Waypoint Location $GPXDR - Transducer Measurements $GPXTE - Cross-Track Error, Measured $GPXTR - Cross-Track Error, Dead Reckoning $GPZDA - Time & Date $GPZFO - UTC & Time from Origin Waypoint $GPZTG - UTC & Time to Destination Waypoint The sentences contain the name of the sentence in the content so there is no reason to add additional identifying information beyond the sentence itself. The GPS configuration may optionally be detailed in the device sensor descriptions section. Example: GPGGA $GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76 GPGSA $GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A GPSV $GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70 GPSV $GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79 GPRMC $GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43 Jones & Steger Expires November 10, 2013 [Page 30] Internet-Draft Signal Position Survey May 2013 6.3.2. Beacons The intent of the object is to allow the surveyor to identify individual beacons and specify the location of that beacon. In other words, in a site survey where beacon A is located at x1, y1 and beacon B is located at x2, y2, this construct would allow for that. This is for those instances where exact beacon position is useful for the LIS to compute device locations. Beacon Identification The beacon object allows the identification of a specific set of beacons. A beacon is specified as an object to be used for positioning which can be identified by a unique identifier. For example in an Infrastructure WiFi network, the basic service set identifier (bssid) is the 48 bit MAC address of the access point. This specification allows for the possibility of manually identifying beacons and including that information in the survey. The type attribute is required. 003200A475C5 The elements include: o id (required) - indicates the key(s) necessary to uniquely identify the beacon of the given type 6.3.3. Signal Measurements Signal-Related Measurement Data Types A common container is defined for the expression of location measurement data, as well as a simple means of identifying specific types of measurement data for the purposes of requesting them. The following example shows a measurement container with measurement time included. A WiFi measurement is enclosed. Jones & Steger Expires November 10, 2013 [Page 31] Internet-Draft Signal Position Survey May 2013 00-12-F0-A0-80-EF wlan-home The "measurement" element is used to encapsulate measurement data that is collected at a certain point in time. It contains time-based attributes that are common to all forms of measurement data, and permits the inclusion of arbitrary measurement data. 6.3.3.1. WiFi Measurements WiFi Measurements are based on the proposed measurements defined in the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements] document. In WiFi, or 802.11 [IEEE.80211.2007], networks a Device might be able to provide information about the access point (AP) that it is attached to, or other WiFi points it is able to see. This is provided using the "wifi" element, as shown in Figure 6, which shows a single complete measurement for a single access point. WiFi scan elements contain a single record for each Access Point which was scanned for each time stamp that that AP was scanned. APs should be scanned as rapidly as feasible to obtain as many samples as possible. Intel(r)PRO/Wireless 2200BG AB-CD-EF-AB-CD-EF example 5 -34.4 150.8 a/g 5 2 Jones & Steger Expires November 10, 2013 [Page 32] Internet-Draft Signal Position Survey May 2013 2 2.56e-9 23 5 -59 23 10 9 -98.5 7.5 802.11 WiFi Measurement Example A wifi element is made up of one or more access points, and an optional "nicType" element. Each access point is described using the "ap" element, which is comprised of the following fields: Required: o bssid: The basic service set identifier. In an Infrastructure BSS network, the bssid is the 48 bit MAC address of the access point. The "verified" attribute of this element describes whether the device has verified the MAC address or it authenticated the access point or the network operating the access point (for example, a captive portal accessed through the access point has been authenticated). This attributes defaults to a value of "false" when omitted. o rcpi: The received channel power indicator for the access point signal, as measured by the Device. This value SHOULD be in units of dBm (with RMS error in dB). If power is measured in a different fashion, the "dBm" attribute MUST be set to "false". Signal strength reporting on current hardware uses a range of different mechanisms; therefore, the value of the "nicType" element SHOULD be included if the units are not known to be in dBm and the value reported by the hardware should be included without modification. This element includes optional "rmsError" and "samples" attributes. Jones & Steger Expires November 10, 2013 [Page 33] Internet-Draft Signal Position Survey May 2013 Optional (as defined in the IETF I-D Held Measurements [I-D.ietf-geopriv-held-measurements] document. o ssid o channel o location o type o band o regclass o antenna o flightTime o apSignal 6.3.3.2. Bluetooth Measurements Note: these need to be clarified and added to held-measurements. Bluetooth devices provide an alternative method for determining location. The bluetooth object provides a method to capture measurements related to bluetooth devices discovered during the survey. o Address/UUID - 48-bit unique identifier o Name o Version o Manufacturer o Features o Class o Signal Strength o Link Quality 6.3.3.3. Other Signal Measurements Jones & Steger Expires November 10, 2013 [Page 34] Internet-Draft Signal Position Survey May 2013 The container allows for the definition of other measurements to be captured. These could include measurements of such things as sound ranging or echolocation signals, cellular signals, or other electromagnetic signal measurement. 7. XML Schema This section gives the XML Schema Definition [W3C.REC- xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the "application/held+xml" format. This is presented as a formal definition of the "application/sigpos+xml" format. Note that the XML Schema Definition is not intended to be used with on-the-fly validation of the presence XML document. Whitespaces are included in the schema to conform to the line length restrictions of the RFC format without having a negative impact on the readability of the document. Any conforming processor should remove leading and trailing white spaces. The XML schema depicted below supports the Beacon Location mode of SigPos Survey data only. This document defines SigPos messages. (draft-jones-geopriv-sigpos-survey) Jones & Steger Expires November 10, 2013 [Page 35] Internet-Draft Signal Position Survey May 2013 Jones & Steger Expires November 10, 2013 [Page 36] Internet-Draft Signal Position Survey May 2013 Jones & Steger Expires November 10, 2013 [Page 38] Internet-Draft Signal Position Survey May 2013 SigPos Partial XML Schema Jones & Steger Expires November 10, 2013 [Page 39] Internet-Draft Signal Position Survey May 2013 8. Security Considerations Location-related measurement data can be as privacy sensitive as location information. Survey data is effectively equivalent to location information if the contextual knowledge necessary to generate one from the other is readily accessible. Even where contextual knowledge is difficult to acquire, there can be no assurance that an authorized recipient of the contextual knowledge is also authorized to receive location information. In order to protect the privacy of the subject of location-related survey data, this implies that survey data is protected with a similar degree of protection as location information. Survey Data Privacy Model In general, survey data represents a smaller privacy risk than personal location information. It does however represent potential privacy risks especially with respect to venues which have security risks or wish to maintain control over the exposure of detailed location information. No entity is permitted to redistribute survey data except as specified in the data license. The Device directs other entities in how survey data is used and retained. 8.1. Assuring That the Proper LIS Has Been Contacted Jones & Steger Expires November 10, 2013 [Page 40] Internet-Draft Signal Position Survey May 2013 This document assumes that the LIS to be contacted is identified either by an IP address or a domain name, as is the case for a LIS discovered as described in LIS Discovery [RFC5986]. As the SigPos transaction is conducted using TLS [RFC5246], the LIS can authenticate its identity, either as a domain name or as an IP address, to the client by presenting a certificate containing that identifier as a subjectAltName (i.e., as an iPAddress or dNSName, respectively). In the case of the HTTP binding described above, this is exactly the authentication described by TLS [RFC2818]. If the client has external information as to the expected identity or credentials of the proper LIS (e.g., a certificate fingerprint), these checks MAY be omitted. Any binding of SigPos MUST be capable of being transacted over TLS so that the client can request the above authentication, and a LIS implementation for a binding MUST include this feature. Note that in order for the presented certificate to be valid at the client, the client must be able to validate the certificate. In particular, the validation path of the certificate must end in one of the client's trust anchors, even if that trust anchor is the LIS certificate itself. 8.2. Protecting Responses from Modification In order to prevent a response from being modified en route, messages must be transmitted over an integrity-protected channel. When the transaction is being conducted over TLS (a required feature per Section 11.1), the channel will be integrity protected by appropriate ciphersuites. When TLS is not used, this protection will vary depending on the binding; in most cases, without protection from TLS, the response will not be protected from modification en route. 9. Examples The following sections provide examples of basic HTTP/HTTPS, a simple location request, and a location request for multiple location types, along with the relevant location responses. To focus on important portions of messages, the examples in Sections 10.2 and 10.3 do not show HTTP/HTTPS headers or the XML prologue. In addition, sections of XML not relevant to the example are replaced with comments. 9.1. Example of a WiFi Access Point Location Survey The examples in this section show example HTTPS messages that include the SigPos submission or response document. POST /location HTTP/1.1 Host: sigpos.example.com:49152 Content-Type: application/sigpos+xml;charset=utf-8 Content-Length: nnn Jones & Steger Expires November 10, 2013 [Page 41] Internet-Draft Signal Position Survey May 2013 A simple example of a small survey composed of two survey points is illustrated by the example message below. This uses the static beacon key survey model. Example Building work Example Building 1 South Boston Street Boston, MA USA 02210 1 South Boston Street Boston MA 02210 USA Rober Builder Builder Robert Jones & Steger Expires November 10, 2013 [Page 42] Internet-Draft Signal Position Survey May 2013 work Rober Builder 1 South Boston Street Boston, MA USA 02210 1 South Boston Street Boston MA 02210 USA work voice tel:+1-555-555-1212;ext=102 work reober.builder@example.com CC BY -34.4 150.8 US Jones & Steger Expires November 10, 2013 [Page 43] Internet-Draft Signal Position Survey May 2013 CA LAX Tom Bradley G 36B 2012-02-21T14:33:58:05 FF00FF723CBA FF00FF723CBB -34.35 150.83 2012-02-21T14:33:58:06 FF00FF723A00 802.11 WiFi Beacon Survey Jones & Steger Expires November 10, 2013 [Page 44] Internet-Draft Signal Position Survey May 2013 9.2. Example of a WiFi Signal Survey A simple example of wifi scan data conveyance using gps for ground truth is illustrated by the example message below. Example Building work Example Building 1 South Boston Street Boston, MA USA 02210 1 South Boston Street Boston MA 02210 USA Rober Builder Builder Robert work Jones & Steger Expires November 10, 2013 [Page 45] Internet-Draft Signal Position Survey May 2013 Rober Builder 1 South Boston Street Boston, MA USA 02210 1 South Boston Street Boston MA 02210 USA work voice tel:+1-555-555-1212;ext=102 work reober.builder@example.com unrestricted 2012-10-29T14:33:58 00EFDA7200B004 lumina smartphone 900 1.2 wifi ath0 omni-directional aetheros Jones & Steger Expires November 10, 2013 [Page 46] Internet-Draft Signal Position Survey May 2013 newco a,b,g,n 1-13 gps gps3210 combined qualcomm newco standard -34.35 150.83 2012-02-21T14:33:58:06 GPGGA $GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76 GPGSA $GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A Jones & Steger Expires November 10, 2013 [Page 47] Internet-Draft Signal Position Survey May 2013 GPSV $GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70 GPSV $GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79 GPRMC $GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43 00-12-F0-A0-80-EF wlan-home -85 00-11-F0-A0-80-EF wlan-other -92 802.11 WiFi Signal Scan Survey 10. Acknowledgements This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project. Thanks to Richard Barnes and Stephane Terrenoir, Adam Roach, Robin Wilton, and Martin Thompson for initial reviews and valuable feedback. Jones & Steger Expires November 10, 2013 [Page 48] Internet-Draft Signal Position Survey May 2013 11. IANA Considerations This section creates a registry for Data License types (Section 6.1.3.3) and registers the namesapces and schema defined in the Schemas (Section 7) secction. 11.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:sigpos This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:sigpos", per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:geopriv:sigpos Registrant Contact: IETF, . XML BEGIN SigPos Messages

Namespace for SigPos Messages

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

See draft-jones-geopriv-sigpos-survey

END 11.2. XML Schema Registration This section registers an XML schema as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:geopriv:sigpos Registrant Contact: IETF, . Schema: The XML for this schema can be found as the entirety of Section 9 of this document. Jones & Steger Expires November 10, 2013 [Page 49] Internet-Draft Signal Position Survey May 2013 11.3. MIME Media Type Registration for 'application/sigpos+xml' This section registers the "application/sigpos+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/sigpos+xml MIME media type name: application MIME subtype name: sigpos+xml Required parameters: (none) Optional parameters: charset Same as the charset parameter of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. Encoding considerations: Same as the encoding considerations of "application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. Security considerations: This content type is designed to carry protocol data related to the location of signal beacons, which could include information that is considered private. Appropriate precautions should be taken to limit disclosure of this information. Interoperability considerations: This content type provides a basis for a protocol. There are multiple interoperable implementations of this protocol. Published specification: Applications which use this media type: Location information surveyors and service providers. Additional Information: Magic Number(s): (none) File extension(s): .heldxml Macintosh File Type Code(s): "TEXT" Person & email address to contact for further information: Mary Barnes Intended usage: LIMITED USE Jones & Steger Expires November 10, 2013 [Page 50] Internet-Draft Signal Position Survey May 2013 Author/Change controller: The IETF Other information: This media type is a specialization of application /xml [RFC3023], and many of the considerations described there also apply to application/held+xml. 11.4. IANA Registry for Data License Types This document establishes a new IANA registry for the for Data License types (Section 6.1.3.3). This reegistry includes tokens for the Data License type. Referring to the [RFC5226], this registry operates under "Specification Required" rules. The IESG will appoint an Expert Review who will advice IANA promptly on each request for a new or updated Data License type. Each entry in the registry requires the following information: o Data License name: the name of the data license o Brief Description: a brief description of the data license o URI: optional URI to the license definition This section pre-registers 8 new 'licenseType' tokens associated with the 'licenseType' 1. unrestricted: this license allows for the use and unrestricted derivative products based on the data set 2. CC BY: this license lets others distribute, remix, tweak, and build upon your work, even commercially, as long as they credit you for the original creation. 3. CC BY-ND: this license allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to you. 4. CC BY-NC-SA: this license lets others remix, tweak, and build upon your work non-commercially, as long as they credit you and license their new creations under the identical terms. 5. CC BY-SA: this license lets others remix, tweak, and build upon your work even for commercial purposes, as long as they credit you and license their new creations under the identical terms. 6. CC BY-NC: this license lets others remix, tweak, and build upon your work even for commercial purposes, as long as they credit you and license their new creations under the identical terms. Jones & Steger Expires November 10, 2013 [Page 51] Internet-Draft Signal Position Survey May 2013 7. CC BY-NC-ND: this license is the most restrictive of our six main licenses, only allowing others to download your works and share them with others as long as they credit you, but they can't change them in any way or use them commercially. 8. private: this license is intended to provide full control over the usage and derivative usage of the data. Any use of the data would be governed under a separate agreement between the licensor and the party wishing to make use of the data. By default, no rights are granted for private data. 12. References 12.1. Normative References [I-D.ietf-geopriv-held-measurements] Thomson, M. and J. Winterbottom, "Using Device-provided Location-Related Measurements in Location Configuration Protocols", draft-ietf-geopriv-held-measurements-07 (work in progress), April 2013. [I-D.ietf-geopriv-relative-location] Thomson, M., Rosen, B., Stanley, D., Bajko, G., and A. Thomson, "Relative Location Representation", draft-ietf- geopriv-relative-location-04 (work in progress), March 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence, S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. Jones & Steger Expires November 10, 2013 [Page 52] Internet-Draft Signal Position Survey May 2013 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)", RFC 5139, February 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009. [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010. [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010. [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, August 2011. [RFC6848] Winterbottom, J., Thomson, M., Barnes, R., Rosen, B., and R. George, "Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF- LO)", RFC 6848, January 2013. 12.2. Informative References [CC] Creative Commons, "Creative Commons LIcenses", 2012, . [GeoShape] , "GML GeoShape Application Schema for use in internet standards developed by the IETF", 2006, . [IEEE.80211.2007] , "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", 2007, . [NMEA0183] Jones & Steger Expires November 10, 2013 [Page 53] Internet-Draft Signal Position Survey May 2013 , "NMEA 0183", 2007, . [OGC-GML3.1.1] , "Geography Markup Language (GML) 3.1.1", 2003, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5774] Wolf, K. and A. Mayrhofer, "Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition", BCP 154, RFC 5774, March 2010. Authors' Addresses Kipp Jones Skyhook Wireless 34 Farnsworth Street Boston 02210 US Phone: +1 (617) 314-9802 Email: kjones@skyhookwireless.com Christopher Steger Skyhook Wireless 34 Farnsworth Street Boston US Phone: +1 (617) 314-9802 Email: csteger@skyhookwireless.com Jones & Steger Expires November 10, 2013 [Page 54]