idnits 2.17.00 (12 Aug 2021) /tmp/idnits13407/draft-thomson-geopriv-location-quality-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 626. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 27, 2008) is 5107 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: A later version (-08) exists of draft-thomson-geopriv-uncertainty-00 ** Downref: Normative reference to an Informational draft: draft-thomson-geopriv-uncertainty (ref. 'I-D.thomson-geopriv-uncertainty') == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft J. Winterbottom 4 Intended status: Standards Track Andrew 5 Expires: November 28, 2008 May 27, 2008 7 Specifying Location Quality Constraints in Location Protocols 8 draft-thomson-geopriv-location-quality-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 28, 2008. 35 Abstract 37 Parameters that define the expected quality of location information 38 are defined for use in location protocols. These parameter can be 39 used by a requester to indicate to a Location Server the desired 40 constraints on the quality of the location information provided. If 41 applicable, the Location Server is able to use this information to 42 control how location information is determined. An optional 43 indication of whether the quality constraints were met is defined to 44 be provided by the Location Server alongside location information. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Conventions used in this document . . . . . . . . . . . . 4 50 2. Location Quality Operation . . . . . . . . . . . . . . . . . . 5 51 3. Location Quality Objects . . . . . . . . . . . . . . . . . . . 6 52 3.1. Location Quality Request . . . . . . . . . . . . . . . . . 6 53 3.1.1. Maximum Uncertainty . . . . . . . . . . . . . . . . . 6 54 3.1.2. Required Civic Elements . . . . . . . . . . . . . . . 7 55 3.1.3. Maximum Age . . . . . . . . . . . . . . . . . . . . . 8 56 3.2. Location Quality Indication . . . . . . . . . . . . . . . 8 57 4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 10 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 60 6.1. URN Sub-Namespace Registration for 61 urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 14 62 6.2. XML Schema Registration for Location Quality Schema . . . 14 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 67 Intellectual Property and Copyright Statements . . . . . . . . . . 19 69 1. Introduction 71 Location determination methods produce results of varying accuracy. 72 In general, the accuracy of location information increases as the 73 effort expended in generating the information increases. Accuracy is 74 the primary aspect of the quality of location information that is 75 relevant to a Location Recipient (LR), but other aspects of quality 76 can also be significant, such as the currency of the data. 78 This document provides XML extension objects that can be added to any 79 protocol that provides location information. These elements provide 80 the ability to communicate location quality constraints to the 81 location server. 83 This document provides semantics, examples and security 84 considerations for the HELD protocol 85 [I-D.ietf-geopriv-http-location-delivery]. Application of the 86 parameters described in this document to other protocols is out of 87 scope. 89 Means for expressing the quality of location information is outlined 90 in [I-D.thomson-geopriv-uncertainty] and [GeoShape]. An entity 91 requesting location information of a Location Server (LS) is unable 92 to specify the quality of the location that it ultimately receives. 93 This is inefficient because an LS either provides location 94 information that is inadequate for the intended task; or the LS could 95 waste resources generating location information that is of 96 eccessively high quality. 98 This document describes an optional HELD parameter that communicates 99 location quality constraints to an LS. These constraints specify a 100 desired uncertainty at a certain confidence, plus the maximum 101 acceptable age where location information is stored. Guidelines for 102 deterministically evaluating location information against these rules 103 are provided. 105 Some of the benefits of providing an LS with location quality 106 constraints are described in [I-D.busin-geopriv-location-qos-req]. 107 Location quality constraints provide information that an LS can use 108 in deciding how to generate location information, if the LS uses a 109 Location Generator as a source of location information. This is the 110 case for a Location Information Server (LIS) and the HELD protocol. 111 For example, a LIS that is able to provide a location estimate with a 112 sufficiently small uncertainty might be able to provide a response 113 before the time indicated within the time indicated in the request 114 (the "responseTime"). 116 This document also provides a means by which the LS is able to 117 indicate if the location quality meets the constraints. These 118 parameters can be used by a Location Recipient to ensure that the 119 location is of adequate quality without requiring specific checking 120 (although the PIDF-LO should include sufficient information to 121 perform this check). Response parameters are optional; the presence 122 of a quality indication in the response also indicates that the LS 123 has understood the location quality constraints. 125 This document provides solutions that address a subset of the 126 requirements in [I-D.busin-geopriv-location-qos-req]. 128 1.1. Conventions used in this document 130 Terms and procedures relating to uncertainty and confidence are taken 131 from [I-D.thomson-geopriv-uncertainty]. Familiarity with terminology 132 outlined in [I-D.ietf-geopriv-l7-lcp-ps] and [RFC3693] is also 133 assumed. 135 The term Location Server (LS) is used as a generic label, since these 136 paramters apply in all cases where location information is served to 137 a requesting entity. From the perspective of this document, the LS 138 could be a Location Information Server (LIS). Similarly, the term 139 Location Recipient (LR) is used to refer to the requester of location 140 information, which could be a Device or Target for HELD. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 2. Location Quality Operation 148 Location quality parameters are provided by a Device or any other 149 client of an LS in a location request message. Figure 1 shows an 150 example message. 152 153 geodetic 154 155 156 150 157 1000 158 159 2008-05-27T05:47:55Z 160 161 163 Figure 1: Example HELD Location Request 165 A LS that supports the location quality element uses the information 166 contained in the request to choose how it serves the query. The 167 response to this message contains a quality indicator element that 168 includes a list of the quality constraints that were met. Figure 2 169 shows a location response that includes a quality indicator. 171 172 174 175 176 177 maxUncertainty/vertical maxAge 178 179 181 Figure 2: Example HELD Location Response 183 A LS doesn't indicate the quality of the location estimate in the 184 quality indicator; quality information is included in the PIDF-LO. 185 The quality indicator provides notice to its recipient that the 186 requested quality was provided. 188 3. Location Quality Objects 190 This section defines the format and semantics of the location quality 191 parameters for requests and the indication that is included with 192 responses. 194 3.1. Location Quality Request 196 The "quality" element is included in a HELD request to indicate the 197 constraints set by the Location Recipient (LR) on the quality of 198 returned location information. This document defines three elements 199 that are included. 201 3.1.1. Maximum Uncertainty 203 The "maxUncertainty" element describes an upper limit on uncertainty 204 at a given confidence. Uncertainty is divided in to horizontal and 205 vertical components. Horizontal uncertainty is the maximum distance 206 from the centroid of the area to the point in the shape furthest from 207 the centroid on the horizontal plane. Vertical uncertainty is the 208 difference in altitude from the centroid to the point in the shape 209 with the greatest altitude. 211 Note: An LS MAY provide location information using the Point shape 212 and indicate that the requested uncertainty is met providing that 213 the LS has access to uncertainty information. However, this is 214 NOT RECOMMENDED since the LR has no way of verifying that the 215 uncertainty meets their requirements. 217 The "horizontal" and "vertical" elements are numerical values that 218 contain a decimal value in meters. Maximum uncertainty values MUST 219 be greater than zero. 221 A location estimate that does not contain uncertainty (i.e. a Point 222 shape), never meets location quality constraints. Where uncertainty 223 is unknown, it MUST be assumed to be infinite at any non-zero 224 confidence. In particular, this applies to vertical uncertainty 225 where the location estimate is two-dimensional only; location 226 estimates without a vertical component of uncertainty never meet 227 vertical uncertainty constraints. 229 The "confidence" attribute of this element includes the confidence 230 level (expressed as a percentage) that the uncertainty is evaluated 231 at. Confidence is set to a default of 95%. 233 To evaluate uncertainty, the location estimate is first scaled so 234 that the confidence of the estimate matches (or exceeds) the 235 requested confidence. The LS MAY convert the shape of the 236 uncertainty to a circle or a sphere prior to scaling to simply the 237 scaling process. For consistency -- and contrary to the rules in 238 [I-D.thomson-geopriv-uncertainty] -- it is RECOMMENDED that a normal 239 PDF be used for all location information except where confidence is 240 reduced for a rectangular PDF. 242 Horizontal uncertainty is evalulated by removing the altitude and 243 altitude uncertainty components from the location estimate. While 244 removing altitude components from a location estimate might normally 245 increase confidence, confidence MUST NOT be increased at this step; 246 the confidence value has already been considered. The shape is then 247 converted to a circle, if it is not already in that shape. The 248 radius of the resulting circle is compared to the maximum horizontal 249 uncertainty. 251 Vertical uncertainty is evaluated for shapes that contain altitude 252 uncertainty. The value used for evaluating vertical uncertainty 253 depends on the shape type: the vertical axis value for the Ellipsoid 254 shape; the radius of the Sphere shape; half the height of the Prism 255 shape. 257 The LS MAY use location quality parameters to alter the way that it 258 generates location information and to provide location information 259 that more closely matches what is requested. If maximum value is 260 provided for vertical uncertainty, it is RECOMMENDED that the LS 261 provide a location estimate that includes altitude and altitude 262 uncertainty. It is RECOMMENDED that the LS provide location 263 information at the confidence included in the request, if possible 264 and if the location information is not significantly degraded by any 265 scaling that might be required to do this. 267 3.1.2. Required Civic Elements 269 The "requiredCivic" element represents the requirements of an LR for 270 civic address information. An LR can specify the address elements 271 that need to be present in the civic address in order for the 272 location information to meet their quality requirements. 274 The "requiredCivic" element contains a whitespace-separated list of 275 element names. These can be interpreted as XPath 276 [W3C.REC-xpath-19991116] expressions that are evaluated in the 277 context of the "civicAddress" element [RFC5139]. These XPath 278 statements are restricted to use of qualified names only (using the 279 response document namespace context) and the "/" separator; that is, 280 the only permitted axis is the "child::" axis. All child nodes of 281 elements (including attributes and textual content) are treated as 282 belonging to an element. 284 Figure 3 shows an example request where an LR requires country, state 285 (or equivalent) and post code civic address elements in the location 286 information provided by the LS. 288 289 291 ca:country ca:A1 ca:PC 292 293 295 Figure 3: Example Specifying Required Civic Address Fields 297 Note that this does not force the LS to restrict civic address 298 information to the indicated fields. Additional fields MAY be 299 provided. 301 3.1.3. Maximum Age 303 Where location information is stored or cached, an LR can specify a 304 limit on the age of this information. This is particularly important 305 if location information is generated in advance. The "age" of 306 location information is indicated by the the "timestamp" element in 307 the PIDF tuple. The age parameter specifies the minimum value for 308 this field; that is, the oldest location information that is 309 acceptable. 311 Location information that has greater age than requested SHOULD 312 either be determined anew, or checked so that the timestamp can be 313 updated. A value of "now" can be used to indicate that stored 314 location information is not acceptable to the LR. 316 3.2. Location Quality Indication 318 The "qualityInd" element is used in responses to indicate which of 319 the location quality constraints from a request were met. The 320 "qualityInd" element contains a list of the quality constraints that 321 the accompanying location information meets. 323 The list of constraints is represented as a whitespace-separated list 324 of element names. These can be interpreted as XPath 325 [W3C.REC-xpath-19991116] expressions that are evaluated in the 326 context of the original location quality request. These statements 327 follow the same constraints as the list of elements in Section 3.1.2. 329 Where elements are nested, such as the "maxUncertainty" element, the 330 outer element can be included to indicate an entire constraint is 331 met; or, each individual child element can be identified. Two 332 equivalent indications are shown in Figure 4. 334 335 maxUncertainty 336 338 339 maxUncertainty/horizontal maxUncertainty/vertical 340 342 Figure 4: Equivalent Quality Indications 344 A LS that is unable to determine if a constraint MUST either omit the 345 quality indication, or indicate that the constraint was not met. 347 Two special values are added to the quality indication element for 348 convenience. The value "##all" indicates that all quality 349 constraints were met (including any extensions). The value "##none" 350 indicates that none of the constraints were met. 352 4. Location Quality Schema 354 Note that the pattern rules in the following schema wrap due to 355 length constraints in RFC documents. None of the patterns contain 356 whitespace. 358 359 367 368 370 HELD Location Quality 371 372 373 375 This schema defines a framework for location quality requests 376 and indications of whether they are met. 377 378 380 382 383 384 385 386 387 388 389 390 392 393 394 395 396 397 399 400 401 402 403 404 405 406 407 409 410 411 413 414 415 416 417 419 420 421 422 423 424 426 428 429 430 431 432 433 434 435 436 437 438 440 441 442 443 444 447 449 450 451 453 455 5. Security Considerations 457 This document does not introduce any security considerations. 458 [[Editor's Note: Please let us know if you can think of some.]] 460 6. IANA Considerations 462 This section registers a namespace and schema for the location 463 quality objects. 465 6.1. URN Sub-Namespace Registration for 466 urn:ietf:params:xml:ns:geopriv:lq 468 This section registers a new XML namespace, 469 "urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in 470 [RFC3688]. 472 URI: urn:ietf:params:xml:ns:geopriv:lq 474 Registrant Contact: IETF, GEOPRIV working group, 475 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 477 XML: 479 BEGIN 480 481 483 484 485 Location Quality 486 487 488

Namespace for Location Quality

489

urn:ietf:params:xml:ns:geopriv:lq

490 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 491 with the RFC number for this specification.]] 492

See RFCXXXX.

493 494 495 END 497 6.2. XML Schema Registration for Location Quality Schema 499 This section registers an XML schema as per the guidelines in 500 [RFC3688]. 502 URI: urn:ietf:params:xml:schema:geopriv:lq 504 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 505 Martin Thomson (martin.thomson@andrew.com). 507 Schema: The XML for this schema can be found in Section 4 of this 508 document. 510 7. References 512 7.1. Normative References 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 518 January 2004. 520 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 521 Format for Presence Information Data Format Location 522 Object (PIDF-LO)", RFC 5139, February 2008. 524 [I-D.ietf-geopriv-http-location-delivery] 525 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 526 "HTTP Enabled Location Delivery (HELD)", 527 draft-ietf-geopriv-http-location-delivery-07 (work in 528 progress), April 2008. 530 [I-D.thomson-geopriv-uncertainty] 531 Thomson, M. and J. Winterbottom, "Representation of 532 Uncertainty and Confidence in PIDF-LO", 533 draft-thomson-geopriv-uncertainty-00 (work in progress), 534 November 2007. 536 7.2. Informative References 538 [W3C.REC-xpath-19991116] 539 Clark, J. and S. DeRose, "XML Path Language (XPath) 540 Version 1.0", World Wide Web Consortium 541 Recommendation REC-xpath-19991116, November 1999, 542 . 544 [I-D.busin-geopriv-location-qos-req] 545 Busin, A., Jin, Y., Mosmondor, M., and S. Loreto, 546 "Requirements for a Location Quality of Service (QoS) 547 Information Object", 548 draft-busin-geopriv-location-qos-req-01 (work in 549 progress), November 2007. 551 [I-D.ietf-geopriv-l7-lcp-ps] 552 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 553 Location Configuration Protocol; Problem Statement and 554 Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in 555 progress), March 2008. 557 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 558 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 560 [GeoShape] 561 Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 562 Application Schema for use by the Internet Engineering 563 Task Force (IETF)", Candidate OpenGIS Implementation 564 Specification 06-142r1, Version: 1.0, April 2007. 566 Authors' Addresses 568 Martin Thomson 569 Andrew 570 PO Box U40 571 Wollongong University Campus, NSW 2500 572 AU 574 Phone: +61 2 4221 2915 575 Email: martin.thomson@andrew.com 576 URI: http://www.andrew.com/ 578 James Winterbottom 579 Andrew 580 PO Box U40 581 Wollongong University Campus, NSW 2500 582 AU 584 Phone: +61 2 4221 2938 585 Email: james.winterbottom@andrew.com 586 URI: http://www.andrew.com/ 588 Full Copyright Statement 590 Copyright (C) The IETF Trust (2008). 592 This document is subject to the rights, licenses and restrictions 593 contained in BCP 78, and except as set forth therein, the authors 594 retain all their rights. 596 This document and the information contained herein are provided on an 597 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 598 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 599 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 600 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 601 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 602 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 604 Intellectual Property 606 The IETF takes no position regarding the validity or scope of any 607 Intellectual Property Rights or other rights that might be claimed to 608 pertain to the implementation or use of the technology described in 609 this document or the extent to which any license under such rights 610 might or might not be available; nor does it represent that it has 611 made any independent effort to identify any such rights. Information 612 on the procedures with respect to rights in RFC documents can be 613 found in BCP 78 and BCP 79. 615 Copies of IPR disclosures made to the IETF Secretariat and any 616 assurances of licenses to be made available, or the result of an 617 attempt made to obtain a general license or permission for the use of 618 such proprietary rights by implementers or users of this 619 specification can be obtained from the IETF on-line IPR repository at 620 http://www.ietf.org/ipr. 622 The IETF invites any interested party to bring to its attention any 623 copyrights, patents or patent applications, or other proprietary 624 rights that may cover technology that may be required to implement 625 this standard. Please address the information to the IETF at 626 ietf-ipr@ietf.org.