RFC 7105
Using Device-Provided Location-Related Measurements in Location Configuration Protocols
Part 1 of 14 🎀
Using Device-Provided Location-Related Measurements in Location Configuration Protocols 💖
Okay bestie, this is RFC 7105 and it is literally giving main character energy 🦋. It's an IETF Request for Comments, published in January 2014, and the category is Standards Track ✨. The authors are M. Thomson (Mozilla) and J. Winterbottom (Unaffiliated). It's ISSN 2070-1721 🌸. The title block doesn't list anything it obsoletes or updates, so this one stands on its own 💅.
Abstract
Okay so the big idea is this: a Device can send location-related measurement data to a Location Information Server (LIS) inside a request for location info 🧚. These measurements are observations about stuff that relates to where the Device is, like its network attachment or its physical surroundings 🌈. The LIS can use that data to make its location estimate more accurate for the Device 🎯. The doc defines a basic set of these measurements, including common kinds of network attachment and assisted GNSS parameters 🛰️. Not me being obsessed with this already 😭🫶
Status of This Memo
Okay this part is the official paperwork, but I'll keep it real 💅. This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check Section 2 of RFC 5741 📚.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7105 🌸.
Copyright Notice
Copyright (c) 2014 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) as they were on the date of publication 📜. Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🍓.
Table of Contents
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Location-Related Measurements in LCPs ...........................6
4. Location-Related Measurement Data Types .........................7
4.1. Measurement Container ......................................7
4.1.1. Time of Measurement .................................8
4.1.2. Expiry Time on Location-Related Measurement Data ....8
4.2. RMS Error and Number of Samples ............................9
4.2.1. Time RMS Error ......................................9
4.3. Measurement Request .......................................10
4.4. Identifying Location Provenance ...........................11
5. Location-Related Measurement Data Types ........................13
5.1. LLDP Measurements .........................................13
5.2. DHCP Relay Agent Information Measurements .................14
5.3. 802.11 WLAN Measurements ..................................15
5.3.1. WiFi Measurement Requests ..........................18
5.4. Cellular Measurements .....................................18
5.4.1. Cellular Measurement Requests ......................22
5.5. GNSS Measurements .........................................22
5.5.1. GNSS: System Type and Signal .......................23
5.5.2. Time ...............................................24
5.5.3. Per-Satellite Measurement Data .....................24
5.5.4. GNSS Measurement Requests ..........................25
5.6. DSL Measurements ..........................................25
5.6.1. L2TP Measurements ..................................26
5.6.2. RADIUS Measurements ................................26
5.6.3. Ethernet VLAN Tag Measurements .....................27
5.6.4. ATM Virtual Circuit Measurements ...................28
6. Privacy Considerations .........................................28
6.1. Measurement Data Privacy Model ............................28
6.2. LIS Privacy Requirements ..................................29
6.3. Measurement Data and Location URIs ........................29
6.4. Measurement Data Provided by a Third Party ................30
7. Security Considerations ........................................30
7.1. Threat Model ..............................................30
7.1.1. Acquiring Location Information without
Authorization ......................................31
7.1.2. Extracting Network Topology Data ...................32
7.1.3. Exposing Network Topology Data .....................32
7.1.4. Lying by Proxy .....................................33
7.1.5. Measurement Replay .................................33
7.1.6. Environment Spoofing ...............................34
7.2. Mitigation ................................................35
7.2.1. Measurement Validation .............................36
7.2.1.1. Effectiveness .............................36
7.2.1.2. Limitations (Unique Observer) .............37
7.2.2. Location Validation ................................38
7.2.2.1. Effectiveness .............................38
7.2.2.2. Limitations ...............................39
7.2.3. Supporting Observations ............................39
7.2.3.1. Effectiveness .............................40
7.2.3.2. Limitations ...............................40
7.2.4. Attribution ........................................40
7.2.5. Stateful Correlation of Location Requests ..........42
7.3. An Unauthorized or Compromised LIS ........................42
8. Measurement Schemas ............................................42
8.1. Measurement Container Schema ..............................43
8.2. Measurement Source Schema .................................45
8.3. Base Types Schema .........................................46
8.4. LLDP Measurement Schema ...................................49
8.5. DHCP Measurement Schema ...................................50
8.6. WiFi Measurement Schema ...................................51
8.7. Cellular Measurement Schema ...............................55
8.8. GNSS Measurement Schema ...................................57
8.9. DSL Measurement Schema ....................................59
9. IANA Considerations ............................................61
9.1. IANA Registry for GNSS Types ..............................61
9.2. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc ...............62
9.3. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm .........................63
9.4. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:basetypes ...............63
9.5. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:lldp ....................64
9.6. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dhcp ....................65
9.7. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:wifi ....................65
9.8. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:cell ....................66
9.9. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:gnss ....................67
9.10. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:lm:dsl ....................67
9.11. XML Schema Registration for Measurement Source Schema ....68
9.12. XML Schema Registration for Measurement Container
Schema ...................................................68
9.13. XML Schema Registration for Base Types Schema ............69
9.14. XML Schema Registration for LLDP Schema ..................69
9.15. XML Schema Registration for DHCP Schema ..................69
9.16. XML Schema Registration for WiFi Schema ..................69
9.17. XML Schema Registration for Cellular Schema ..............70
9.18. XML Schema Registration for GNSS Schema ..................70
9.19. XML Schema Registration for DSL Schema ...................70
10. Acknowledgements ..............................................70
11. References ....................................................71
11.1. Normative References .....................................71
11.2. Informative References ...................................731. Introduction ✨
Okay so a Location Configuration Protocol (LCP) is how a Device asks an access network for info about where it physically is 📍. The Location Information Server (LIS) is the server that actually hands that info back, because it knows about the network and the physical environment 🏠.
The LIS is part of the access network, so it can grab measurement results about the Device's location from network elements 🔌. It also knows the network topology, which is what lets it turn measurement data into an actual location 🗺️. And it can level up even more with info that comes straight from the Device itself 💅.
Here's the tea: a Device can make observations about its network attachment or its physical environment 👀. That location-related measurement data might be unavailable to the LIS. Or the LIS could get it, but it'd cost more in time or some other metric 🙈. Giving the LIS measurement data gives it more options for figuring out location, which can improve the service it provides 🌟. Better accuracy is one possible win, but faster response times and lower error rates are on the table too 🚀.
This document explains how a Device reports location-related measurement data to the LIS 🎀. The examples use the HTTP-Enabled Location Delivery (HELD) [RFC5985] location configuration protocol 💜.
2. Conventions Used in This Document ✨
okay so first things first, "LIS" and "Device" mean the same thing here as they do in [RFC5985] 💖 we're keeping it consistent bestie
this doc also has a few definitions you need to know 🎀
Location Measurement: an observation about the physical properties of a particular Device's position in time and space 🌸 the result of a location measurement (we call it "location-related measurement data", or just "measurement data" once the context is clear) can be used to figure out where a Device is. location-related measurement data doesn't directly identify a Device, though it could do so indirectly 👀 and measurement data can change over time if the Device moves too.
location-related measurement data doesn't always contain location info directly, but you can combine it with contextual knowledge and/or algorithms to derive location info. examples are radio signal strength or timing measurements, Ethernet switch identifiers, and port identifiers 🧚
location-related measurement data can be considered sighting information, based on the definition in [RFC3693] 💜
Location Estimate: an approximation of where the Device is located 📍 location estimates come from location measurements, and they're subject to uncertainty, which comes from errors in the measurement results. so yeah, they're never 100% perfect, periodt 💅
GNSS: Global Navigation Satellite System ✨ a satellite-based system that gives you positioning and time info, like the US Global Positioning System (GPS) or the European Galileo system 🛰️
and now the important part 🫶 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 [RFC2119] 🔥
3. Location-Related Measurements in LCPs 🌈
okay so this section is about a standard container for sending location-related measurement parameters inside location configuration protocols 💖 it's an XML container that identifies parameters by type, and it lets the Device share the results of any measurement it's able to perform. there's also a set of measurement schemas that can be carried in that generic container ✨
here's a simple example of measurement data in action 🎀 Figure 1 shows a HELD location request message with an Ethernet switch and port measurement taken using the Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] 💅
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">civic</locationType>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">0a01003c</chassis>
<port type="6">c2</port>
</lldp>
</measurements>
</locationRequest>
Figure 1: HELD Location Request with Measurement Datathis LIS is allowed to ignore measurement data it doesn't support or understand 🙈 the measurements defined in this document follow this rule: any extension that could cause backward incompatibility MUST be added as a new measurement definition, not as an extension to an existing type 🚫 no breaking the old stuff, bestie
you can include multiple sets of measurement data in the measurements element, whether they're the same type or from different sources 🍓 see Section 4.1.1 for details on repeating this element
a LIS can choose to use or ignore location-related measurement data when it's figuring out location, as long as the rules about use and retention (Section 6) are respected ⭐ the method parameter in the Presence Information Data Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to reflect the method used 🎯 a correct method helps location recipients judge the quality (both accuracy and integrity) of location info, though there could be reasons to hold back info about where the data came from 🤫
measurement data is typically only used to serve the request it came in with 💜 there may be exceptions, especially when it comes to location URIs, and Section 6 has more info on usage rules
location-related measurement data doesn't have to come only from Devices 🌸 a third-party location requester (for example, see [RFC6155]) can ask for location info using measurement data, as long as the requester is able to acquire the measurement data and is authorized to distribute it 🦋 there are specific privacy considerations for third parties using measurements, which Section 6.4 covers
location-related measurement data and its use come with a bunch of privacy and security challenges 😭 they're described in more detail in Sections 6 and 7, so go read those too
4. Location-Related Measurement Data Types 💖
okay so this section defines a common container for expressing location measurement data, plus a simple way to identify specific types of measurement data when you want to request them 🎀
the next example shows a measurement container with measurement time and expiration time included 🧚 a WiFi measurement is enclosed inside it ✨
<lm:measurements xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58"
expires="2008-04-29T17:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<ap serving="true">
<bssid>00-12-F0-A0-80-EF</bssid>
<ssid>wlan-home</ssid>
</ap>
</wifi>
</lm:measurements>
Figure 2: Measurement Example4.1. Measurement Container 🫧
the measurements element is used to wrap up measurement data that was collected at a certain point in time 🕰️ it holds the time-based attributes that all forms of measurement data have in common, and it allows arbitrary measurement data inside. the elements inside measurements are generically called "measurement elements" 🌷
you can add this container to a request for location info in any protocol that can carry XML, such as a HELD location request [RFC5985] 💅
4.1.1. Time of Measurement ⏰
the time attribute records the time the measurement or observation was made 💫 that can be different from the time the measurement info was reported 🙃 time info can be used to fill in a timestamp on the location result, or to decide whether the measurement info gets used at all
the time attribute SHOULD be provided whenever possible 🎀 that way a LIS doesn't have to pick some arbitrary timestamp. there are exceptions where leaving out time might make sense: relatively static types of measurement (like the DSL measurements in Section 5.6), or legacy Devices that don't record time info (like the Home Location Register/Home Subscriber Server for cellular) 🦋
the time attribute is attached to the root measurement element 🌈 multiple measurements can often share the same timestamp, even when they weren't actually taken at the same time (think of a set of measurements taken one after another, where the gap between observations isn't significant) ⭐ measurements can't be grouped if they have different types, or if each measurement needs its own independent time value 🙅♀️ in those cases, you need multiple measurement sets
4.1.2. Expiry Time on Location-Related Measurement Data ⌛
a Device can indicate an expiry time in the location measurement using the expires attribute 💜 nominally, this attribute says how long the info is expected to be valid, but it can also set a time limit on the retention and use of the measurement data 🫶 a Device can use it to ask the LIS not to keep measurement data beyond the indicated time
Note: Movement of the Device might result in the measurement data being invalidated before the expiry time.
a Device is advised to set expires to the earlier of two times: when measurements are likely to be unusable, and when it wants the LIS to have discarded them 🧚 a Device that doesn't want measurement data retained can just leave out the expires attribute entirely 🌸 Section 6 describes more specific rules about measurement data retention, so check that out too
4.2. RMS Error and Number of Samples 📊
often a measurement is taken more than once 🔁 reporting the average of a number of measurement results helps soften the effects of random errors in the measurement process 💖
reporting each measurement individually can be the most effective way to report multiple measurements 🎀 you do this by providing multiple measurement elements, one for each different time ✨
the alternative is to aggregate multiple measurements and report a mean value across the whole set 🍓 extra info about how the results are distributed can be really useful for figuring out location uncertainty 🧠
two attributes are provided for use on some measurement values 🫧
rmsError: the root-mean-squared (RMS) error of the set of measurement values used to calculate the result. RMS error is expressed in the same units as the measurement, unless otherwise stated. if an accurate value for the RMS error isn't known, this value can be used to indicate an upper bound or estimate for it 🌷samples: the number of samples taken when determining the measurement value. if omitted, this value can be assumed to be large enough that the RMS error is an indication of the standard deviation of the sample set 📈
for some measurement techniques, the measurement error depends mostly on the technique itself 💅 in those cases, the error is largely a product of the technique and not the specific circumstances, so the RMS error doesn't need to be actively measured 🙌 a fixed value MAY be provided for the RMS error where appropriate ✨
the rmsError and samples elements are added as attributes of specific measurement data types 🎀
4.2.1. Time RMS Error ⏱️
measurement of time can be a big deal in certain situations 😭 the GNSS measurements in this document are one such case, where a small error in time can result in a large error in location 🛰️ factors like clock drift and errors in time synchronization can cause small but significant time errors 🙃 including an indication of how good the time measurements are can be super helpful 💖
a timeError attribute MAY be added to the measurement element to indicate the RMS error in time 🦋 timeError indicates an upper bound on the time RMS error, in seconds ⏰
the timeError attribute doesn't apply where multiple samples of a measurement are taken over time 🙅♀️ if multiple samples are taken, each one SHOULD be included in a different measurement element 🌈 that's the way to go, iykyk 👑
4.3. Measurement Request ✨
Okay so a measurement request is how a protocol peer says, "hey, these are the measurements I'd love to get from you" 💅. There's a measurementRequest element that can be dropped right into a protocol exchange, and it's giving very organized.
For example, a LIS can use a measurement request in HELD responses. If the LIS can't provide location information but thinks a particular measurement type would let it figure out a location, it can include a measurement request in an error response. Main character problem-solving 🧚
The measurement element inside the request says which type of measurement is wanted. Its type attribute names that type using an XML qualified name. A samples attribute MAY be used to say how many samples of that measurement are requested 🍓
The measurement element can be repeated, so you can ask for several measurement types, or ask for alternatives. Iykyk, it's basically a menu 🌈
Some measurement types also come with extra XML content to refine a request. These extra elements either narrow down what's wanted or specify the non-mandatory parts of the measurement data that are needed. They're defined alongside the specific measurement type, so you'll find them in each type's own section ✨
In HELD, putting a measurement request inside an error response with a code of locationUnknown means that providing measurements would make a later request more likely to succeed. Honestly so smart 🫶
This example shows a HELD error response saying WiFi measurement data would be useful if a later request were made. The extra elements show that the received signal strength for an 802.11n access point is being requested 📡
<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
code="locationUnknown">
<message xml:lang="en">Insufficient measurement data</message>
<measurementRequest
xmlns="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<measurement type="wifi:wifi">
<wifi:type>n</wifi:type>
<wifi:parameter context="ap">wifi:rcpi</wifi:parameter>
</measurement>
</measurementRequest>
</error>Figure 3: HELD Error Requesting Measurement Data
A measurement request that shows up in other HELD messages has undefined semantics, so it can be safely ignored 🙈 Other specifications might define what it means under other conditions, so keep an eye out!
4.4. Identifying Location Provenance 🔥
Here's an extension to the PIDF-LO [RFC4119] that lets a location recipient see where the location information came from, and which measurement data was used to work it out. The receipts, bestie 🧾
The source element gets added to the geopriv element of the PIDF-LO. It doesn't name specific entities. Instead, it tells you the type of measurement source 💜
These are the values defined for the source element:
lis: Location information is based on measurement data that the LIS, or sources it trusts, have acquired. This label MAY be used if measurement data provided by the Device has been completely validated by the LIS.device: A LIS MUST include this value if the location information is based (in whole or in part) on measurement data provided by the Device and if the measurement data isn't completely validated. 🚩other: Location information is based on measurement data that a third party has provided. This might be an authorized third party that uses identity parameters [RFC6155] or any other entity. The LIS MUST include this, unless the third party is trusted by the LIS to provide measurement data.
No assertion is made about the veracity of measurement data from sources other than the LIS. Also, a combination of tags MAY be included to show that measurement data from multiple types of sources was used 🌸
Here's an example. The first tuple of the following PIDF-LO shows that measurement data from a LIS and a Device were combined to produce the result. The second tuple was produced by the LIS alone 👑
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
entity="pres:lm@example.com">
<tuple id="deviceLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34324 134.47162</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>OTDOA</gp:method>
<lmsrc:source>lis device</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
<tuple id="lisLoc">
<status>
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>7.34379 134.46484</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
9000
</gs:radius>
</gs:Circle>
</gp:location-info>
<gp:usage-rules/>
<gp:method>Cell</gp:method>
<lmsrc:source>lis</lmsrc:source>
</gp:geopriv>
</status>
</tuple>
</presence>PIDF-LO Document with Source Labels
5. Location-Related Measurement Data Types 🎀
This document defines location-related measurement data types for a whole range of common network types 🌈
Every included measurement data definition allows for arbitrary extension in the corresponding schema. New parameters that are relevant to location determination get added as new XML elements in a unique namespace. They never get added to an existing namespace, so no crossing wires 🧚
5.1. LLDP Measurements 🦋
Link-Layer Discovery Protocol (LLDP) [IEEE.8021AB] messages get sent between adjacent nodes in an IEEE 802 network (for example, wired Ethernet, WiFi, or 802.16). Every one of these messages has identification information for the sending node, and that identification information can be used to figure out location 🗺️ A Device that receives LLDP messages can report this information to the LIS as a location-related measurement, and then the LIS can use that data to work out where the Device is.
Note: The LLDP extensions defined in LLDP Media Endpoint Discovery (LLDP-MED) [ANSI-TIA-1057] provide the ability to acquire location information directly from an LLDP endpoint. Where this information is available, it might be unnecessary to use any other form of location configuration.
Values are provided as hexadecimal sequences. The Device MUST report the values directly as they were provided by the adjacent node. Trying to adjust or translate the type of identifier is likely to make the measurement data useless, so please don't 🙅♀️
If a Device has received LLDP messages from multiple adjacent nodes, it should provide the information from those messages by repeating the lldp element 💖
Here's an example of an LLDP measurement. It shows an adjacent node (chassis) identified by the IP address 192.0.2.45 (hexadecimal c000022d), and the port on that node is numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2) 🍓
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
<chassis type="4">c000022d</chassis>
<port type="6">a2</port>
</lldp>
</measurements>Figure 4: LLDP Measurement Example
IEEE 802 Devices that can find out about adjacent network switches, and how they're attached to them, by other means MAY use this data type to convey that information 🫶
5.2. DHCP Relay Agent Information Measurements 💅
The DHCP Relay Agent Information option [RFC3046] provides measurement data about the network attachment of a Device. This measurement data can be included in the dhcp-rai element 📡
The elements in the DHCP relay agent information options are opaque data types assigned by the DHCP relay agent. The three items MAY be omitted if they're unknown: the circuit identifier (circuit, from circuit [RFC3046], or Interface-Id [RFC3315]), the remote identifier (remote, from Remote ID [RFC3046], or remote-id [RFC4649]), and the subscriber identifier (subscriber, from subscriber-id [RFC3993], or Subscriber-ID [RFC4580]). The DHCPv6 remote-id has an associated enterprise number [IANA.enterprise] as an XML attribute 🎀
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dhcp-rai xmlns="urn:ietf:params:xml:ns:geopriv:lm:dhcp">
<giaddr>192.0.2.158</giaddr>
<circuit>108b</circuit>
</dhcp-rai>
</measurements>Figure 5: DHCP Relay Agent Information Measurement Example
The giaddr element is specified as a dotted quad IPv4 address or an RFC 4291 [RFC4291] IPv6 address, using the forms defined in [RFC3986]. IPv6 addresses SHOULD use the form described in [RFC5952] 🧠 The enterprise number is written as a decimal integer. All other information is included verbatim from the DHCP request, in hexadecimal format.
The subscriber element could be considered sensitive 😭 This information MUST NOT be provided to a LIS that isn't authorized to receive information about the access network. See Section 7.1.3 for more details.
5.3. 802.11 WLAN Measurements 📶✨
okay so, in WiFi (802.11 [IEEE.80211]) networks, a Device might be able to tell you about the access point (AP) it's attached to, plus any other WiFi points it can see 📡 that's what the wifi element is for! Figure 6 shows one complete measurement for one access point 💖
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2011-04-29T14:33:58">
<wifi xmlns="urn:ietf:params:xml:ns:geopriv:lm:wifi">
<nicType>Intel(r)PRO/Wireless 2200BG</nicType>
<ap serving="true">
<bssid>AB-CD-EF-AB-CD-EF</bssid>
<ssid>example</ssid>
<channel>5</channel>
<location>
<gml:Point xmlns:gml="http://opengis.net/gml">
<gml:pos>-34.4 150.8</gml:pos>
</gml:Point>
</location>
<type>a</type>
<band>5</band>
<regclass country="AU">2</regclass>
<antenna>2</antenna>
<flightTime rmsError="4e-9" samples="1">2.56e-9</flightTime>
<apSignal>
<transmit>23</transmit>
<gain>5</gain>
<rcpi dBm="true" rmsError="12" samples="1">-59</rcpi>
<rsni rmsError="15" samples="1">23</rsni>
</apSignal>
<deviceSignal>
<transmit>10</transmit>
<gain>9</gain>
<rcpi dBm="true" rmsError="9.5" samples="1">-98.5</rcpi>
<rsni rmsError="6" samples="1">7.5</rsni>
</deviceSignal>
</ap>
</wifi>
</measurements>Figure 6: 802.11 WLAN Measurement Example
A wifi element is made up of one or more access points, plus a nicType element, which MAY be omitted. Each access point is described using the ap element, which is made up of the following fields 🫶
bssid: The Basic Service Set (BSS) 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 has 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 attribute defaults to a value of "false" when omitted 🔐
ssid: The service set identifier (SSID) for the wireless network served by the access point.
The SSID is a 32-octet identifier that is commonly represented as an ASCII [ASCII] or UTF-8 [RFC3629] encoded string. To represent octets that cannot be directly included in an XML element, escaping is used. Sequences of octets that do not represent a valid UTF-8 encoding can be escaped using a backslash (\) followed by two case-insensitive hexadecimal digits representing the value of a single octet 🌸
The canonical or value-space form of an SSID is a sequence of up to 32 octets that is produced from the concatenation of UTF-8 encoded sequences of unescaped characters and octets derived from escaped components.
channel: The channel number (frequency) on which the access point operates.
location: The location of the access point, as reported by the access point. This element contains any valid location, using the rules for a location-info element, as described in [RFC5491] 📍
type: The network type for the network access. This element includes the alphabetic suffix of the 802.11 specification that introduced the radio interface, or PHY, e.g., "a", "b", "g", or "n".
band: The frequency band for the radio, in gigahertz (GHz). 802.11 [IEEE.80211] specifies PHY layers that use 2.4, 3.7, and 5 gigahertz frequency bands.
regclass: The operating class (regulatory domain and class in older versions of 802.11); see Annex E of [IEEE.80211]. The country attribute optionally includes the applicable two-character country identifier (dot11CountryString), which can be followed by an 'O', 'I', or 'X'. The element text content includes the value of the regulatory class: an 8-bit integer in decimal form 🌍
antenna: The antenna identifier for the antenna that the access point is using to transmit the measured signals.
flightTime: Flight time is the difference between the time of departure (TOD) of signal from a transmitting station and time of arrival (TOA) of signal at a receiving station, as defined in [IEEE.80211]. Measurement of this value requires that stations synchronize their clocks. This value can be measured by an access point or Device; because the flight time is assumed to be the same in either direction -- aside from measurement errors -- only a single element is provided. This element permits the use of the rmsError and samples attributes. RMS error might be derived from the reported RMS error in TOD and TOA ⏱️
apSignal: Measurement information for the signal transmitted by the access point, as observed by the Device. Some of these values are derived from 802.11v [IEEE.80211] messages exchanged between the Device and access point. The contents of this element include:
- transmit: The transmit power reported by the access point, in dBm.
- gain: The gain of the access point antenna reported by the access point, in dB.
- 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
dBmattribute MUST be set to"false". Signal strength reporting on current hardware uses a range of different mechanisms; therefore, the value of thenicTypeelement 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 permits the use of thermsErrorandsamplesattributes 📶 - rsni: The received signal-to-noise indicator in dB. This element permits the use of the
rmsErrorandsamplesattributes.
deviceSignal: Measurement information for the signal transmitted by the Device, as reported by the access point. This element contains the same child elements as the ap element, with the access point and Device roles reversed 🔄
The only mandatory element in this structure is "bssid".
The nicType element is used to specify the make and model of the wireless network interface in the Device. Different 802.11 chipsets report measurements in different ways, so knowing the network interface type aids the LIS in determining how to use the provided measurement data. The content of this field is unconstrained, and no mechanisms are specified to ensure uniqueness. This field is unlikely to be useful, except under tightly controlled circumstances 🤷♀️
5.3.1. WiFi Measurement Requests
Two elements are defined for requesting WiFi measurements in a measurement request:
- type: The
typeelement identifies the desired type (or types that are requested). - parameter: The
parameterelement identifies measurements that are requested for each measured access point. An element is identified by its qualified name. The"context"parameter can be used to specify if an element is included as a child of theapordeviceelements; omission indicates that it applies to both 🎀
Multiple types or parameters can be requested by repeating either element.
5.4. Cellular Measurements ✨
okay so cellular devices are literally everywhere 📱, and base station IDs are a really good source of coarse location info 🗼. Cellular measurements can go to a LIS run by the cellular operator, or to an alternative LIS operator that can access one of several global cell-id to location mapping databases 🌍.
There are a bunch of advanced location methods for cellular networks 🤓. For those, a range of measurement parameters can be collected by the network, the Device, or both working together 🫶. This document only includes a basic identifier for the wireless transmitter 📡. Future efforts might define more parameters for more accurate location methods, and I'm so here for that 🔥.
The cellular measurement set lets a Device report to a LIS any LTE (Figure 7), UMTS (Figure 8), GSM (Figure 9), or CDMA (Figure 10) cells it can observe 👀. Cells are reported using their global identifiers 🆔. All Third Generation Partnership Project (3GPP) cells are identified by a public land mobile network (PLMN), which is made of a mobile country code (MCC) and mobile network code (MNC) 🌏. Specific fields get added for each network type 💅.
Formats for 3GPP cell identifiers are described in [TS.3GPP.23.003]. Bit-level formats for CDMA cell identifiers are described in [TIA-2000.5], and decimal representations are used there 🔢.
MCC and MNC are given as decimal digit sequences, and a leading zero in an MCC or MNC is significant 🙈. Every other value is a decimal integer ✨.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>20</mnc><eucid>80936424</eucid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc><eucid>10736789</eucid>
</observedCell>
</cellular>
</measurements>Long term evolution (LTE) cells are identified by a 28-bit cell identifier (eucid) 💜.
Figure 7: Example LTE Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</servingCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>Universal mobile telephony service (UMTS) cells are identified by a 12- or 16-bit radio network controller (rnc) id and a 16-bit cell id (cid) 🎀.
Figure 8: Example UMTS Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</servingCell>
</cellular>
</measurements>Global System for Mobile communication (GSM) cells are identified by a 16-bit location area code (lac) and a 16-bit cell id (cid) 🌸.
Figure 9: Example GSM Cellular Measurement
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<servingCell>
<sid>15892</sid><nid>4723</nid><baseid>12</baseid>
</servingCell>
<observedCell>
<sid>15892</sid><nid>4723</nid><baseid>13</baseid>
</observedCell>
</cellular>
</measurements>Code division multiple access (CDMA) cells are not identified by a PLMN 🙃. Instead, they use a 15-bit system id (sid), a 16-bit network id (nid), and a 16-bit base station id (baseid) 🦋.
Figure 10: Example CDMA Cellular Measurement
In general, a cellular Device is attached to the cellular network, so the idea of a serving cell exists 📶. Cellular networks also overlap between neighboring sites, so a mobile Device can hear more than one cell 👂. The measurement schema supports sending both the serving cell and any other cells the mobile might be able to hear 🧚. Sometimes the Device is just listening to cell info without actually attaching to the network. Mobiles without a SIM are an example of this 📵. In that case, the Device can report the cells it can hear without naming any particular cell as a serving cell 💅. Here's an example of that, in Figure 11 ⬇️.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<cellular xmlns="urn:ietf:params:xml:ns:geopriv:lm:cell">
<observedCell>
<mcc>465</mcc><mnc>20</mnc>
<rnc>2000</rnc><cid>65000</cid>
</observedCell>
<observedCell>
<mcc>465</mcc><mnc>06</mnc>
<lac>16383</lac><cid>32767</cid>
</observedCell>
</cellular>
</measurements>Figure 11: Example Observed Cellular Measurement
5.4.1. Cellular Measurement Requests
Two elements can be used in measurement requests for cellular measurements 📝:
type: a label for the type of identifier to provide. It's one of"gsm","umts","lte", or"cdma"🏷️.network: the network portion of the cell identifier. For 3GPP networks, this is the combo of MCC and MNC. For CDMA, it's the network identifier 🌐.
You can ask for multiple identifier types or networks by repeating either element 🔁.
5.5. GNSS Measurements
A Global Navigation Satellite System (GNSS) uses orbiting satellites to transmit signals 🛰️✨. A Device with a GNSS receiver can take measurements from those satellite signals 📡. The results can be used to figure out both the time and the location of the Device ⏰📍.
Determining location and time in autonomous GNSS receivers happens in three steps 🪜:
- Signal acquisition: the receiver searches for the repeating code that each GNSS satellite sends 🔍. Successful operation typically needs measurement data for a minimum of 5 satellites. At this stage, measurement data is available to the Device 📲.
- Navigation message decode: once the signal is acquired, the receiver gets info about the configuration of the satellite constellation 🌌. Each satellite broadcasts this info, modulated onto the base signal at a low rate. For instance, GPS sends it at about 50 bits per second 🐢.
- Calculation: the measurement data gets combined with the data on the satellite constellation to figure out the location of the receiver and the current time 🧮.
A Device that uses a GNSS receiver can report measurements after the first stage of this process 🙌. A LIS can use those results to determine a location 📌. If fewer results are available than the optimal minimum, the LIS might be able to use other sources of measurement info and combine them with the available data to work out a position 🧩.
Note: Using different sets of GNSS assistance data can cut down the time needed for the signal acquisition stage, and can make it unnecessary for the receiver to extract data on the satellite constellation. Providing assistance data is outside the scope of this document 🙈.
Figure 12 shows an example of GNSS measurement data 📊. The measurement is for the GPS satellite system, and it only includes measurement data for three satellites 🛰️🛰️🛰️.
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58" timeError="2e-5">
<gnss xmlns="urn:ietf:params:xml:ns:geopriv:lm:gnss"
system="gps" signal="L1">
<sat num="19">
<doppler>499.9395</doppler>
<codephase rmsError="1.6e-9">0.87595747</codephase>
<cn0>45</cn0>
</sat>
<sat num="27">
<doppler>378.2657</doppler>
<codephase rmsError="1.6e-9">0.56639479</codephase>
<cn0>52</cn0>
</sat>
<sat num="20">
<doppler>-633.0309</doppler>
<codephase rmsError="1.6e-9">0.57016835</codephase>
<cn0>48</cn0>
</sat>
</gnss>
</measurements>Figure 12: Example GNSS Measurement
Each gnss element represents a single set of GNSS measurement data, taken at a single point in time 🕒. Measurements taken at different times can go in different gnss elements, which lets results get refined step by step 🔄.
GNSS measurement parameters are described in more detail in the following sections 📚.
5.5.1. GNSS: System Type and Signal
The GNSS measurement structure is designed to be generic, so it applies to different GNSS types 🌈. Different signals within those systems are accounted for too, and each can be measured separately 📶.
The GNSS type decides which time system gets used 🕰️. Telling the LIS the type of system and signal makes sure it can use the measurements correctly 💯.
You can include measurements for multiple GNSS types and signals by repeating the gnss element 🔁.
This document creates an IANA registry for GNSS types 🗂️. Two satellite systems are registered by this document: GPS [GPS.ICD] and Galileo [Galileo.ICD]. Details for the registry are in Section 9.1 💖.
5.5.2. Time
Each set of GNSS measurements is taken at a specific point in time ⏱️. The time attribute indicates when the measurement was acquired, if the receiver knows how the time system used by the GNSS relates to UTC time 🌍⏰.
As an alternative to the measurement time, or in addition to it, the gnssTime element MAY be included 🧚. The gnssTime element holds a relative time in milliseconds, using the time system native to the satellite system. For the GPS satellite system, gnssTime is the time of week in milliseconds. For the Galileo system, it's the time of day in milliseconds 🕐.
The accuracy of the time measurement is critical for how accurate the location info derived from GNSS measurements can be 😭. The receiver SHOULD indicate an estimated time error for any time it provides 🫶. An RMS error can be included for the gnssTime element, with a value in milliseconds 💅.
5.5.3. Per-Satellite Measurement Data 🛰️✨
okay so each GNSS measurement set can bundle up multiple satellites using the sat element 💫. every satellite gets its own number in the num attribute, and that number matches the identifier the given GNSS uses, so nobody gets mixed up 💅
both GPS and Galileo use satellite numbers from 1 to 64, so that's the range you're working with 🌈
the GNSS receiver measures these parameters for each satellite (it's giving precision 🔥):
doppler: the observed Doppler shift of the satellite signal, measured in meters per second 🏃♀️. the receiver converts it from Hertz so the measurement can be used without needing to know the carrier frequency of the satellite system 🧚. this value lets you use RMS error attributes too, which are also measured in meters per second.codephase: the observed code phase for the satellite signal, measured in milliseconds ⏱️. it gets converted from system-specific chips or wavelengths into a system-independent value, which is so iconic 👑. bigger numbers mean the satellite is farther from the receiver, periodt. this value lets you use RMS error attributes as well, and those are measured in milliseconds too.cn0: the signal-to-noise ratio for the satellite signal, measured in decibel-Hertz (dB-Hz) 📶. the expected range is between 20 and 50 dB-Hz, so if you're outside that, something's up 🙈mp: an estimation of how much error multipath signals add, measured in meters 🌀. this parameter MAY be omitted.cq: an indication of the carrier quality 🦋. there are two attributes here: "continuous" (which can be either "true" or "false") and "direct" (which can be either "direct" or "inverted"). this parameter MAY be omitted.adr: the accumulated Doppler range, measured in meters 📏. this parameter MAY be omitted, and it isn't useful unless you have multiple sets of GNSS measurements or you're doing differential positioning 🌸
all the values get converted from the satellite system's native measures into generic measures, so everyone reads them the same way 🫶. unless it's necessary, the schema doesn't constrain these values, so they stay flexible 💖
5.5.4. GNSS Measurement Requests 📡
measurement requests can include a gnss element, which has the system and signal attributes 🎀. you can include multiple gnss elements to ask for GNSS measurements from multiple systems or signals, so you get the full picture 🧚
5.6. DSL Measurements 🌐
Digital Subscriber Line (DSL) networks rely on a whole range of network technologies 🧩. DSL deployments regularly need several organizations to work together, and they fall into two broad categories: infrastructure providers and Internet service providers (ISPs) 🤝. for the same end user, the infrastructure and the Internet service can come from different entities. infrastructure providers manage most of the physical stuff, including the cabling 🔌. end users get their service from an ISP, which handles everything the end user can see, including IP address allocation and running a LIS 💜. see [DSL.TR025] and [DSL.TR101] for more on DSL network deployments and the parameters that are available 📚
sharing measurement info between these organizations is necessary for location information to be generated correctly 😭. the ISP LIS needs to get location information from the infrastructure provider. but the infrastructure provider might not know any Device identifiers, so it can only identify a stream of data that's sent to the ISP 🥺. the fix is to pass measurement data about the Device to a LIS run by the infrastructure provider ✨
5.6.1. L2TP Measurements 🔗
the Layer 2 Tunneling Protocol (L2TP) [RFC2661] is a super common way to link the infrastructure provider and the ISP 🌈. the infrastructure provider LIS needs measurement data that identifies a single L2TP tunnel, so it can generate location information from it 💅. Figure 13 shows an example L2TP measurement 🦋
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<l2tp>
<src>192.0.2.10</src>
<dest>192.0.2.61</dest>
<session>528</session>
</l2tp>
</dsl>
</measurements>
Figure 13: Example DSL L2TP Measurement5.6.2. RADIUS Measurements 🛡️
when it comes to authenticating network access, the infrastructure provider might use a RADIUS [RFC2865] proxy at the DSL Access Module (DSLAM) or Access Node (AN) 🏢. these messages give the ISP RADIUS server an identifier for the DSLAM or AN, plus the slot and port the Device is attached to 🎯. that data can be sent along as a measurement, so the infrastructure provider LIS can generate location information 💖
the format of the AN, slot, and port identifiers isn't defined in the RADIUS protocol 🤷♀️. the slot and port together identify a circuit on the AN, which is kind of like the circuit identifier in [RFC3046] 🧠. these items get provided directly, just the way they would appear in the RADIUS message. Figure 14 has an example 🌸
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<an>AN-7692</an>
<slot>3</slot>
<port>06</port>
</dsl>
</measurements>
Figure 14: Example DSL RADIUS Measurement5.6.3. Ethernet VLAN Tag Measurements 🏷️
for Ethernet-based DSL access networks, the DSLAM or AN puts two VLAN tags on packets 📦. the C-TAG identifies the incoming residential circuit, and the S-TAG identifies the DSLAM or AN 🧁. together, the C-TAG and S-TAG can identify a single point of network attachment, which is lowkey genius 🧠. Figure 15 shows an example
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<stag>613</stag>
<ctag>1097</ctag>
</dsl>
</measurements>
Figure 15: Example DSL VLAN Tag Measurementthere's also an alternative: the C-TAG can be swapped out for data about the slot and port the Device is attached to 🎀. that info might be included in RADIUS requests that get proxied from the infrastructure provider to the ISP RADIUS server 💫
5.6.4. ATM Virtual Circuit Measurements 🌊
an ATM virtual circuit can be used between the ISP and the infrastructure provider 💜. giving the virtual port ID (VPI) and virtual circuit ID (VCI) for that virtual circuit lets the infrastructure provider LIS identify a single data stream 🎯. here's a sample measurement in Figure 16 🦋
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
time="2008-04-29T14:33:58">
<dsl xmlns="urn:ietf:params:xml:ns:geopriv:lm:dsl">
<vpi>55</vpi>
<vci>6323</vci>
</dsl>
</measurements>
Figure 16: Example DSL ATM Measurement6. Privacy Considerations 🔒
location-related measurement data can be just as privacy sensitive as location information [RFC6280] 😭🔐
measurement data is basically the same as location information if the contextual knowledge needed to turn one into the other is easy to get 👀. even when that contextual knowledge is hard to acquire, there's no guarantee that someone authorized to receive the context is also authorized to receive location information 🙈
to protect the privacy of the subject of location-related measurement data, measurement data MUST be protected with the same degree of protection as location information 🫶. the confidentiality and authentication provided by Transport Layer Security (TLS) MUST be used to convey measurement data over HELD [RFC5985]. other protocols MUST provide comparable guarantees 💖
6.1. Measurement Data Privacy Model 🧠
measurement data doesn't need to be distributed the same way as location information 💅. it's less useful to location recipients than location information is, so a simple distribution model is described in this document ✨
in this simple model, the Device is the only entity that can distribute measurement data 🧚. to borrow an analogy from the GEOPRIV architecture, the Device (as the Location Generator or the Measurement Data Generator) is the one and only entity that can play both the Rule Maker and the Location Server roles 👑
a Device that provides location-related measurement data MUST only do so as explicitly authorized by a Rule Maker 🛑. this depends on having an interface that lets Rule Makers (for instance, users or administrators) control where and how measurement data is provided 🎀
no entity is permitted to redistribute measurement data 🚫. the Device tells other entities how measurement data is used and retained 🦋
the GEOPRIV model [RFC6280] protects the location of a Target using direction provided by a Rule Maker. for measurement data distribution, this model relies on the assumptions made in Section 3 of HELD [RFC5985]. those assumptions basically declare the Device to be a proxy for both the Target and the Rule Maker 🌈
6.2. LIS Privacy Requirements 🛡️
a LIS MUST NOT reveal location-related measurement data to any other entity 🙅♀️. a LIS MUST NOT reveal location information based on measurement data to any other entity unless the Device directs it to 😤
by adding measurement data to a request for location information, the Device implicitly grants the LIS permission to generate the requested location information using that measurement data 💫. permission to use this data for any other purpose is not implied, so don't assume it 🙈
as long as measurement data is only used to serve the request it's attached to, data retention rules aren't really necessary 🧹. a LIS MUST discard location-related measurement data after servicing a request, unless the Device grants permission to use that information for other purposes 🗑️
6.3. Measurement Data and Location URIs 📍
a LIS MAY use measurement data provided by the Device to serve requests to location URIs, if the Device permits it 🌸. a Device permits this by including measurement data in a request that explicitly asks for a location URI. by requesting a location URI, the Device grants the LIS permission to use the measurement data when serving requests to that location URI. the LIS cannot give location recipients measurement data, as defined in Section 6.1 🚫
Note: In HELD, the "any" type is not an explicit request for a location URI, though a location URI might be provided. ✨
the usefulness of measurement data provided this way is limited 🥲. the measurement data is only valid at the time the Device acquired it. when a request is made to a location URI, the Device might have moved, which would make the measurement data incorrect 🏃♀️
a Device can explicitly limit how long a LIS keeps measurement data by adding an expiry time to it ⏰. a LIS MUST NOT retain location-related measurement data in memory, storage, or logs beyond the time indicated in the "expires" attribute (Section 4.1.2) 😭. a LIS MUST NOT retain measurement data if the "expires" attribute is absent 🚫💜
6.4. Measurement Data Provided by a Third Party 🎀
okay so, an authorized third-party request for the location of a Device (see [RFC6155]) can include location-related measurement data too 🧚 this makes sense when the third party is able to make observations about the Device.
A third party that provides measurement data MUST be authorized to provide the specific measurement for the identified Device. Either a third party MUST be trusted by the LIS for the purposes of providing measurement data of the provided type, or the measurement data MUST be validated (see Section 7.2.1) before being used. bestie, these two MUST lines are doing the heavy lifting here 💅
How a third party authenticates its identity or gains authorization to use measurement data is not covered by this document. that's a whole other story, so this doc just leaves it alone 🌸
7. Security Considerations 🔥
The use of location-related measurement data has privacy considerations that are discussed in Section 6. go read that bit, it's important 💖
7.1. Threat Model 💅
The threat model for location-related measurement data concentrates on the Device providing falsified, stolen, or incorrect measurement data. so the main villain here is the Device itself 😭
A Device that provides location-related measurement data might use data to:
- acquire the location of another Device, without authorization;
- extract information about network topology; or
- coerce the LIS into providing falsified location information based on the measurement data.
Location-related measurement data describes the physical environment or network attachment of a Device. A third-party adversary in the proximity of the Device might be able to alter the physical environment such that the Device provides measurement data that is controlled by the third party. this might be used to indirectly control the location information that is derived from measurement data 👀 sneaky, sneaky 🦋
7.1.1. Acquiring Location Information without Authorization 🙈
Requiring authorization for location requests is an important part of privacy protections of a location protocol. A location configuration protocol usually operates under a restricted policy that allows a requester to obtain their own location. HELD identity extensions [RFC6155] allow other entities to be authorized, conditional on a Rule Maker providing sufficient authorization.
The intent of these protections is to ensure that a location recipient is authorized to acquire location information. Location-related measurement data could be used by an attacker to circumvent such authorization checks if the association between measurement data and Target Device is not validated by a LIS. ngl this is the scary part 😭
A LIS can be coerced into providing location information for a Device that a location recipient is not authorized to receive. A request identifies one Device (implicitly or explicitly), but measurement data is provided for another Device. If the LIS does not check that the measurement data is for the identified Device, it could incorrectly authorize the request.
By using unverified measurement data to generate a response, the LIS provides information about a Device without appropriate authorization. not it 💀
The feasibility of this attack depends on the availability of information that links a Device with measurement data. In some cases, measurement data that is correlated with a Target is readily available. For instance, LLDP measurements (Section 5.1) are broadcast to all nodes on the same network segment. An attacker on that network segment can easily gain measurement data that relates a Device with measurements. literally anyone on the segment can see it, so yeah 🫠
For some types of measurement data, it's necessary for an attacker to know the location of the Target in order to determine what measurements to use. This attack is meaningless for types of measurement data that require that the attacker first know the location of the Target before measurement data can be acquired or fabricated. GNSS measurements (Section 5.5) share this trait with many wireless location determination methods. iykyk, the chicken-and-egg thing protects you here 🧚♀️
7.1.2. Extracting Network Topology Data 🗺️
Allowing requests with measurements might be used to collect information about network topology.
Network topology can be considered sensitive information by a network operator for commercial or security reasons. While it is impossible to completely prevent a Device from acquiring some knowledge of network topology if a location service is provided, a network operator might desire to limit how much of this information is made available. so the operator just wants to keep the good stuff on the down-low 🤫
Mapping a network topology does not require that an attacker be able to associate measurement data with a particular Device. If a requester is able to try a number of measurements, it is possible to acquire information about network topology.
It is not even necessary that the measurements are valid; random guesses are sufficient, provided that there is no penalty or cost associated with attempting to use the measurements. no cap, guessing still works if nothing stops you from trying again 🎲💀
7.1.3. Exposing Network Topology Data 📡
A Device could reveal information about a network to entities outside of that network if it provides location measurement data to a LIS that is outside of that network. With the exception of GNSS measurements, the measurements in this document provide information about an access network that could reveal topology information to an unauthorized recipient.
A Device MUST NOT provide information about network topology without a clear signal that the recipient is authorized. A LIS that is discovered using DHCP as described in LIS discovery [RFC5986] can be considered to be authorized to receive information about the access network. 🚨 this one's a hard rule, no exceptions, periodt 💅
7.1.4. Lying by Proxy 🎭
Location information, which includes measurement data, is a function of its inputs. Thus, falsified measurement data can be used to alter the location information that is provided by a LIS. garbage in, garbage out, but make it sus 🗑️
Some types of measurement data are relatively easy to falsify in a way that causes the resulting location information to be selected with little or no error. For instance, GNSS measurements are easy to use for this purpose because all the contextual information necessary to calculate a position using measurements is broadcast by the satellites [HARPER]. ok the satellites are basically handing over the cheat codes 🛰️😭
An attacker that falsifies measurement data gains little if they are the only recipient of the result. The attacker knows that the location information is bad. The attacker only gains if the information can somehow be attributed to the LIS by another location recipient. By coercing the LIS into providing falsified location information, any credibility that the LIS might have -- that the attacker does not -- is gained by the attacker. the LIS's reputation becomes the prize, and that's the whole scam 👑
A third party that is reliant on the integrity of the location information might base an evaluation of the credibility of the information on the source of the information. If that third party is able to attribute location information to the LIS, then an attacker might gain.
Location information that is provided to the Device without any means to identify the LIS as its source is not subject to this attack. The Device is identified as the source of the data when it distributes the location information to location recipients. no LIS label, no problem 🫶
Location information is attributed to the LIS either through the use of digital signatures or by having the location recipient directly interact with the LIS. A LIS that digitally signs location information becomes identifiable as the source of the data. Similarly, the LIS is identified as a source of data if a location recipient acquires information directly from a LIS using a location URI. 🔏
7.1.5. Measurement Replay 🔁
The values of some measured properties do not change over time for a single location. The time invariance of network properties is often a direct result of the practicalities of operating the network. Limiting the changes to a network ensures greater consistency of service. A largely static network also greatly simplifies the data management tasks involved with providing a location service. stable networks are giving reliable vibes ✨
However, time-invariant properties allow for simple replay attacks, where an attacker acquires measurements that can later be used without being detected as being invalid. oh no, the classic replay plot twist 😱
Measurement data is frequently an observation of a time-invariant property of the environment at the subject location. For measurements of this nature, nothing in the measurement itself is sufficient proof that the Device is present at the resulting location. Measurement data might have been previously acquired and reused. so a fresh-looking measurement can still be old news 📼
For instance, the identity of a radio transmitter, if broadcast by that transmitter, can be collected and stored. An attacker that wishes it known that they exist at a particular location can claim to observe this transmitter at any time. Nothing inherent in the claim reveals it to be false. the attacker just says "I saw it!" and there's nothing in the claim itself to call them out 🙃🌈
7.1.6. Environment Spoofing ✨
Okay bestie, so some measurement data can be messed with by a third party, which means a Device can unknowingly hand over falsified data 😭. If someone can change the thing being measured, any location info derived from that data can get nudged too 🎀.
Changing the environment like this might not require involving the Device or the LIS at all 🦋. Passive measurement, where the Device just observes a signal or other phenomenon without poking at anything, is the most vulnerable to tampering by third parties 👀.
Radio signal measurements are especially vulnerable, ngl 💀. The attacker only has to be in the general vicinity and able to transmit a signal. For example, a GNSS spoofer can make fake signals that claim to come from any satellite or set of satellites (see [GPS.SPOOF]) 🛰️.
Measurements that need direct interaction make the attack more complicated 💅. For measurements about the communication medium, though, a third party can't avoid direct interaction. They just need to be on the communications path, which is a man in the middle, iykyk 🫣.
Even if the entity being interacted with is authenticated, that gives zero assurance about the integrity of the measurement data 🙅. Like, the Device might authenticate a radio transmitter using cryptographic means and take signal strength readings from it. But radio signal strength is trivial for an attacker to boost. They just receive and amplify the raw signal, and they don't need to understand the signal content 📡.
Note: This particular "attack" is more often completely legitimate. Radio repeaters are a commonplace mechanism used to increase radio coverage. 🌈
Attacks that rely on altering the observed environment of a Device need countermeasures that affect the measurement process itself 🔧. For radio signals, that could mean authenticated signals or altered receiver design. Countermeasures are super specific to each individual measurement process, so an exhaustive discussion is left to the relevant literature for each measurement technology 📚.
A Device that provides measurement data is assumed to be responsible for applying appropriate countermeasures against this type of attack 🧚.
Where a Device is the sole recipient of location information derived from measurement data, a LIS might choose to provide location information without any validation 🤷. The responsibility for ensuring the veracity of the measurement data lies with the Device 💖.
Measurement data that is susceptible to this sort of influence SHOULD be treated as though it were produced by an untrusted Device, for cases where a location recipient might attribute the location information to the LIS. GNSS measurements and radio signal strength measurements can be affected relatively cheaply 💸. Almost all other measurement types can also be affected, with varying costs to an attacker, and the largest cost is often a requirement for physical access 🚪. To the extent that it is feasible, measurement data SHOULD be subjected to the same validation as for other types of attacks that rely on measurement falsification ✅.
Note: Altered measurement data might be provided by a Device that has no knowledge of the alteration. Thus, an otherwise trusted Device might still be an unreliable source of measurement data 😬.
7.2. Mitigation
Here's the tea: the following measures can be applied to limit or prevent attacks 🍵. How well each one works depends on the type of measurement data and how that data is acquired 💅.
Two general approaches are identified for dealing with untrusted measurement data:
- Require independent validation of measurement data or the location information that is produced.
- Identify the types of sources that provided the measurement data from which that location information was derived.
This section gets into the details of the different forms of validation in Sections 7.2.1, 7.2.2, and 7.2.3. The impact of attributing location information to sources is covered in more detail in Section 7.2.4 🧩.
Any costs in validation are balanced against the degree of integrity you want from the resulting location information ⚖️.
7.2.1. Measurement Validation
Recognizing that measurement data has been falsified is hard without integrity mechanisms 😤.
Independent confirmation of the veracity of measurement data makes sure the measurement is accurate and applies to the correct Device ✔️. When the same measurement data can be gathered from a trusted and independent source without undue expense, the LIS can use the trusted data in place of what the untrusted Device sent. When that's impractical, the untrusted data can provide hints that allow corroboration of the data (see Section 7.2.1.1) 🕵️.
Measurement information might not contain any inherent indication that it is falsified 🫠. It can also be difficult to get information that gives any real assurance the measurement device is physically at a particular location 📍. Measurements that are difficult to verify require other forms of assurance before they can be used 🙏.
7.2.1.1. Effectiveness
Measurement validation MUST be used if measurement data for a particular Device can be easily acquired by unauthorized location recipients, as described in Section 7.1.1. This prevents unauthorized access to location information using measurement data 🔒.
Validation can be significantly more effective than independently acquiring the same data 🔥. For instance, a Device in a large Ethernet network could provide a measurement indicating its point of attachment using LLDP measurements. For a LIS, acquiring that same measurement data might require a request to all switches in the network. With the measurement data in hand, validation can target the identified switch with one specific query 🎯.
Validation is effective in identifying falsified measurement data (Section 7.1.4), including attacks involving replay of measurement data (Section 7.1.5). Validation also limits the amount of network topology information (Section 7.1.2) made available to Devices, down to just the portion of the topology they are directly attached to 🗺️.
Measurement validation has no effect if the underlying environment is being altered (Section 7.1.6) 🙃.
7.2.1.2. Limitations (Unique Observer)
A Device is often in a unique position to make a measurement 🧍. It alone occupies the point in space-time that the location determination process seeks to determine. So the Device becomes a unique observer for a particular property 👑.
Being a unique observer makes the Device invaluable to the location determination process 💎. It also makes the claims of a Device difficult to validate and easy to spoof 😬.
As long as no other entity is capable of making the same measurements, there is also no other entity that can independently check that the measurements are correct and applicable to the Device 🚫. A LIS might be unable to validate all or part of the measurement data it receives from a unique observer. For instance, a signal strength measurement of the signal from a radio tower cannot be validated directly 📶.
Some portion of the measurement data might still be independently verified, even if all information cannot. In the previous example, the radio tower might be able to verify that the Device is present if it is able to observe a radio signal sent by the Device 🗼.
If measurement data can only be partially validated, the extent to which it can be validated determines the effectiveness of validation against these attacks 📏.
The advantage of having the Device as a unique observer is that it makes it difficult for an attacker to acquire measurements without the assistance of the Device 🛡️. Attempts to use measurements to gain unauthorized access to measurement data (Section 7.1.1) are largely ineffectual against a unique observer 🙅♀️.
7.2.2. Location Validation
Location information that is derived from location-related measurement data can also be verified against trusted location information 🗺️. Rather than validating inputs to the location determination process, suspect locations are identified at the output of the process 🚨.
Trusted location information is acquired using sources of measurement data that are trusted. Untrusted location information is acquired using measurement data provided from untrusted sources, which might include the Device 🫤. These two locations are compared. If the untrusted location agrees with the trusted location, the untrusted location information is used ✅.
Algorithms for the comparison of location information are not included in this document. However, a simple comparison for agreement might require that the untrusted location be entirely contained within the uncertainty region of the trusted location 🧠.
There is little point in using a less accurate, less trusted location 🙄. Untrusted location information that has worse accuracy than trusted information can be immediately discarded. There are multiple factors that affect accuracy, with uncertainty and currency being the most important 📐. How location information is compared for accuracy is not defined in this document 🤷♀️.
7.2.2.1. Effectiveness
Location validation limits the extent to which falsified -- or erroneous -- measurement data can cause an incorrect location to be reported 🎀.
Location validation can be more efficient than validation of inputs, particularly for a unique observer (Section 7.2.1.2) ⚡.
Validating location ensures that the Device is at or near the resulting location 📌. Location validation can be used to limit or prevent all of the attacks identified in this document 💪.
7.2.2.2. Limitations
The trusted location that is used for validation is always less accurate than the location that is being checked 😩. The amount by which the untrusted location is more accurate is the same amount that an attacker can exploit 😈.
For example, a trusted location might indicate an uncertainty region with a radius of five kilometers. An untrusted location that describes a 100-meter uncertainty within the larger region might be accepted as more accurate 🙈. An attacker might still falsify measurement data to select any location within the larger uncertainty region. While the 100-meter uncertainty that is reported seems more accurate, a falsified location could be anywhere in the five-kilometer region 🗺️.
Where measurement data might have been falsified, the actual uncertainty is effectively much higher 📈. Local policy might allow differing degrees of trust to location information derived from untrusted measurement data. This might be a boolean operation with only two possible outcomes: untrusted location information might be used entirely or not at all 🔀. Alternatively, untrusted location information could be combined with trusted location information using different weightings, based on a value set in local policy ⚖️.
7.2.3. Supporting Observations ✨
Okay so replay attacks using old measurement data are lowkey the hardest thing to catch unless you have independent validation 😭. So instead of checking the measurement data directly, you might use supplementary data to validate the measurements or the location info that was worked out from them 🦋.
These supporting observations can give extra assurance that the Device's measurement data was gathered at a specific time and place 🧚. Basically, the Device is asked to prove it was actually there at the location it reported 💅.
For example, say a Device measures attributes of a radio signal. It could also be asked to send a sample of that radio signal 📡. If the LIS can observe the same signal, the two observations can be compared 👀. As long as the signal can't be predicted ahead of time by the Device, that supports the claim that the Device is able to receive it 🎀. So the Device is likely to be within the range that the signal is transmitted 🌈. A LIS can use this to give more trust to the related measurement data or resulting location 👑.
7.2.3.1. Effectiveness 🌸
The LIS's ability to get and validate these observations is the limit here 🙈. The cool thing about picking observations that are independent of the measurement data is that you can choose ones that are easy to get for both the LIS and the Device 💖. You can also tune how much data and how good it is based on how much assurance you want ✨.
Supporting observations are kind of similar to both measurement validation and location validation 🫶. All three methods depend on independently validating one or more properties, so each one applies in a similar way 💜.
Supporting observations can be used to limit or prevent all of the attacks identified in this document 🔥. Iconic 😭.
7.2.3.2. Limitations 🥀
How well this validation works depends on how good the supporting observation is 💅. That means how hard it is for the validating entity to get the data at a different time or place, how difficult it is to guess, and what other costs come with getting it 💀.
With the radio signal example, asking for a sample of the signal only proves the Device can receive the signal from the measured transmitter 📻. That gives some assurance the Device is within range of the transmitter, and that's it 🙃.
Just like with location validation, a Device could still send falsified measurements that change the location info, as long as the result stays inside that region 🫠.
You can ask for more supporting observations to shrink the region where an attacker could change the location, or to boost trust in the result 💪. But every extra measurement costs something to acquire 💸. Supporting observations contribute little or nothing toward the main goal of working out where the Device actually is 😤.
7.2.4. Attribution 🏷️
Lying by proxy (Section 7.1.4) works because the location recipient can't tell which LIS the location info came from 🎭. The attack stops working if location info is explicitly attributed to a particular source 🛑.
To do that, you need an extension to the location object that explicitly identifies the source (or sources) of each piece of location info 📝.
Instead of trying to make sure location info is accurate, this approach gives the location recipient what they need to make their own call on whether the location info can be trusted 🧠. Literally main character energy 👑.
Including an authenticated identity for every source of measurement data comes with a bunch of technical and operational headaches 😩. A LIS might only have a transient relationship with a Device 🕐. A Device isn't expected to share authentication info with a LIS 🔐. There's no guarantee that Device identification is usable by a potential location recipient 🤷♀️. And privacy concerns might stop identification info from being shared, even if it existed and was usable 🙈.
Identifying the type of measurement source is way simpler 💡. It lets a location recipient decide how trustworthy the location info is without needing authenticated identity info for each source 💖. The element for this is defined in Section 4.4 🎀.
When location info is based on measurement data from sources that might be untrusted, a LIS SHOULD include alternative location info derived from trusted sources of measurement data 🫶. Then each item of location info can be labeled with the source of that data 🏷️.
A location recipient that can identify a specific source of measurement data (whether that's the LIS or the Device) can attribute the location info to either entity or to both 🔍. That means it's way better at deciding how much to trust the info, based on where it came from 📊.
A location recipient that doesn't understand the "source" element can't make that distinction at all 😭. When constructing a PIDF-LO document, trusted location info MUST be placed in the PIDF-LO so that it gets higher priority than any untrusted location info, according to Rule #8 of [RFC5491] 👑🔥.
Attribution doesn't fix attacks that change the observed parameters used in location determination (Section 7.1.6). Those are a different beast 💀.
7.2.5. Stateful Correlation of Location Requests 🕸️
Stateful examination of requests can stop a Device from trying to map network topology with requests for location info (Section 7.1.2) 🗺️.
Just limiting how often a single Device can make requests cuts down how much data it can pull about network topology 🚦. A LIS can also keep track of how a Device moves 👀. A Device that's trying to gather topology info will probably get assigned locations that jump around a lot between requests 🦘, which could break physical laws (or lower limits that are still unlikely) when it comes to speed and acceleration 🏎️💨. Sus behavior, bestie 💅.
7.3. An Unauthorized or Compromised LIS 🚨
A compromised LIS, or a compromise in LIS discovery [RFC5986], could let an unauthorized entity get its hands on measurement data 😱. That info could then be used or passed around 📤. A Device MUST ensure that it authenticates a LIS, as described in Section 9 of [RFC5985] 🔐🫶.
Anyone who can get measurement data can use it to figure out where a Device is, but they can also use it for other stuff 🕵️♀️. That info can give insight into network topology (Section 7.1.2) 🗺️.
Measurement data can also get exploited in other ways 🧨. For example, if you reveal the type of 802.11 transceiver a Device uses, an attacker could use specific vulnerabilities to go after that Device 📡💀. Similarly, revealing info about network elements could enable targeted attacks on that infrastructure 🎯.
8. Measurement Schemas 🎀
The schemas are split up by their functions 🧩. There's a base container schema that all measurements go into, and it includes the definition of a measurement request (Section 8.1) 📦. A PIDF-LO extension is defined in its own separate schema (Section 8.2) 💜. A basic Types Schema holds common definitions, including the "rmsError" and "samples" attributes, plus types for IPv4, IPv6, and MAC addresses (Section 8.3) 🌸. Each specific measurement type gets its own separate schema ✨.
8.1. Measurement Container Schema 📦
<?xml version="1.0"?>
<xs:schema
xmlns:lm="urn:ietf:params:xml:ns:geopriv:lm"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a framework for location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="measurements">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="time" type="xs:dateTime"/>
<xs:attribute name="timeError" type="bt:positiveDouble"/>
<xs:attribute name="expires" type="xs:dateTime"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="measurementRequest"
type="lm:measurementRequestType"/>
<xs:complexType name="measurementRequestType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element ref="lm:measurement"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="measurement" type="lm:measurementType"/>
<xs:complexType name="measurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" type="xs:QName" use="required"/>
<xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- PIDF-LO extension for source -->
<xs:element name="source" type="lm:sourceType"/>
<xs:simpleType name="sourceType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="lis"/>
<xs:enumeration value="device"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:schema>Measurement Container Schema 🌈
8.2. Measurement Source Schema ✨
Okay bestie, this one is the little source tag 🏷️ that tells you what kind of measurement produced the location data. The schema is an extension to PIDF-LO, and its documentation says it indicates the type of measurement source behind the location information 📍.
<?xml version="1.0"?>
<xs:schema
xmlns:lmsrc="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines an extension to PIDF-LO that indicates
the type of measurement source that produced the measurement
data used in generating the associated location information.
</xs:documentation>
</xs:annotation>
<xs:element name="source" type="lmsrc:sourceType"/>
<xs:simpleType name="sourceType">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="lis"/>
<xs:enumeration value="device"/>
<xs:enumeration value="other"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:schema>Measurement Source PIDF-LO Extension Schema
8.3. Base Types Schema 🧁
Heads up bestie 🙈: the pattern rules in the schema below wrap because they're so long. Don't panic, none of the patterns contain whitespace ✨.
<?xml version="1.0"?>
<xs:schema
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:basetypes">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a set of base type elements.
</xs:documentation>
</xs:annotation>
<xs:simpleType name="byteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="twoByteType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="0"/>
<xs:maxInclusive value="65535"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="nonNegativeDouble">
<xs:restriction base="xs:double">
<xs:minInclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="positiveDouble">
<xs:restriction base="bt:nonNegativeDouble">
<xs:minExclusive value="0.0"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="doubleWithRMSError">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:attribute name="rmsError" type="bt:positiveDouble"/>
<xs:attribute name="samples" type="xs:positiveInteger"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="nnDoubleWithRMSError">
<xs:simpleContent>
<xs:restriction base="bt:doubleWithRMSError">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="ipAddressType">
<xs:union memberTypes="bt:IPv6AddressType bt:IPv4AddressType"/>
</xs:simpleType>
<!-- IPv6 format definition -->
<xs:simpleType name="IPv6AddressType">
<xs:annotation>
<xs:documentation>
An IP version 6 address, based on RFC 4291.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<!-- Fully specified address -->
<xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
<!-- Double colon start -->
<xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
<!-- Double colon middle -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
(:[0-9A-Fa-f]{1,4}){1}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
(:[0-9A-Fa-f]{1,4}){1,2}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
(:[0-9A-Fa-f]{1,4}){1,3}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
(:[0-9A-Fa-f]{1,4}){1,4}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
(:[0-9A-Fa-f]{1,4}){1,5}"/>
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
(:[0-9A-Fa-f]{1,4}){1,6}"/>
<!-- Double colon end -->
<xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
<!-- IPv4-Compatible and IPv4-Mapped Addresses -->
<xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
(:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
(:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
|((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
[0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
[0-9]?[0-9])"/>
<!-- The unspecified address -->
<xs:pattern value="::"/>
</xs:restriction>
</xs:simpleType>
<!-- IPv4 format definition -->
<xs:simpleType name="IPv4AddressType">
<xs:restriction base="xs:token">
<xs:pattern value="(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])\.
(25[0-5]|2[0-4][0-9]|[0-1]?[0-9]?[0-9])"/>
</xs:restriction>
</xs:simpleType>
<!-- MAC address (EUI-48) or EUI-64 address -->
<xs:simpleType name="macAddressType">
<xs:restriction base="xs:token">
<xs:pattern
value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}((-[\da-fA-F]{2}){2})?"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>Base Types Schema
8.4. LLDP Measurement Schema 🔗
This is the schema for LLDP location measurements, the chassis and port info that gets tucked into the data 💅.
<?xml version="1.0"?>
<xs:schema
xmlns:lldp="urn:ietf:params:xml:ns:geopriv:lm:lldp"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:lldp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:lldp">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a set of LLDP location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="lldp" type="lldp:lldpMeasurementType"/>
<xs:complexType name="lldpMeasurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="chassis" type="lldp:lldpDataType"/>
<xs:element name="port" type="lldp:lldpDataType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="lldpDataType">
<xs:simpleContent>
<xs:extension base="lldp:lldpOctetStringType">
<xs:attribute name="type" type="bt:byteType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="lldpOctetStringType">
<xs:restriction base="xs:hexBinary">
<xs:minLength value="1"/>
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>LLDP Measurement Schema
8.5. DHCP Measurement Schema 🌸
Last one in this batch! This schema covers DHCP location measurements, including the DHCP Relay Agent Information option 🧚.
<?xml version="1.0"?>
<xs:schema
xmlns:dhcp="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dhcp"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:dhcp">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a set of DHCP location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<!-- DHCP Relay Agent Information option -->
<xs:element name="dhcp-rai" type="dhcp:dhcpType"/>
<xs:complexType name="dhcpType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="giaddr" type="bt:ipAddressType"/>
<xs:element name="circuit"
type="xs:hexBinary" minOccurs="0"/>
<xs:element name="remote"
type="dhcp:dhcpRemoteType" minOccurs="0"/>
<xs:element name="subscriber"
type="xs:hexBinary" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="dhcpRemoteType">
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
<xs:attribute name="enterprise" type="xs:positiveInteger"
use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>DHCP Measurement Schema
8.6. WiFi Measurement Schema 📶
okay bestie, this one is the 802.11 (WiFi) location measurement schema 🦋 it's giving "here's exactly how to describe what a WiFi scan found, in XML." the namespace is urn:ietf:params:xml:ns:geopriv:lm:wifi and it leans on the base types from the basetypes schema, so the whole thing is layered like a cute outfit 💅
<?xml version="1.0"?>
<xs:schema
xmlns:wifi="urn:ietf:params:xml:ns:geopriv:lm:wifi"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:gml="http://www.opengis.net/gml"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:wifi"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:wifi">
802.11 location measurements
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a basic set of 802.11 location
measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:import namespace="http://www.opengis.net/gml"/>
<xs:element name="wifi" type="wifi:wifiNetworkType"/>
<xs:complexType name="wifiNetworkType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="nicType" type="xs:token"
minOccurs="0"/>
<xs:element name="ap" type="wifi:wifiType"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="wifiType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="bssid" type="wifi:bssidType"/>
<xs:element name="ssid" type="wifi:ssidType"
minOccurs="0"/>
<xs:element name="channel" type="xs:nonNegativeInteger"
minOccurs="0"/>
<xs:element name="location" minOccurs="0"
type="xs:anyType"/>
<xs:element name="type" type="wifi:networkType"
minOccurs="0"/>
<xs:element name="regclass" type="wifi:regclassType"
minOccurs="0"/>
<xs:element name="antenna" type="wifi:octetType"
minOccurs="0"/>
<xs:element name="flightTime" minOccurs="0"
type="bt:nnDoubleWithRMSError"/>
<xs:element name="apSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:element name="deviceSignal" type="wifi:signalType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="serving" type="xs:boolean"
default="false"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="bssidType">
<xs:simpleContent>
<xs:extension base="bt:macAddressType">
<xs:attribute name="verified" type="xs:boolean"
default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Note that this pattern does not prevent multibyte UTF-8
sequences that result in an SSID longer than 32 octets. -->
<xs:simpleType name="ssidType">
<xs:restriction base="xs:token">
<xs:pattern value="(\\[\da-fA-F]{2}|[^\\]){0,32}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="networkType">
<xs:restriction base="xs:token">
<xs:pattern value="[a-zA-Z]+"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="regclassType">
<xs:simpleContent>
<xs:extension base="wifi:octetType">
<xs:attribute name="country">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="[A-Z]{2}[OIX]?"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="octetType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="signalType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="transmit" type="xs:double"
minOccurs="0"/>
<xs:element name="gain" type="xs:double" minOccurs="0"/>
<xs:element name="rcpi" type="wifi:rssiType"
minOccurs="0"/>
<xs:element name="rsni" type="bt:doubleWithRMSError"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="rssiType">
<xs:simpleContent>
<xs:extension base="bt:doubleWithRMSError">
<xs:attribute name="dBm" type="xs:boolean" default="true"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- Measurement Request elements -->
<xs:element name="type" type="wifi:networkType"/>
<xs:element name="parameter" type="wifi:parameterType"/>
<xs:complexType name="parameterType">
<xs:simpleContent>
<xs:extension base="xs:QName">
<xs:attribute name="context" use="optional">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="ap"/>
<xs:enumeration value="device"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>WiFi Measurement Schema ✨
So the big picture is: a wifi element holds an optional nicType plus one or more ap entries (that's the maxOccurs="unbounded" doing the heavy lifting 🙌). Each ap carries a bssid (required), and can optionally carry an ssid, channel, location, type, regclass, antenna, flightTime, and signal info through apSignal and deviceSignal. Anything from other namespaces can tag along too, thanks to the ##other wildcards. Lowkey iconic extensibility 🌈
Two things the schema itself flags, so we don't pretend otherwise: the SSID pattern has a note saying it does not stop multibyte UTF-8 sequences from making an SSID longer than 32 octets 👀, and the type and parameter elements at the bottom are grouped under the comment about Measurement Request elements 📋
8.7. Cellular Measurement Schema 📡
and now the cellular one, the sibling schema for cell measurements 🌸 it lives in urn:ietf:params:xml:ns:geopriv:lm:cell, and it's got its own vibe: a cellular element with a serving cell or observed cell, plus any number of extra observed cells. the cellType is where it gets spicy, because it's a choice between a GSM/UMTS/LTE style identity (mcc, mnc, and then rnc/lac/cid or eucid) and a CDMA style one (sid, nid, baseid) 🔥
<?xml version="1.0"?>
<xs:schema
xmlns:cell="urn:ietf:params:xml:ns:geopriv:lm:cell"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:cell"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:cell">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a set of cellular location measurements.
</xs:documentation>
</xs:annotation>
<xs:element name="cellular" type="cell:cellularType"/>
<xs:complexType name="cellularType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:choice>
<xs:element name="servingCell" type="cell:cellType"/>
<xs:element name="observedCell" type="cell:cellType"/>
</xs:choice>
<xs:element name="observedCell" type="cell:cellType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="cellType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:sequence>
<xs:element name="mcc" type="cell:mccType"/>
<xs:element name="mnc" type="cell:mncType"/>
<xs:choice>
<xs:sequence>
<xs:choice>
<xs:element name="rnc" type="cell:cellIdType"/>
<xs:element name="lac" type="cell:cellIdType"/>
</xs:choice>
<xs:element name="cid" type="cell:cellIdType"/>
</xs:sequence>
<xs:element name="eucid" type="cell:cellIdType"/>
</xs:choice>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence>
<xs:element name="sid" type="cell:cellIdType"/>
<xs:element name="nid" type="cell:cellIdType"/>
<xs:element name="baseid" type="cell:cellIdType"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="mccType">
<xs:restriction base="xs:token">
<xs:pattern value="[0-9]{3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="mncType">
<xs:restriction base="xs:token">
<xs:pattern value="[0-9]{2,3}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="cellIdType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="268435455"/> <!-- 2^28 (eucid) -->
</xs:restriction>
</xs:simpleType>
<!-- Measurement Request elements -->
<xs:element name="type" type="cell:typeType"/>
<xs:simpleType name="typeType">
<xs:restriction base="xs:token">
<xs:enumeration value="gsm"/>
<xs:enumeration value="umts"/>
<xs:enumeration value="lte"/>
<xs:enumeration value="cdma"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="network" type="cell:networkType"/>
<xs:complexType name="networkType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:sequence>
<xs:element name="mcc" type="cell:mccType"/>
<xs:element name="mnc" type="cell:mncType"/>
</xs:sequence>
<xs:element name="nid" type="cell:cellIdType"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>Cellular Measurement Schema 💖
the cellIdType tops out at 268435455, and the comment right next to it says that's 2^28 for the eucid case 🧮 and the typeType enumerates the four radio families (gsm, umts, lte, cdma) that the type element can name 📶
8.8. GNSS Measurement Schema ✨
Okay bestie, here's the GNSS schema 🛰️💖 It's the one for satellite location measurements, the GPS-and-friends stuff, and it's giving very structured. Here's the full schema:
<?xml version="1.0"?>
<xs:schema
xmlns:gnss="urn:ietf:params:xml:ns:geopriv:lm:gnss"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:gnss"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:gnss">
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a set of GNSS location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<!-- GNSS -->
<xs:element name="gnss" type="gnss:gnssMeasurementType">
<xs:unique name="gnssSatellite">
<xs:selector xpath="sat"/>
<xs:field xpath="@num"/>
</xs:unique>
</xs:element>
<xs:complexType name="gnssMeasurementType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="gnssTime" type="bt:nnDoubleWithRMSError"
minOccurs="0"/>
<xs:element name="sat" type="gnss:gnssSatelliteType"
minOccurs="1" maxOccurs="64"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="system" type="xs:token" use="required"/>
<xs:attribute name="signal" type="xs:token"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="gnssSatelliteType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="doppler" type="bt:doubleWithRMSError"/>
<xs:element name="codephase"
type="bt:nnDoubleWithRMSError"/>
<xs:element name="cn0" type="bt:nonNegativeDouble"/>
<xs:element name="mp" type="bt:positiveDouble"
minOccurs="0"/>
<xs:element name="cq" type="gnss:codePhaseQualityType"
minOccurs="0"/>
<xs:element name="adr" type="xs:double" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="num" type="xs:positiveInteger"
use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="codePhaseQualityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="continuous" type="xs:boolean"
default="true"/>
<xs:attribute name="direct" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="direct"/>
<xs:enumeration value="inverted"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>GNSS Measurement Schema
8.9. DSL Measurement Schema 💜
Next up is the DSL schema, for the wired-line side of things 🧚 Same energy, different vibe. Here it is:
<?xml version="1.0"?>
<xs:schema
xmlns:dsl="urn:ietf:params:xml:ns:geopriv:lm:dsl"
xmlns:bt="urn:ietf:params:xml:ns:geopriv:lm:basetypes"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:geopriv:lm:dsl"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:lm:dsl">
DSL measurement definitions
</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc7105.txt">
This schema defines a basic set of DSL location measurements.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:geopriv:lm:basetypes"/>
<xs:element name="dsl" type="dsl:dslVlanType"/>
<xs:complexType name="dslVlanType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice>
<xs:element name="l2tp">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="src" type="bt:ipAddressType"/>
<xs:element name="dest" type="bt:ipAddressType"/>
<xs:element name="session"
type="xs:nonNegativeInteger"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:sequence>
<xs:element name="an" type="xs:token"/>
<xs:group ref="dsl:dslSlotPort"/>
</xs:sequence>
<xs:sequence>
<xs:element name="stag" type="dsl:vlanIDType"/>
<xs:choice>
<xs:sequence>
<xs:element name="ctag" type="dsl:vlanIDType"/>
<xs:group ref="dsl:dslSlotPort" minOccurs="0"/>
</xs:sequence>
<xs:group ref="dsl:dslSlotPort"/>
</xs:choice>
</xs:sequence>
<xs:sequence>
<xs:element name="vpi" type="bt:byteType"/>
<xs:element name="vci" type="bt:twoByteType"/>
</xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="vlanIDType">
<xs:restriction base="xs:nonNegativeInteger">
<xs:maxInclusive value="4095"/>
</xs:restriction>
</xs:simpleType>
<xs:group name="dslSlotPort">
<xs:sequence>
<xs:element name="slot" type="xs:token"/>
<xs:element name="port" type="xs:token"/>
</xs:sequence>
</xs:group>
</xs:schema>DSL Measurement Schema
9. IANA Considerations 🌸
Okay, so this section is the paperwork part, but it's lowkey important 💅 It creates a registry for GNSS types (Section 5.5) and registers the namespaces and schemas from Section 8.
9.1. IANA Registry for GNSS Types 🛰️
This document sets up a brand new IANA registry for "Global Navigation Satellite System (GNSS)" types. The registry holds tokens for the GNSS type itself and for each of the signals inside that type. Referring to [RFC5226], this registry runs under "Specification Required" rules. The IESG will appoint an Expert Reviewer, who will advise IANA promptly on each request for a new or updated GNSS type.
Every entry in the registry needs the following info:
- GNSS Name: the name of the GNSS
- Brief Description: a brief description of the GNSS
- GNSS Token: a token that can be used to identify the GNSS
- Signals: a set of tokens that represent each of the signals that the system provides
- Documentation Reference: a reference to one or more stable, public specifications that outline usage of the GNSS, including (but not limited to) signal specifications and time systems
The registry starts off with two registrations 🌈
- GNSS Name: Global Positioning System (GPS)
- Brief Description: a system of satellites that use spread-spectrum transmission, operated by the US military for commercial and military applications
- GNSS Token:
gps - Signals:
L1,L2,L1C,L2C,L5 - Documentation Reference: Navstar GPS Space Segment/Navigation User Interface [GPS.ICD]
- GNSS Name: Galileo
- Brief Description: a system of satellites that operate in the same spectrum as GPS, operated by the European Union for commercial applications
- GNSS Token:
galileo - Signals:
L1,E5A,E5B,E5A+B,E6 - Documentation Reference: Galileo Open Service Signal In Space Interface Control Document (SIS ICD) [Galileo.ICD]
9.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc
This section registers a new XML namespace, urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc, following the guidelines in [RFC3688] 🦋
- URI:
urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
- XML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Measurement Source for PIDF-LO</title>
</head>
<body>
<h1>Namespace for Location Measurement Source</h1>
<h2>urn:ietf:params:xml:ns:pidf:geopriv10:lmsrc</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>9.3. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm, following the guidelines in [RFC3688] 💖
- URI:
urn:ietf:params:xml:ns:geopriv:lm - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
- XML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Measurement Container</title>
</head>
<body>
<h1>Namespace for Location Measurement Container</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>9.4. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:basetypes
This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:lm:basetypes, following the guidelines in [RFC3688] ✨
- URI:
urn:ietf:params:xml:ns:geopriv:lm:basetypes - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com).
- XML:
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Base Device Types</title>
</head>
<body>
<h1>Namespace for Base Types</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:basetypes</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>9.5. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:lldp ✨
Okay bestie, this one registers a brand new XML namespace, "urn:ietf:params:xml:ns:geopriv:lm:lldp" 🦋, following the guidelines in [RFC3688]. It's giving organized 💅
- URI:
urn:ietf:params:xml:ns:geopriv:lm:lldp - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🫶
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>LLDP Measurement Set</title>
</head>
<body>
<h1>Namespace for LLDP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:lldp</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END9.6. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dhcp 🌸
Next up is the DHCP one! This registers the XML namespace "urn:ietf:params:xml:ns:geopriv:lm:dhcp", again following [RFC3688]. Same squad, same vibes 🧚
- URI:
urn:ietf:params:xml:ns:geopriv:lm:dhcp - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 💜
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DHCP Measurement Set</title>
</head>
<body>
<h1>Namespace for DHCP Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dhcp</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END9.7. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:wifi 📶
WiFi time! This registers "urn:ietf:params:xml:ns:geopriv:lm:wifi" as a new XML namespace, per the guidelines in [RFC3688]. Iconic behaviour, honestly 👑
- URI:
urn:ietf:params:xml:ns:geopriv:lm:wifi - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🫶
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>WiFi Measurement Set</title>
</head>
<body>
<h1>Namespace for WiFi Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:wifi</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END9.8. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:cell 📱
Cellular next! This registers "urn:ietf:params:xml:ns:geopriv:lm:cell" as a new XML namespace under [RFC3688]. Ate and left no crumbs 💅
- URI:
urn:ietf:params:xml:ns:geopriv:lm:cell - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🌈
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Cellular Measurement Set</title>
</head>
<body>
<h1>Namespace for Cellular Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:cell</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END9.9. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:gnss 🛰️
GNSS! This registers "urn:ietf:params:xml:ns:geopriv:lm:gnss" as a new XML namespace, following the guidelines in [RFC3688]. Main character energy ⭐
- URI:
urn:ietf:params:xml:ns:geopriv:lm:gnss - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 💖
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>GNSS Measurement Set</title>
</head>
<body>
<h1>Namespace for GNSS Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:gnss</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END9.10. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:lm:dsl 🧵
Last of the namespace set: DSL! This registers "urn:ietf:params:xml:ns:geopriv:lm:dsl" as a new XML namespace, per [RFC3688]. Periodt 🫶
- URI:
urn:ietf:params:xml:ns:geopriv:lm:dsl - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🍓
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>DSL Measurement Set</title>
</head>
<body>
<h1>Namespace for DSL Measurement Set</h1>
<h2>urn:ietf:params:xml:ns:geopriv:lm:dsl</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc7105.txt">
RFC 7105</a>.</p>
</body>
</html>
END9.11. XML Schema Registration for Measurement Source Schema 🗂️
Now we're registering the XML schemas! This registers an XML schema following the guidelines in [RFC3688].
- URI:
urn:ietf:params:xml:schema:pidf:geopriv10:lmsrc - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 💜
- Schema: The XML for this schema can be found in Section 8.2 of this document.
9.12. XML Schema Registration for Measurement Container Schema 📦
Container schema, coming in hot! This registers an XML schema following the guidelines in [RFC3688] 💅
- URI:
urn:ietf:params:xml:schema:geopriv:lm - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🫶
- Schema: The XML for this schema can be found in Section 8.1 of this document.
9.13. XML Schema Registration for Base Types Schema 🧱
Base types next! This registers an XML schema following the guidelines in [RFC3688]. Foundational, but make it cute 🎀
- URI:
urn:ietf:params:xml:schema:geopriv:lm:basetypes - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🌸
- Schema: The XML for this schema can be found in Section 8.3 of this document.
9.14. XML Schema Registration for LLDP Schema 🔌
LLDP schema! This registers an XML schema under the guidelines in [RFC3688]. Lowkey iconic ✨
- URI:
urn:ietf:params:xml:schema:geopriv:lm:lldp - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🦋
- Schema: The XML for this schema can be found in Section 8.4 of this document.
9.15. XML Schema Registration for DHCP Schema 🛜
DHCP schema time! This registers an XML schema following [RFC3688]. Slay 💖
- URI:
urn:ietf:params:xml:schema:geopriv:lm:dhcp - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🧚
- Schema: The XML for this schema can be found in Section 8.5 of this document.
9.16. XML Schema Registration for WiFi Schema 📡
WiFi schema! This registers an XML schema under the guidelines in [RFC3688]. No notes 🙈
- URI:
urn:ietf:params:xml:schema:geopriv:lm:wifi - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 💜
- Schema: The XML for this schema can be found in Section 8.6 of this document.
9.17. XML Schema Registration for Cellular Schema 📶
Cellular schema! This registers an XML schema following [RFC3688], and it's giving tidy 🌈
- URI:
urn:ietf:params:xml:schema:geopriv:lm:cell - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🫶
- Schema: The XML for this schema can be found in Section 8.7 of this document.
9.18. XML Schema Registration for GNSS Schema 🌍
GNSS schema! This registers an XML schema under the guidelines in [RFC3688]. Obsessed 😭
- URI:
urn:ietf:params:xml:schema:geopriv:lm:gnss - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) ⭐
- Schema: The XML for this schema can be found in Section 8.8 of this document.
9.19. XML Schema Registration for DSL Schema 🧵
DSL schema, the final one in this batch! It registers an XML schema following [RFC3688]. Done and dusted 👑
- URI:
urn:ietf:params:xml:schema:geopriv:lm:dsl - Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin Thomson (martin.thomson@gmail.com) 🍓
- Schema: The XML for this schema can be found in Section 8.9 of this document.
10. Acknowledgements 🫶
Huge thank-yous, bestie! Simon Cox gets props for his terminology comments, which helped keep this document lined up with ongoing work in the Open Geospatial Consortium (OGC) 🌍. Neil Harper reviewed and commented on the GNSS sections 🛰️. Noor-E-Gagan Singh, Gabor Bajko, Russell Priebe, and Khalid Al-Mufti put in serious input and suggestions to improve the 802.11 measurements 📶, and Cullen Jennings gave feedback and suggestions 💖. Bernard Aboba reviewed and gave feedback on a range of measurement data definitions 🧾. Mary Barnes and Geoff Thompson did a review and corrections ✨. David Waitzman and John Bressler both pointed out shortcomings with the 802.11 measurements 👀. And Keith Drage and Darren Pawson shared expert LTE knowledge 📡. Y'all are the real MVPs 👑
11. References
11.1. Normative References ✨
okay so these are the must-read docs 📚 the spec leans on them hard, no cap
[ASCII]ANSI, "US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986", 1986.[GPS.ICD]"Navstar GPS Space Segment/Navigation User Interface", ICD GPS-200, April 2000.[Galileo.ICD]GJU, "Galileo Open Service Signal In Space Interface Control Document (SIS ICD)", May 2006.[IANA.enterprise]IANA, "Private Enterprise Numbers", 2014,<http://www.iana.org/assignments/enterprise-numbers>.[IEEE.80211]IEEE, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2012, March 2012.[IEEE.8021AB]IEEE, "IEEE Standard for Local and Metropolitan Area Networks, Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB-2009, September 2009.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC3046]Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.[RFC3315]Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.[RFC3993]Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 3993, March 2005.[RFC4119]Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.[RFC4291]Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.[RFC4580]Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, June 2006.[RFC4649]Volz, B., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August 2006.[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.[RFC5952]Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.[RFC5985]Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.[RFC5986]Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.[TIA-2000.5]TIA/EIA, "Upper Layer (Layer 3) Signaling Standard for cdma2000(R) Spread Spectrum Systems", TR-45.5 / TSG-C TIA-2000.5-E / C.S0005-E v1.0, September 2009.[TS.3GPP.23.003]3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 12.0.0, September 2013,<http://www.3gpp.org/ftp/Specs/html-info/23003.htm>.
11.2. Informative References 🌸
these ones are the bonus reads, super helpful for context but the spec doesn't need them to work 🧚
[ANSI-TIA-1057]ANSI/TIA, "Link Layer Discovery Protocol for Media Endpoint Devices", TIA 1057, April 2006.[DSL.TR025]Wang, R., "Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL", September 1999.[DSL.TR101]Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL Aggregation", April 2006.[GPS.SPOOF]Scott, L., "Anti-Spoofing and Authenticated Signal Architectures for Civil Navigation Signals", ION-GNSS Portland, Oregon, 2003.[HARPER]Harper, N., "Server-side GPS and Assisted-GPS in Java", December 2009.[RFC2661]Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.[RFC2865]Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.[RFC3688]Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.[RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[RFC6155]Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.[RFC6280]Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
Authors' Addresses 🎀
the people who wrote it, with how to reach them 💌
Martin Thomson
Mozilla
Suite 300
650 Castro Street
Mountain View, CA 94041
US
EMail: martin.thomson@gmail.com
James Winterbottom
Unaffiliated
AU
EMail: a.james.winterbottom@gmail.com📦 where this page comes from
- ietf: rfc7105 2014-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms