idnits 2.17.1 draft-doran-geopriv-proto-map-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: version: The Gears "version" parameter is specific to the Google Gears protocol and therefore does not get stored in the CLIF model. When encoding a Google Gears request from a CLIF request object, the encoder MUST generate the version parameter on its own. When decoding a Google Gears request and storing the data in a CLIF object, the decoder MUST not store the version number in the model, though it MAY choose to store or use it outside CLIF for some application-specific purpose. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: host: The Gears "host" parameter is specific to the Google Gears protocol and therefore does not get stored in the CLIF model. When encoding a Google Gears request from a CLIF request object, the encoder MUST generate the host parameter on its own. When decoding a Google Gears request, the decoder MUST not store the host parameter in a CLIF object, though it MAY choose to store or use it outside CLIF for some application-specific purpose. -- The document date (March 9, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ISO639' on line 278 -- Looks like a reference, but probably isn't: 'RFC4282' on line 386 -- Looks like a reference, but probably isn't: 'PIDF-LO' on line 814 -- Looks like a reference, but probably isn't: 'Protocol A' on line 1413 -- Looks like a reference, but probably isn't: 'Protocols A' on line 1389 -- Looks like a reference, but probably isn't: 'B' on line 1389 -- Looks like a reference, but probably isn't: 'C' on line 1389 -- Looks like a reference, but probably isn't: 'Protocol B' on line 1412 == Unused Reference: '2' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1434, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1437, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1442, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1447, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1454, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1461, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1465, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1469, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-21 == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-07 == Outdated reference: A later version (-17) exists of draft-ietf-geopriv-rfc3825bis-09 Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV K. Doran 3 Internet-Draft R. Barnes 4 Intended status: Informational BBN Technologies 5 Expires: September 10, 2010 March 9, 2010 7 A Common Framework for Location Protocols 8 draft-doran-geopriv-proto-map-01 10 Abstract 12 There are currently several protocols developed by different 13 standards organizations that implement a basic design pattern where a 14 client requests location from a location server and the server 15 responds with location information. This document defines the Common 16 Location Interoperability Framework (CLIF), a general data model for 17 such protocols, and describes how some existing geolocation protocols 18 can be mapped into this unified model. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 10, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5 63 4. Request parameters . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1.1. Callback . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.2. Language . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1.3. Response Accuracy . . . . . . . . . . . . . . . . . . 7 68 4.1.4. Response Age . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.5. Response Time . . . . . . . . . . . . . . . . . . . . 7 70 4.1.6. Response Location Type . . . . . . . . . . . . . . . . 7 71 4.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2.1. Unique Identifier (UID) . . . . . . . . . . . . . . . 9 73 4.2.2. Network Access Identifier (NAI) . . . . . . . . . . . 9 74 4.2.3. Network Access Password . . . . . . . . . . . . . . . 9 75 4.2.4. Group Identifier . . . . . . . . . . . . . . . . . . . 9 76 4.2.5. IP Address . . . . . . . . . . . . . . . . . . . . . . 9 77 4.2.6. MAC Address . . . . . . . . . . . . . . . . . . . . . 10 78 4.2.7. Port Number . . . . . . . . . . . . . . . . . . . . . 10 79 4.2.8. URI . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.2.9. Fully Qualified Domain Name . . . . . . . . . . . . . 10 81 4.2.10. Telephony . . . . . . . . . . . . . . . . . . . . . . 10 82 4.2.10.1. Mobile Station International Subscriber Dial 83 Number (MSISDN) . . . . . . . . . . . . . . . . . 11 84 4.2.10.2. International Mobile Subscriber Identity 85 (IMSI) . . . . . . . . . . . . . . . . . . . . . 11 86 4.2.10.3. International Mobile Equipment Identifier 87 (IMEI) . . . . . . . . . . . . . . . . . . . . . 11 88 4.2.10.4. Mobile Identification Number (MIN) . . . . . . . 11 89 4.2.10.5. Mobile Directory Number (MDN) . . . . . . . . . . 11 90 4.2.10.6. Home Mobile Country Code . . . . . . . . . . . . 11 91 4.2.10.7. Home Mobile Network Code . . . . . . . . . . . . 12 92 4.3. Measurement . . . . . . . . . . . . . . . . . . . . . . . 12 93 4.3.1. Timestamp . . . . . . . . . . . . . . . . . . . . . . 12 94 4.3.2. Expires . . . . . . . . . . . . . . . . . . . . . . . 12 95 4.3.3. Samples . . . . . . . . . . . . . . . . . . . . . . . 12 96 4.3.4. WifiMeasurement . . . . . . . . . . . . . . . . . . . 12 97 4.3.4.1. NIC Type . . . . . . . . . . . . . . . . . . . . 13 98 4.3.4.2. Wireless Access Point (WAP) . . . . . . . . . . . 13 99 4.3.5. CellularMeasurement . . . . . . . . . . . . . . . . . 15 100 4.3.5.1. Radio Type . . . . . . . . . . . . . . . . . . . 15 101 4.3.5.2. Carrier . . . . . . . . . . . . . . . . . . . . . 15 102 4.3.5.3. Cellular Tower . . . . . . . . . . . . . . . . . 15 103 4.3.6. WiMAX . . . . . . . . . . . . . . . . . . . . . . . . 17 104 4.3.7. GNSS . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 4.3.8. w16e . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 4.4. Other parameters . . . . . . . . . . . . . . . . . . . . . 17 107 5. Response parameters . . . . . . . . . . . . . . . . . . . . . 17 108 5.1. General parameters . . . . . . . . . . . . . . . . . . . . 17 109 5.1.1. Message . . . . . . . . . . . . . . . . . . . . . . . 17 110 5.1.2. Age . . . . . . . . . . . . . . . . . . . . . . . . . 18 111 5.1.3. Unique Identifer (UID) . . . . . . . . . . . . . . . . 18 112 5.2. Location Reference . . . . . . . . . . . . . . . . . . . . 18 113 5.3. Location Oject [PIDF-LO] . . . . . . . . . . . . . . . . . 18 114 5.3.1. Geodetic location . . . . . . . . . . . . . . . . . . 18 115 5.3.2. Civic location . . . . . . . . . . . . . . . . . . . . 18 116 5.4. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 18 117 5.4.1. Error Code . . . . . . . . . . . . . . . . . . . . . . 18 118 5.4.2. Error Message . . . . . . . . . . . . . . . . . . . . 19 119 6. Protocol mapping summary . . . . . . . . . . . . . . . . . . . 19 120 6.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 121 6.1.1. Location Request Message . . . . . . . . . . . . . . . 23 122 6.1.2. Location Response Message . . . . . . . . . . . . . . 23 123 6.1.3. Error Message . . . . . . . . . . . . . . . . . . . . 23 124 6.2. Google Gears . . . . . . . . . . . . . . . . . . . . . . . 23 125 6.2.1. Location Request Message . . . . . . . . . . . . . . . 26 126 6.2.2. Location Response Message . . . . . . . . . . . . . . 29 127 6.3. Parlay/X . . . . . . . . . . . . . . . . . . . . . . . . . 29 128 6.3.1. getLocation Request Message . . . . . . . . . . . . . 31 129 6.3.2. getLocation Response Message . . . . . . . . . . . . . 31 130 6.3.3. getLocationForGroup Request Message . . . . . . . . . 31 131 6.3.4. getLocationForGroup Response Message . . . . . . . . . 31 132 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 31 133 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 32 134 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 135 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 136 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 137 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 140 1. Introduction 142 Over time, the increasing mobility of Internet endpoints, and the 143 global basis on which Internet applciations are delivered, have 144 driven demand for geolocation information about Internet hosts. In 145 order to respond to the demand, many different organizations have 146 developed geolocation platforms and protocols. For example, the SUPL 147 and MLP location protocols for cellular networks were developed in 148 the 3GPP and OMA, while the Parlay/X location protocol for tradional 149 fixed-line telephone networks was developed in ETSI. While many of 150 these protocols have matured idependently, because they are similiar 151 in purpose, the data models that they define are also similiar. 152 While the terminoligy for data elements may vary, the definitions are 153 often analogous, if not equivalent. Despite the clear overlap of 154 function, different protocols continue to be used independently, 155 perpetuating a fragmented marketplace for location services. 157 This fragmentation did not cause problems while the domains of 158 different protocols remained distinct. However, many different types 159 of networks, with their own "native" location protocols, are now 160 being used to carry IP traffic. At the same time, geolocation 161 functiosn are being introduced as core components of modern web 162 browsers and operating systems. These trends argue for a unification 163 of the current space of location protocols in order to facilitate 164 location services that are interoperable across the entire Internet. 166 Obviously, a proliferation of protocols has practical implications as 167 well. Without a single universal data model, developers are forced 168 to choose which protocols to use or support in their implemetations. 169 Server and client components have little re-usability and 170 interoperability across protocols. Transitioning from one protocol 171 to another is expensive and difficult. This is an unfortunate 172 situation, espescially because it could be avoided given the 173 similarities among protocols. In fact, if a universal data model is 174 agreed upon, and the process for mapping various protocols to and 175 from that data model is standardized, these problems can be resolved. 177 This document introduces a universal geolocation data model that will 178 meet the needs of the majority of exisiting protocols and be 179 extensible to accomodate future protocols. We call this universal 180 data model the Common Location Interoperability Framework, or CLIF. 182 This document also provides mappings of some exisiting geolocation 183 protocols to this data model. A main goal of these mappings is to 184 reduce confusion resulting from the use of different terminology to 185 mean the same thing in different specifications. 187 2. Definitions 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [1]. 193 3. Data Model Overview 195 CLIF has two top level message types: Request and Response. In both 196 'pull'- and 'push'-style systems, there is an entity that wants to 197 know location (requester or client) and an entity that provides 198 location (responder or server). The request object represents the 199 messages that originate from requesters, and likewise, the response 200 object represents messages originating from responders. 202 These two general message types satistfy the needs of many current 203 location location protocols. Protocols that use a request/response 204 message flow -- especially those that use HTTP as a transport -- are 205 of course naturally suited to this model, for example: 207 o HELD [ref:draft-ietf-geopriv-http-location-delivery] 209 o MLP [ref] 211 o Parlay/X [ref] (when used with "get"-style requests) 213 o Google Gears [ref] 215 . The data model also fits into protocols that use a subscribe/ 216 notify pattern, since such protocols can be thought of as a request 217 (subscription) followed by multiple responses (notifications): 219 o Parlay/X [ref] (when used with "notification"-style requests) 221 o LOCSIP [ref] 223 o SIMPLE [ref:RFC4079] 225 Geolocation platforms that depend on client-originated location 226 updates can also use this data model, e.g., to provide rough location 227 as an input to location determination. So this request/response 228 structured data model is flexible enough to fit into many different 229 types of protocols and message flows. 231 The request object contains any information that is necessary or 232 helpful for a location provider in determining the target's location. 233 This information includes, for example, identifiers for the target, 234 signal measurements, constraints on the response, callback URIs. 236 The response object contains location objects or error information 237 (or possibly both). In addition raw location information, a location 238 object typically contains an identifier for the target, a timestamp, 239 and possibly privacy rules. A response object does not necessarily 240 have to be used as a "response" in the underlying transport protocol 241 (e.g., in HTTP or SIP). Responses can be used by any entity that 242 wants to send a location object to another, e.g., a server sending an 243 unsolicited update to a client (as in a DHCP announcement). 245 4. Request parameters 247 This section defines a CLIF request object. 249 4.1. General 251 Parameters listed under "General" are top level parameters not 252 falling under any particular categorization. 254 4.1.1. Callback 256 Field name: callback 258 Data type: string (URI) 260 The "callback" parameter specifies a callback address to which the 261 location response should be sent. The value of this paramter is a 262 URI. In the case of a third-party location query, this field is used 263 to specify the address of the first-party device that is performing 264 the lookup on behalf of the third-party device. 266 4.1.2. Language 268 Field name: language 270 Data type: string 272 Value Space: two-character and three-character codes as specified in 273 ISO 639 275 The "language" parameter specifies a requested langauge for a 276 response containing a civic address. Language values should follow 277 two-character and three-character representations defined in 278 [ISO639]. 280 4.1.3. Response Accuracy 282 Field name: accuracy 284 Data type: int / double ? 286 Units: meters? 288 The "accuracy" parameter specifies the requested accuracy for a 289 response containing a geodetic address. 291 4.1.4. Response Age 293 Field name: maxAge 295 Data type: string (date-time) 297 The "maxAge" parameter defines the maximum age of the location in the 298 response. [How should tolerance of this request parameter be handled 299 if it cannot be satisfied? Let each implementation define it? Add 300 tolerance parameters?] 302 4.1.5. Response Time 304 Field name: responseTime 306 Data type: ? 308 The "responseTime" parameter defines the requested maximum response 309 time for the location provider to respond to the location request. 310 [How should this be represented?] 312 4.1.6. Response Location Type 314 Field name: locationType 316 Data type: byte 318 Format: Combination of bitmap flags according to table below: 320 +------+--------------------------------------+ 321 | Flag | Location Type | 322 +------+--------------------------------------+ 323 | ---1 | Geodetic Location Type Flag | 324 | --1- | Civic Location Type Flag | 325 | -1-- | Reference Location Type Flag | 326 | 1--- | Exact Modifier Flag | 327 | 1000 | Default Location Type (special case) | 328 +------+--------------------------------------+ 330 Table 1 332 These flags can be combined in any way. For example "-111" would ask 333 for all location types, while "-011" would ask for Geodetic and Civic 334 location types. Specifying no location types ("0000") is the 335 equivalent of asking for any available location type(s). 337 The "exact" modifier is used to specify how the location provider 338 should handle the other flags. Specifically, if the exact modifier 339 is set to 0 (false), then the location provider MUST provide the 340 requested location types in the response, but it MAY provide more. 341 If the exact modifier is set to 1 (true), the location provider MUST 342 provide exactly the types requested, no more or less, and it MUST 343 return an error if it cannot satisfy the request. 345 There is one special cases, indicated by "1000". If the location 346 provider sees this flag comination, it should simply follow its 347 default behavior. Note that this is slightly different from "0000," 348 which asks the locaiton provider to return any location type. For 349 example if a location provider's default behavior is to return 350 geodetic location only, then the "1000" flag would return a geodetic 351 location, whereas the "0000" flag might return both geodetic and 352 civic locations. 354 4.2. Identifiers 356 Identifiers are parameters that identify the device that is 357 requesting location. For third-party location queries, these should 358 describe the third-party device, not the first-party requester. That 359 is, if Device A requesting location on behalf of Device B, 360 identifiers should describe Device B, and Device A can be specified 361 via the "callback" parameter. A Location Request object can store 362 more that one Identifiers objects for cases where it is requesting 363 the location of multiple entities from the same location provider in 364 a single request. 366 4.2.1. Unique Identifier (UID) 368 Field name: uid 370 Data type: string 372 The "uid" parameter MAY be used to define any Unique Identifier 373 applicable to the protocol being represented, e.g., "DUID" for 374 location over DHCP. 376 A "uid" should not be confused with a network access identifier (see 377 NAI below). 379 4.2.2. Network Access Identifier (NAI) 381 Field name: accessUsername 383 Data type: string 385 To be used with protocols that require authentication ie, username, 386 user@domain (See [RFC4282] for full definition) 388 4.2.3. Network Access Password 390 Field name: accessPassword 392 Data type: string 394 Password associated with UNI for networks that require username/ 395 password authentication 397 4.2.4. Group Identifier 399 Field name: groupId 401 Data type: string 403 Format: any 405 The "group" parameter MAY be used to define a group/buddy list when 406 looking up a location for multiple users. This is used for third- 407 party requests. 409 4.2.5. IP Address 411 Field name: ip 413 Data type: string 414 The "ip" parameter stores IP address of the requester. 416 4.2.6. MAC Address 418 Field name: mac 420 Data type: string 422 The "mac" parameter stores the MAC address (bssid) of the requester. 424 4.2.7. Port Number 426 Field name: port 428 Data type: int 430 The "port" parameter MAY be used to specify the UDP or TCP Port being 431 used. This is useful for mulitple requesters running on same IP on 432 different ports. 434 4.2.8. URI 436 Field name: uri 438 Data type: string (URI) 440 A "uri" parameter can specify a uri that identifies the requester. 442 4.2.9. Fully Qualified Domain Name 444 Field name: fqdn 446 Data type: string 448 The fully qualified domain name of the requester can be stored in the 449 "fqdn" parameter. This should be a domain name that resolves to a 450 single device. ie, server-1.example.com. 452 4.2.10. Telephony 454 Data type: Telephony Object 456 The Telephony object contains fields to store various telephony 457 identifiers. 459 4.2.10.1. Mobile Station International Subscriber Dial Number (MSISDN) 461 Field name: msidn 463 Data type: string 465 Mobile Station International Subscriber Dial Number (MSISDN) 467 4.2.10.2. International Mobile Subscriber Identity (IMSI) 469 Field name: imsi 471 Data type: string 473 International Mobile Subscriber Identity (IMSI) - GSM / UMTS mobile 474 subscriber identifier 476 4.2.10.3. International Mobile Equipment Identifier (IMEI) 478 Field name: imei 480 Data type: string 482 International Mobile Equipment Identifier (IMEI) 484 4.2.10.4. Mobile Identification Number (MIN) 486 Field name: min 488 Data type: string 490 Mobile Identification Number (MIN) - a unique number associated with 491 CDMA devices 493 4.2.10.5. Mobile Directory Number (MDN) 495 Field name: mdn 497 Data type: string 499 Mobile Directory Number (MDN) - usage similar to MSISDN 501 4.2.10.6. Home Mobile Country Code 503 Field name: hmcc 505 Data type: string 506 Mobile country code for the device's home network. 508 4.2.10.7. Home Mobile Network Code 510 Field name: hmnc 512 Data type: string 514 Mobile network code for the device's home network. Used in 515 conjunction with home mcc. 517 4.3. Measurement 519 Data type: Object 521 The Measurement object contains fields to store various measurements 522 from the device. A request can have multiple Measurement objects. 523 Every type of Measurement object has a few parameters in common, 524 which objects that extend Measurement inherit: 526 4.3.1. Timestamp 528 Field name: timestamp 530 Data type: string 532 The time the measurement was recorded. 534 4.3.2. Expires 536 Field name: expires 538 Data type: string 540 The time the measurement expires. 542 4.3.3. Samples 544 Field name: samples 546 Data type: int 548 The total number of samples on which the measurement is based. 550 4.3.4. WifiMeasurement 552 Field name: WifiMeasurement 553 Data type: Object extends Measurement 555 Type of Measurement object for storing WiFi Data. 557 4.3.4.1. NIC Type 559 Field name: nicType 561 Data type: string 563 Identifies the NIC used for capturing the wifi measurements. 565 4.3.4.2. Wireless Access Point (WAP) 567 Field name: Wap 569 Data type: Object 571 A WifiMeasurement object was a Wap object as a parameter. A Wap 572 object describes signals from a wap the NIC sees. 574 4.3.4.2.1. SSID 576 Field name: ssid 578 Data type: string 580 The ssid the wap is broadcasting. 582 4.3.4.2.2. BSSID 584 Field name: bssid 586 Data type: string 588 The bssid (MAC address) of the wap. 590 4.3.4.2.3. Access Point Name 592 Field name: apName 594 Data type: string 596 The name of the wap. 598 4.3.4.2.4. WAP Location 600 Field name: location 602 Data type: gml 604 The location of the wap. 606 4.3.4.2.5. Type 608 Field name: type 610 Data type: enum{a|b|g|n} 612 The type of wifi signal the wap. 614 4.3.4.2.6. Channel 616 Field name: channel 618 Data type: int 620 The channel the wap is broadcasting on. 622 4.3.4.2.7. RSSI 624 Field name: rssi 626 Data type: int 628 Units: dBm 630 The radio signal strength indicator. 632 4.3.4.2.8. Signal to Noise Ratio 634 Field name: snr 636 Data type: double? 638 Units: dBm 640 The signal to noise ratio of the signal being broadcast by the wap. 642 4.3.4.2.9. Round Trip Time 644 Field name: rtt 645 Data type: int? 647 Units: milliseconds? 649 From section-4.4 of [draft-thomson-geopriv-held-measurements-05]: 650 "The The total round trip time from the time that a request is sent 651 by the device to the time that it receives the response from the 652 access point." 654 4.3.5. CellularMeasurement 656 Field name: CellularMeasurement 658 Data type: Object extends Measurement 660 Type of Measurement object for storing Cellular Data. 662 4.3.5.1. Radio Type 664 Field name: radioType 666 Data type: string (possibly enum? e.g., gsm, cdma, wcdma, etc) 668 Identifies the cellular radio type. 670 4.3.5.2. Carrier 672 Field name: carrier 674 Data type: string 676 Identifies the cellular carrier by name. 678 4.3.5.3. Cellular Tower 680 Field name: Tower 682 Data type: Object 684 A CellularMeasurement object was a Tower object as a parameter. A 685 Tower object describes signals from a tower the cellular radio sees. 687 4.3.5.3.1. Mobile Country Code 689 Field name: mcc 691 Data type: int 693 4.3.5.3.2. Mobile Network Code 695 Field name: mnc 697 Data type: int 699 4.3.5.3.3. Cell Id 701 Field name: cid 703 Data type: int 705 4.3.5.3.4. 28-bit Cell Id 707 Field name: eucid 709 Data type: int 711 4.3.5.3.5. Radio Network Controller 713 Field name: rnc 715 Data type: int 717 4.3.5.3.6. Network Id 719 Field name: nid 721 Data type: int 723 4.3.5.3.7. System Id 725 Field name: sid 727 Data type: int 729 4.3.5.3.8. Base Station Id 731 Field name: baseid 733 Data type: int 735 4.3.5.3.9. RSSI 737 Field name: rssi 739 Data type: int 740 Units: dBm 742 The radio signal strength indicator. 744 4.3.5.3.10. Timing Advance 746 Field name: timingAdvance 748 Data type: int 750 Units: ms 752 4.3.6. WiMAX 754 Measurement object for storing WiMAX Data 756 4.3.7. GNSS 758 Measurement object for storing GNSS Data 760 4.3.8. w16e 762 Measurement object for storing w16e Data 764 4.4. Other parameters 766 Describe how CLIF can be extended here. 768 5. Response parameters 770 This section defines a CLIF response object. 772 5.1. General parameters 774 Parameters listed under "General" are top level parameters not 775 falling under any particular categorization. 777 5.1.1. Message 779 Field name: message 781 Data type: string 783 The "message" field contains any relavant report / status messages 784 from the location provider. 786 5.1.2. Age 788 Field name: age 790 Data type: string 792 The date-time the location was discovered. 794 5.1.3. Unique Identifer (UID) 796 Field name: age 798 Data type: string 800 The "uid" field in the response object can store a unique identifier 801 or access token assigned by the location provider for the requester 802 to use for future queries. 804 5.2. Location Reference 806 Field name: uri 808 Data type: string (URI) 810 The "uri" field in the response object can store a reference to a 811 location. A response may have multiple Location References in an 812 array. 814 5.3. Location Oject [PIDF-LO] 816 The Location object is based on PIDF-LO. 818 5.3.1. Geodetic location 820 5.3.2. Civic location 822 5.4. Error 824 Error Parameters: 826 5.4.1. Error Code 828 Field name: code 830 Data type: string 832 The "code" field stores an error code from the location provider. 834 5.4.2. Error Message 836 Field name: message 838 Data type: string 840 The "message" field stores an error message from the location 841 provider. This field SHOULD be human readable text. 843 6. Protocol mapping summary 845 This section provides mapping between Geolocation Protocols and CLIF. 847 This table shows how protocols share elements with CLIF: 849 +-----------------------------------------+------+-------+----------+ 850 | CLIF Request | HELD | Gears | Parlay/X | 851 +-----------------------------------------+------+-------+----------+ 852 | callback | | | o | 853 | language | | o | | 854 | accuracy | | | o | 855 | maxAge | | | o | 856 | responseTime | | | o | 857 | locationType | o | o | | 858 | Identifiers:uid | o | o | o | 859 | Identifiers:accessUsername | o | | | 860 | Identifiers:accessPassword | | | | 861 | Identifiers:ip | o | | | 862 | Identifiers:mac | o | | | 863 | Identifiers:port | o | | | 864 | Identifiers:uri | o | | o | 865 | Identifiers:fqdn | o | | | 866 | Identifiers:Telephony | | | | 867 | Identifiers:Telephony:msisdn | o | | | 868 | Identifiers:Telephony:imsi | o | | | 869 | Identifiers:Telephony:imei | o | | | 870 | Identifiers:Telephony:min | o | | | 871 | Identifiers:Telephony:mdn | o | | | 872 | Identifiers:Telephony:hmcc | | o | | 873 | Identifiers:Telephony:hmnc | | o | | 874 | Measurement | | | | 875 | Measurement:time | | o | | 876 | Measurement:expires | | | | 877 | Measurement:samples | | | | 878 | WifiMeasurement::Measurement | o | o | | 879 | WifiMeasurement:nicType | o | | | 880 | WifiMeasurement:wap | o | o | | 881 | WifiMeasurement:wap:ssid | o | | | 882 | WifiMeasurement:wap:bssid | o | o | | 883 | WifiMeasurement:wap:apName | o | | | 884 | WifiMeasurement:wap:location | o | | | 885 | WifiMeasurement:wap:type | o | | | 886 | WifiMeasurement:wap:channel | o | o | | 887 | WifiMeasurement:wap:rssi | o | o | | 888 | WifiMeasurement:wap:snr | o | o | | 889 | WifiMeasurement:wap:rtt | o | | | 890 | CellularMeasurement::Measurement | o | o | | 891 | CellularMeasurement:radioType | | o | | 892 | CellularMeasurement:carrier | | o | | 893 | CellularMeasurement:tower | o | | | 894 | CellularMeasurement:tower:mcc | o | o | | 895 | CellularMeasurement:tower:mnc | o | o | | 896 | CellularMeasurement:tower:cid | o | o | | 897 | CellularMeasurement:tower:eucid | o | | | 898 | CellularMeasurement:tower:rnc | o | | | 899 | CellularMeasurement:tower:lac | o | o | | 900 | CellularMeasurement:tower:nid | o | | | 901 | CellularMeasurement:tower:sid | o | | | 902 | CellularMeasurement:tower:baseid | o | | | 903 | CellularMeasurement:tower:rssi | | o | | 904 | CellularMeasurement:tower:timingAdvance | | o | | 905 +-----------------------------------------+------+-------+----------+ 907 Table 2 909 +-------------------------+------+-------+----------+ 910 | CLIF Response | HELD | Gears | Parlay/X | 911 +-------------------------+------+-------+----------+ 912 | message | | | o | 913 | uid | | o | o | 914 | age | | | o | 915 | uri | o | | | 916 | location | o | | | 917 | location:geo | o | o | o | 918 | location:civic | o | o | | 919 | location:civic:language | o | | | 920 | location:civic:country | o | o | | 921 | location:civic:a1 | o | o | | 922 | location:civic:a2 | o | o | | 923 | location:civic:a3 | o | o | | 924 | location:civic:a4 | o | | | 925 | location:civic:a5 | o | | | 926 | location:civic:a6 | o | o | | 927 | location:civic:prd | o | | | 928 | location:civic:pod | o | | | 929 | location:civic:sts | o | | | 930 | location:civic:hno | o | o | | 931 | location:civic:hns | o | | | 932 | location:civic:lmk | o | | | 933 | location:civic:loc | o | | | 934 | location:civic:name | o | | | 935 | location:civic:pc | o | o | | 936 | location:civic:bld | o | o | | 937 | location:civic:unit | o | | | 938 | location:civic:flr | o | | | 939 | location:civic:room | o | | | 940 | location:civic:plc | o | | | 941 | location:civic:pcn | o | | | 942 | location:civic:pobox | o | | | 943 | location:civic:addcode | o | | | 944 | location:civic:seat | o | | | 945 | location:civic:rd | o | | | 946 | location:civic:rdsec | o | | | 947 | location:civic:rdbr | o | | | 948 | location:civic:rdsubbr | o | | | 949 | location:civic:prm | o | | | 950 | location:civic:pom | o | | | 951 | location:reference | o | | | 952 | location:reference:uris | o | | | 953 | Error | o | | | 954 | Error:code | o | | o | 955 | Error:message | o | | | 956 +-------------------------+------+-------+----------+ 958 Table 3 960 6.1. HELD 962 This section will focus on how to use CLIF with the HELD protocol. 964 +--------------------------------------+----------------------------+ 965 | CLIF Request | HELD | 966 +--------------------------------------+----------------------------+ 967 | callback | | 968 | language | | 969 | accuracy | | 970 | maxAge | | 971 | responseTime | | 972 | locationType | locationType | 973 | Identifiers:uid | Identifiers:duid | 974 | Identifiers:accessUsername | Identifiers:nai | 975 | Identifiers:accessPassword | | 976 | Identifiers:ip | Identifiers:ip | 977 | Identifiers:mac | Identifiers:mac | 978 | Identifiers:port | Identifiers:tcpport,udppor | 979 | | t | 980 | Identifiers:uri | Identifiers:uri | 981 | Identifiers:fqdn | Identifiers:fqdn | 982 | Identifiers:Telephony | | 983 | Identifiers:Telephony:msisdn | Identifiers:msisdn | 984 | Identifiers:Telephony:imsi | Identifiers:imsi | 985 | Identifiers:Telephony:imei | Identifiers:imei | 986 | Identifiers:Telephony:min | Identifiers:min | 987 | Identifiers:Telephony:mdn | Identifiers:mdn | 988 | Identifiers:Telephony:hmcc | | 989 | Identifiers:Telephony:hmnc | | 990 | Measurement | | 991 | Measurement:time | | 992 | Measurement:expires | | 993 | Measurement:samples | | 994 | WifiMeasurement::Measurement | | 995 | WifiMeasurement:nicType | | 996 | WifiMeasurement:wap | | 997 | WifiMeasurement:wap:ssid | | 998 | WifiMeasurement:wap:bssid | | 999 | WifiMeasurement:wap:apName | | 1000 | WifiMeasurement:wap:location | | 1001 | WifiMeasurement:wap:type | | 1002 | WifiMeasurement:wap:channel | | 1003 | WifiMeasurement:wap:rssi | | 1004 | WifiMeasurement:wap:snr | | 1005 | WifiMeasurement:wap:rtt | | 1006 | CellularMeasurement::Measurement | | 1007 | CellularMeasurement:radioType | | 1008 | CellularMeasurement:carrier | | 1009 | CellularMeasurement:tower | | 1010 | CellularMeasurement:tower:mcc | | 1011 | CellularMeasurement:tower:mnc | | 1012 | CellularMeasurement:tower:cid | | 1013 | CellularMeasurement:tower:eucid | | 1014 | CellularMeasurement:tower:rnc | | 1015 | CellularMeasurement:tower:lac | | 1016 | CellularMeasurement:tower:nid | | 1017 | CellularMeasurement:tower:sid | | 1018 | CellularMeasurement:tower:baseid | | 1019 | CellularMeasurement:tower:rssi | | 1020 | CellularMeasurement:tower:timingAdva | | 1021 | n ce | | 1022 +--------------------------------------+----------------------------+ 1024 Table 4 1026 +---------------+------------------+ 1027 | CLIF Response | HELD | 1028 +---------------+------------------+ 1029 | message | | 1030 | uid | | 1031 | age | | 1032 | uri | locationUriSet | 1033 | location | presence PIDF-LO | 1034 | Error | | 1035 | Error:code | Error:code | 1036 | Error:message | Error:message | 1037 +---------------+------------------+ 1039 Table 5 1041 6.1.1. Location Request Message 1043 This section will focus on how to encode/decode a HELD Location 1044 Request message using CLIF. 1046 6.1.2. Location Response Message 1048 This section will focus on how to encode/decode a HELD Location 1049 Response message using CLIF. 1051 6.1.3. Error Message 1053 This section will focus on how to encode/decode a HELD Error message 1054 using CLIF. 1056 6.2. Google Gears 1058 This section will focus on how to use CLIF with the Google Gears 1059 Geolocation network protocol. 1061 +-----------------------------------------+---------------------+ 1062 | CLIF Request | Gears | 1063 +-----------------------------------------+---------------------+ 1064 | callback | | 1065 | language | address_language | 1066 | accuracy | | 1067 | maxAge | | 1068 | responseTime | | 1069 | locationType | request_address | 1070 | Identifiers:uid | access_token | 1071 | Identifiers:accessUsername | | 1072 | Identifiers:accessPassword | | 1073 | Identifiers:ip | | 1074 | Identifiers:mac | | 1075 | Identifiers:port | | 1076 | Identifiers:uri | | 1077 | Identifiers:fqdn | | 1078 | Identifiers:Telephony | | 1079 | Identifiers:Telephony:msisdn | | 1080 | Identifiers:Telephony:imsi | | 1081 | Identifiers:Telephony:imei | | 1082 | Identifiers:Telephony:min | | 1083 | Identifiers:Telephony:mdn | | 1084 | Identifiers:Telephony:hmcc | | 1085 | Identifiers:Telephony:hmnc | | 1086 | Measurement | | 1087 | Measurement:time | age | 1088 | Measurement:expires | | 1089 | Measurement:samples | | 1090 | WifiMeasurement::Measurement | [WiFi Data Object] | 1091 | WifiMeasurement:nicType | | 1092 | WifiMeasurement:wap | | 1093 | WifiMeasurement:wap:ssid | | 1094 | WifiMeasurement:wap:bssid | mac-address | 1095 | WifiMeasurement:wap:apName | | 1096 | WifiMeasurement:wap:location | | 1097 | WifiMeasurement:wap:type | | 1098 | WifiMeasurement:wap:channel | channel | 1099 | WifiMeasurement:wap:rssi | signal_strength | 1100 | WifiMeasurement:wap:snr | signal_to_noise | 1101 | WifiMeasurement:wap:rtt | | 1102 | CellularMeasurement::Measurement | [Cell Data Object] | 1103 | CellularMeasurement:radioType | radio_type | 1104 | CellularMeasurement:carrier | carrier | 1105 | CellularMeasurement:tower | | 1106 | CellularMeasurement:tower:mcc | mobile_country_code | 1107 | CellularMeasurement:tower:mnc | mobile_network_code | 1108 | CellularMeasurement:tower:cid | cell_id | 1109 | CellularMeasurement:tower:eucid | | 1110 | CellularMeasurement:tower:rnc | | 1111 | CellularMeasurement:tower:lac | location_area_code | 1112 | CellularMeasurement:tower:nid | | 1113 | CellularMeasurement:tower:sid | | 1114 | CellularMeasurement:tower:baseid | | 1115 | CellularMeasurement:tower:rssi | signal_strength | 1116 | CellularMeasurement:tower:timingAdvance | timing_advance | 1117 +-----------------------------------------+---------------------+ 1119 Table 6 1121 +-------------------------+--------------------------+ 1122 | CLIF Response | Gears | 1123 +-------------------------+--------------------------+ 1124 | message | | 1125 | uid | access_token | 1126 | age | | 1127 | uri | | 1128 | location | | 1129 | location:geo | Response location fields | 1130 | location:civic | | 1131 | location:civic:language | | 1132 | location:civic:country | address:country | 1133 | location:civic:a1 | address:region | 1134 | location:civic:a2 | address:county | 1135 | location:civic:a3 | address:city | 1136 | location:civic:a4 | | 1137 | location:civic:a5 | | 1138 | location:civic:a6 | address:street | 1139 | location:civic:prd | | 1140 | location:civic:pod | | 1141 | location:civic:sts | | 1142 | location:civic:hno | address:street_number | 1143 | location:civic:hns | | 1144 | location:civic:lmk | | 1145 | location:civic:loc | | 1146 | location:civic:name | | 1147 | location:civic:pc | address:postal_code | 1148 | location:civic:bld | address:premises | 1149 | location:civic:unit | | 1150 | location:civic:flr | | 1151 | location:civic:room | | 1152 | location:civic:plc | | 1153 | location:civic:pcn | | 1154 | location:civic:pobox | | 1155 | location:civic:addcode | | 1156 | location:civic:seat | | 1157 | location:civic:rd | | 1158 | location:civic:rdsec | | 1159 | location:civic:rdbr | | 1160 | location:civic:rdsubbr | | 1161 | location:civic:prm | | 1162 | location:civic:pom | | 1163 | location:reference | | 1164 | location:reference:uris | | 1165 | Error | | 1166 | Error:code | | 1167 | Error:message | | 1168 +-------------------------+--------------------------+ 1169 Table 7 1171 6.2.1. Location Request Message 1173 This section will focus on how to encode/decode a Gears Location 1174 Request message using CLIF. 1176 Here is an example of a Gears Location Request message: 1178 { 1179 "version": "1.1.0", 1180 "host": "maps.google.com", 1181 "access_token": "2:k7j3G6LaL6u_lafw:4iXOeOpTh1glSXe", 1182 "home_mobile_country_code": 310, 1183 "home_mobile_network_code": 410, 1184 "radio_type": "gsm", 1185 "carrier": "Vodafone", 1186 "request_address": true, 1187 "address_language": "en_GB", 1188 "location": { 1189 "latitude": 51.0, 1190 "longitude": -0.1 1191 }, 1192 "cell_towers": [ 1193 { "cell_id": 42, 1194 "location_area_code": 415, 1195 "mobile_country_code": 310, 1196 "mobile_network_code": 410, 1197 "age": 0, 1198 "signal_strength": -60, 1199 "timing_advance": 5555 1200 }, 1201 { "cell_id": 88, 1202 "location_area_code": 415, 1203 "mobile_country_code": 310, 1204 "mobile_network_code": 580, 1205 "age": 0, 1206 "signal_strength": -70, 1207 "timing_advance": 7777 1208 } 1209 ], 1210 "wifi_towers": [ 1211 { "mac_address": "01-23-45-67-89-ab", 1212 "signal_strength": 8, 1213 "age": 0 1214 }, 1215 { "mac_address": "01-23-45-67-89-ac", 1216 "signal_strength": 4, 1217 "age": 0 1218 } 1219 ] 1220 } 1222 Figure 1: Gears Location Request Message 1223 [http://code.google.com/apis/gears/geolocation_network_protocol.html] 1224 Specifications for encoding/decoding fields in the Gears Location 1225 Request: 1227 version: The Gears "version" parameter is specific to the Google 1228 Gears protocol and therefore does not get stored in the CLIF 1229 model. When encoding a Google Gears request from a CLIF request 1230 object, the encoder MUST generate the version parameter on its 1231 own. When decoding a Google Gears request and storing the data in 1232 a CLIF object, the decoder MUST not store the version number in 1233 the model, though it MAY choose to store or use it outside CLIF 1234 for some application-specific purpose. 1236 host: The Gears "host" parameter is specific to the Google Gears 1237 protocol and therefore does not get stored in the CLIF model. 1238 When encoding a Google Gears request from a CLIF request object, 1239 the encoder MUST generate the host parameter on its own. When 1240 decoding a Google Gears request, the decoder MUST not store the 1241 host parameter in a CLIF object, though it MAY choose to store or 1242 use it outside CLIF for some application-specific purpose. 1244 access_token: The Gears "access_token" parameter MAY be stored in 1245 the Identifiers:uid field of the CLIF request object. In the 1246 Gears protocol, this parameter is set by the server in a response 1247 message to be used for future requests. Therefore, if this field 1248 is empty in the CLIF model, a Gears encoder MUST NOT attempt to 1249 generate it. If the encoder has an access_token that was 1250 generated by a Gears server to use for requests, it SHOULD insert 1251 this access_token into requests and ignore the Identifiers:uid 1252 field. If the encoder does not have its own Gears access_token, 1253 it MAY check the Identifiers:uid field for an access_token, but it 1254 MUST verify that any value stored in this field is a valid Gears 1255 access_tokn, as this field can store other unique identifiers. An 1256 example of a situation where it would be safe for the encoder to 1257 use the Identifiers:uid field as a Gears access_token would be 1258 when it has full knowledge of how this field was propogated and 1259 knows that it is being used to store Gears access_tokes (e.g., a 1260 decoder accepting only Gears location requests). A Gears decoder 1261 MAY store the access_token value in the Identifiers:uid field when 1262 decoding a Gears request. 1264 home_mobile_country_code: The Gears "home_mobile_country_code" 1265 parameter MUST be stored in the Identifiers:Telephony:hmcc field 1266 of the CLIF request object. An encoder can check this field when 1267 encoding a Gears Location Request message, and if it has a value 1268 it MAY encode it as the value for the home_mobile_country_code 1269 parameter in the Gears request. When decoding a Gears Location 1270 Request message, a home_mobile_country_code MUST be stored in the 1271 Identifiers:Telephony:hmcc field of the CLIF request object. 1273 home_mobile_network_code: The Gears "home_mobile_network_code" 1274 parameter MUST be stored in the Identifiers:Telephony:hmnc field 1275 of the CLIF request object. An encoder can check this field when 1276 encoding a Gears Location Request message, and if it has a value 1277 it MAY encode it as the value for the home_mobile_network_code 1278 parameter in the Gears request. When decoding a Gears Location 1279 Request message, a home_mobile_network_code MUST be stored in the 1280 Identifiers:Telephony:hmnc field of the CLIF request object. 1282 radio_type: 1284 carrier: 1286 request_address: 1288 address_language: 1290 location: 1292 latitude: 1294 longitude: 1296 cell_towers: 1298 wifi_towers: 1300 6.2.2. Location Response Message 1302 This section will focus on how to encode/decode a Gears Location 1303 Response message using CLIF request object. 1305 6.3. Parlay/X 1307 This section will focus on how to use CLIF request object with the 1308 Parlay/X protocol. 1310 +------------------------------+------------------------------------+ 1311 | CLIF Request | Parlay/X | 1312 +------------------------------+------------------------------------+ 1313 | callback | requester | 1314 | language | | 1315 | accuracy | requestedAccuracy, | 1316 | | acceptableAccuracy | 1317 | maxAge | maximumAge | 1318 | responseTime | responseTime | 1319 | locationType | | 1320 | Identifiers:uid | reference, correlator | 1321 | Identifiers:accessUsername | | 1322 | Identifiers:accessPassword | | 1323 | Identifiers:ip | | 1324 | Identifiers:mac | | 1325 | Identifiers:port | | 1326 | Identifiers:uri | address | 1327 | Identifiers:fqdn | | 1328 | Identifiers:Telephony | | 1329 | Identifiers:Telephony:msisdn | | 1330 | Identifiers:Telephony:imsi | | 1331 | Identifiers:Telephony:imei | | 1332 | Identifiers:Telephony:min | | 1333 | Identifiers:Telephony:mdn | | 1334 | Identifiers:Telephony:hmcc | | 1335 | Identifiers:Telephony:hmnc | | 1336 +------------------------------+------------------------------------+ 1338 Table 8 1340 +----------------+---------------------------------------+ 1341 | CLIF Response | Parlay/X | 1342 +----------------+---------------------------------------+ 1343 | message | LocationData:reportStatus | 1344 | uid | correlator | 1345 | age | LocationInfo:timestamp | 1346 | uri | | 1347 | location | | 1348 | location:geo | LocationInfo | 1349 | location:civic | | 1350 | Error | | 1351 | Error:code | reason, LocationData:errorInformation | 1352 | Error:message | | 1353 +----------------+---------------------------------------+ 1355 Table 9 1357 6.3.1. getLocation Request Message 1359 This section will focus on how to encode/decode a Parlay/X 1360 getLocation Request using the CLIF. 1362 6.3.2. getLocation Response Message 1364 This section will focus on how to encode/decode a Parlay/X 1365 getLocation Response using CLIF. 1367 6.3.3. getLocationForGroup Request Message 1369 This section will focus on how to encode/decode a Parlay/X 1370 getLocationForGroup Request using CLIF. 1372 6.3.4. getLocationForGroup Response Message 1374 This section will focus on how to encode/decode a Parlay/X 1375 getLocationForGroup Response using CLIF. 1377 7. Applications 1379 This section provides use cases for CLIF: 1381 o Implementing Single Protocol [Protocol A] Client 1383 * Pre-designed, pre-implemented data model - developers will not 1384 have to design and implement their own 1386 * The client is already designed to support additional protocols 1387 if they are later added 1389 o Implementing Multiple Protocol [Protocols A, B, C] Client 1391 * Single Data Model, Multiple Protocols 1393 o Transitioning from Protocol A to Protocol B 1395 * Mapping in this docuemnt provides instructions for how to map 1396 Protocol A to CLIF to Protocol B 1398 * All Protocol A code / components / assets can still be used, 1399 just add a translation layer 1401 o Reusing Server Components 1403 * A location server can accept multiple protocols on the front- 1404 end, normalize them all to CLIF, allowing other parts of the 1405 server to be usable for all protocols (eg, logging, caching) 1407 o Interoperability of Protocols 1409 * Implement a location server that accepts [Protocol A] Requests, 1410 in case of [Protocol A] failure, it degrades to use [Protocol 1411 B], and the translation / [Protocol B] query is done server- 1412 side, with the [Protocol B] response being translate back to 1413 [Protocol A] to send to the client. 1415 8. Privacy Considerations 1417 [Text here] 1419 9. Security Considerations 1421 [Text here] 1423 10. References 1425 10.1. Normative References 1427 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1428 Levels", BCP 14, RFC 2119, March 1997. 1430 [2] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 1431 J., and J. Rosenberg, "Common Policy: A Document Format for 1432 Expressing Privacy Preferences", RFC 4745, February 2007. 1434 [3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1435 January 2004. 1437 [4] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 1438 J. Polk, "Geolocation Policy: A Document Format for Expressing 1439 Privacy Preferences for Location Information", 1440 draft-ietf-geopriv-policy-21 (work in progress), January 2010. 1442 [5] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP 1443 Enabled Location Delivery (HELD)", 1444 draft-ietf-geopriv-http-location-delivery-16 (work in 1445 progress), August 2009. 1447 [6] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and 1448 IPv6 Option for a Location Uniform Resource Identifier (URI)", 1449 draft-ietf-geopriv-dhcp-lbyr-uri-option-07 (work in progress), 1450 March 2010. 1452 10.2. Informative References 1454 [7] Peterson, J., "A Presence-based GEOPRIV Location Object 1455 Format", RFC 4119, December 2005. 1457 [8] Peterson, J., Hardie, T., and J. Morris, "Implications of 1458 'retransmission-allowed' for SIP Location Conveyance", 1459 RFC 5606, August 2009. 1461 [9] Marshall, R., "Requirements for a Location-by-Reference 1462 Mechanism", draft-ietf-geopriv-lbyr-requirements-09 (work in 1463 progress), November 2009. 1465 [10] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1466 Configuration Protocol; Problem Statement and Requirements", 1467 draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009. 1469 [11] Polk, J., Schnizlein, J., Linsner, M., Thomson, M., and B. 1470 Aboba, "Dynamic Host Configuration Protocol Options for 1471 Coordinate-based Location Configuration Information", 1472 draft-ietf-geopriv-rfc3825bis-09 (work in progress), 1473 March 2010. 1475 Authors' Addresses 1477 Kevin M. Doran 1478 BBN Technologies 1479 9861 Broken Land Parkway 1480 Columbia, MD 21046 1481 US 1483 Phone: +1 410 290 6175 1484 Email: kdoran@bbn.com 1486 Richard L. Barnes 1487 BBN Technologies 1488 9861 Broken Land Parkway 1489 Columbia, MD 21046 1490 US 1492 Phone: +1 410 290 6169 1493 Email: rbarnes@bbn.com