idnits 2.17.1 draft-thomson-geopriv-location-quality-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (June 28, 2011) is 4679 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: A later version (-08) exists of draft-thomson-geopriv-uncertainty-06 ** Downref: Normative reference to an Informational draft: draft-thomson-geopriv-uncertainty (ref. 'I-D.thomson-geopriv-uncertainty') == Outdated reference: A later version (-04) exists of draft-thomson-geopriv-confidence-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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 Corporation 5 Expires: December 30, 2011 June 28, 2011 7 Specifying Location Quality Requirements in Location Protocols 8 draft-thomson-geopriv-location-quality-08.txt 10 Abstract 12 Parameters that define the expected quality of location information 13 are defined for use in location protocols. These parameter can be 14 used by a requester to indicate to a Location Server quality 15 requirements for the location information that is requested. The 16 Location Server is able to use this information to control how 17 location information is determined. An optional indication of 18 whether the quality requirements were met is defined to be provided 19 by the Location Server alongside location information. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 30, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 4 57 2. Location Quality Operation . . . . . . . . . . . . . . . . . . 4 58 3. Location Quality Objects . . . . . . . . . . . . . . . . . . . 6 59 3.1. Location Quality Request . . . . . . . . . . . . . . . . . 6 60 3.1.1. Strict Quality Constraints . . . . . . . . . . . . . . 6 61 3.1.2. Maximum Uncertainty . . . . . . . . . . . . . . . . . 6 62 3.1.3. Required Civic Elements . . . . . . . . . . . . . . . 8 63 3.1.4. Maximum Age . . . . . . . . . . . . . . . . . . . . . 9 64 3.2. Location Quality Indication . . . . . . . . . . . . . . . 9 65 4. Location Quality Schema . . . . . . . . . . . . . . . . . . . 10 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. URN Sub-Namespace Registration for 69 urn:ietf:params:xml:ns:geopriv:lq . . . . . . . . . . . . 13 70 6.2. XML Schema Registration for Location Quality Schema . . . 13 71 6.3. Registration of HELD 'lowQuality' Error Code . . . . . . . 14 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 Location determination methods produce results of varying accuracy. 80 In general, the accuracy of location information increases as the 81 effort expended in generating the information increases. Accuracy is 82 the primary aspect of the quality of location information that is 83 relevant to a Location Recipient (LR). Other aspects of quality can 84 also be significant, such as the currency of the data. 86 Means for expressing the quality of location information is outlined 87 in [RFC5491] and [I-D.thomson-geopriv-uncertainty]. An entity 88 requesting location information of a Location Server (LS) is unable 89 to specify the quality of the location that it ultimately receives. 90 This is inefficient because an LS either provides location 91 information that is inadequate for the intended task; or the LS could 92 waste resources generating location information that is of 93 eccessively high quality. 95 This document defines XML elements that can be added to any protocol 96 that provides location information. These elements provide the 97 ability to communicate location quality requirements to a Location 98 Server. These requirements specify a desired uncertainty at a 99 certain confidence, plus the maximum acceptable age where location 100 information is stored. Guidelines for deterministically evaluating 101 location information against these rules are provided. 103 Location quality requirements provide information that a LS is able 104 to use in deciding how to generate location information, if the LS 105 has that capacity, directly or otherwise. 107 This document provides semantics, examples and security 108 considerations for the HELD protocol [RFC5985] and the SIP presence 109 event package [RFC3856]. The parameters and procedures described in 110 this document are applicable to HELD when used either as a location 111 configuration protocol (LCP) [RFC5687] or as a location dereference 112 protocol [RFC5808]. Application of the parameters described in this 113 document to other protocols is not described, but is relatively 114 trivial for protocols that are able to convey XML. 116 Specifying location quality requirements ensures that a Location 117 Receipient (LR) receives information that is suited to their needs. 118 It also provides information that any Location Generator (LG) can use 119 to better decide how location information is generated. This 120 provides advantages to both requester and source of the information. 121 In one example, a LS might be able to meet quality constraints more 122 quickly than allowed for (for instance, using the HELD "responseTime" 123 parameter). 125 This document also defines an object that can be used by the LS to 126 indicate if the location quality meets the requirements. These 127 parameters can be used by a location recipient to ensure that the 128 location is of adequate quality without requiring specific checking 129 without having to examine the location object. Response parameters 130 are an optional optimisation that also indicates that the LS has 131 understood the location quality requirements. 133 1.1. Conventions used in this document 135 Terms and procedures relating to uncertainty and confidence are taken 136 from [I-D.thomson-geopriv-uncertainty]. Familiarity with terminology 137 outlined in [RFC5687] and [I-D.ietf-geopriv-arch] is also assumed. 139 The term Location Server (LS) is used as a generic label, since these 140 paramters apply in all cases where location information is served to 141 a requesting entity. From the perspective of this document, the LS 142 could be a Location Information Server (LIS). Similarly, the term 143 Location Recipient (LR) is used to refer to the requester of location 144 information, which could be a Device or Target for HELD. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 2. Location Quality Operation 152 Location quality parameters are provided by a location recipient when 153 it requests location information. These parameters identify a 154 minimum quality for parameters. 156 Figure 1 shows an example HELD message where a Device requests 157 location information of a specified quality. 159 160 geodetic 161 163 164 150 165 1000 166 167 2008-05-27T05:47:55Z 168 169 171 Figure 1: Example HELD Location Request 173 A presence application that uses event notification filtering 174 [RFC4660] and the XML format for expressing event notification 175 filters [RFC4661] can include this element in the "what" element of 176 the filter document. A SIP presence application might include this 177 in a filter document as shown in Figure 2. 179 183 184 185 186 ca:RD ca:HNO 187 188 189 190 192 Figure 2: Example Filter Document 194 An LS that supports the location quality element uses the information 195 contained in the request to choose how it serves the query. If the 196 LS sources the information from an LG, this information might be 197 passed to the LG to determine how it generates the information. 199 The response to a request for location of a particular quality MAY 200 contain a quality indicator element that includes a list of the 201 quality requirements that were understood and met. Figure 3 shows a 202 HELD location response that includes a quality indicator. 204 205 207 208 209 210 maxUncertainty/vertical maxAge 211 212 214 Figure 3: Example HELD Location Response 216 An LS provides an indication of the requirements that have been met. 217 The actual quality of the location estimate SHOULD be included in the 218 actual PIDF-LO document, expressed in the uncertainty inherent in the 219 location information and tuple timestamp. 221 3. Location Quality Objects 223 This section defines the format and semantics of the location quality 224 parameters for requests and the indication that is included with 225 responses. 227 3.1. Location Quality Request 229 The "quality" element is included in a HELD request to indicate the 230 requirements set by the Location Recipient (LR) on the quality of 231 returned location information. This document defines three elements 232 that are included. 234 Extensions to this specification can specify XML elements that are 235 included as children of the "quality" element. Elements that are not 236 understood MUST be ignored. 238 3.1.1. Strict Quality Constraints 240 The "strict" attribute of the "quality" element contains a Boolean 241 value that indicates if the constraints are to be followed strictly. 242 If the "strict" attribute is present and set to "true", the LS is 243 requested to respond with an error code when it is unable to provide 244 location information of the requested quality. 246 A HELD error code, "lowQuality", is registered in Section 6.3. A 247 code of "lowQuality" indicates that the requested quality couldn't be 248 provided. The example in Figure 4 shows how the "lowQuality" error 249 code might be used. 251 254 255 Could not provide location of requested quality. 256 ##none 257 259 Figure 4: HELD Error 261 The "strict" attribute defaults to "false". This indicates that the 262 LS provides location information even when the quality constraints 263 aren't met. 265 3.1.2. Maximum Uncertainty 267 The "maxUncertainty" element describes an upper limit on uncertainty 268 at a given confidence. Uncertainty is divided in to horizontal and 269 vertical components. Horizontal uncertainty is the maximum distance 270 from the centroid of the area to the point in the shape furthest from 271 the centroid on the plane of the horizontal at the centroid. 272 Vertical uncertainty is the absolute difference in altitude from the 273 centroid to the point in the shape with the greatest or least 274 altitude. 276 The "horizontal" and "vertical" elements are numerical values that 277 contain a decimal value in metres. Maximum uncertainty values MUST 278 be greater than zero. 280 A location estimate that does not contain uncertainty (i.e. a Point 281 shape), never meets location quality requirements. Where uncertainty 282 is unknown, it is assumed to be arbitrarily large for any non-zero 283 confidence. In particular, this applies to vertical uncertainty 284 where the location estimate is two-dimensional only; location 285 estimates without a vertical component of uncertainty never meet 286 vertical uncertainty requirements. 288 Note: An LS MAY provide location information using the Point shape 289 and indicate that the requested uncertainty is met, if the LS has 290 access to uncertainty information and is prevented from sharing 291 this information due to policy constraints. An LS SHOULD NOT omit 292 uncertainty in this fashion, because the LR has no way of 293 independently verifying that the uncertainty meets their 294 requirements. 296 The "confidence" attribute of this element includes the confidence 297 level (expressed as a percentage) that the uncertainty is evaluated 298 at. Desired confidence has a default value of 95. The definition of 299 this attribute is taken from [I-D.thomson-geopriv-confidence]. 301 To evaluate uncertainty, the location estimate is first scaled so 302 that the confidence of the estimate matches or exceeds the requested 303 confidence. The LS SHOULD convert the shape of the uncertainty to a 304 circle or a sphere prior to scaling to simply the scaling process. 305 For consistency - and contrary to the rules in 306 [I-D.thomson-geopriv-uncertainty] - it is RECOMMENDED that a normal 307 PDF be assumed for all location information except where confidence 308 is reduced for a rectangular PDF. Other scaling methods MAY be 309 applied where better information about the distribution is known. 311 Horizontal uncertainty is evalulated by removing the altitude and 312 altitude uncertainty components from the location estimate. While 313 removing altitude components from a location estimate might normally 314 increase confidence, confidence MUST NOT be increased at this step; 315 the confidence value has already been considered. The shape is then 316 converted to a circle, if it is not already in that shape. The 317 radius of the resulting circle is compared to the maximum horizontal 318 uncertainty. 320 Vertical uncertainty is evaluated for shapes that contain altitude 321 uncertainty. The value used for evaluating vertical uncertainty 322 depends on the shape type: the vertical axis value for the Ellipsoid 323 shape; the radius of the Sphere shape; half the height of the Prism 324 shape. A constraint on vertical uncertainty cannot be met if 325 vertical uncertainty is not known. 327 The LS MAY use location quality parameters to alter the way that it 328 generates location information and to provide location information 329 that more closely matches what is requested. If maximum value is 330 provided for vertical uncertainty, the LS SHOULD provide a location 331 estimate that includes altitude and altitude uncertainty if possible. 332 The LS SHOULD provide location information with the confidence 333 included in the request, if scaling is possible. Scaling MAY be 334 avoided if the location information is significantly degraded by the 335 scaling process. 337 3.1.3. Required Civic Elements 339 The "requiredCivic" element represents the requirements of an LR for 340 civic address information. An LR can specify the address elements 341 that need to be present in the civic address in order for the 342 location information to meet their quality requirements. 344 The "requiredCivic" element contains a whitespace-separated list of 345 element names. These can be interpreted as XPath 346 [W3C.REC-xpath20-20070123] expressions that are evaluated in the 347 context of the "civicAddress" element [RFC5139]. These XPath 348 statements are restricted to use of qualified names only (using the 349 response document namespace context) and the "/" separator; that is, 350 the only permitted axis is the "child::" axis. All child nodes of 351 elements (including attributes and textual content) are treated as 352 belonging to an element. 354 Figure 5 shows an example request where an LR requires country, state 355 (or equivalent) and post code civic address elements in the location 356 information provided by the LS. 358 359 361 ca:country ca:A1 ca:PC 362 363 364 Figure 5: Example Specifying Required Civic Address Fields 366 This does not force the LS to limit the civic address fields provided 367 to just those requested. Any additional address fields that are 368 known can be provided as long as policy permits their inclusion. 370 3.1.4. Maximum Age 372 Where location information is stored or cached, an LR can specify a 373 limit on the age of this information. This is particularly important 374 if location information is generated in advance. The "age" of 375 location information is indicated by the the "timestamp" element in 376 the PIDF tuple. The age parameter specifies the minimum value for 377 this field; that is, the oldest location information that is 378 acceptable. 380 Location information that has greater age than requested SHOULD be 381 determined anew. A value of "now" can be used to indicate that 382 stored location information of any age is not acceptable to the LR. 384 Age is calculated from the time that the LS receives a request. 385 Location information generated after this time has an effective age 386 that is less than zero. The age of location information generated 387 after the request is received is always acceptable. 389 3.2. Location Quality Indication 391 The "qualityInd" element is used in responses to indicate which of 392 the location quality requirements from a request were met. The 393 presence of this element indicates that a request for a given 394 location quality was understood and lists the quality requirements 395 that the accompanying location information meets. 397 The list of requirements is represented as a whitespace-separated 398 list of element names. These can be interpreted as XPath 399 [W3C.REC-xpath20-20070123] expressions that are evaluated in the 400 context of the original location quality request. These statements 401 follow the same constraints as the list of elements in Section 3.1.3. 403 Where elements are nested, such as the "maxUncertainty" element, the 404 outer element can be included to indicate an entire constraint is 405 met; or, each individual child element can be identified. Two 406 quality indications that are roughly equivalent are shown in 407 Figure 6. 409 410 maxUncertainty 411 413 414 maxUncertainty/horizontal maxUncertainty/vertical 415 417 Figure 6: Similar Quality Indications 419 A LS that is unable to determine if a constraint is met for any 420 reason MUST NOT list that constraint in this element. This includes 421 the case where the constraint is not supported by the LS. This list 422 MAY be empty if none of the requested quality requirements could be 423 met. 425 The special value "##all" indicates that all quality requirements 426 were met. A value of "##all" cannot be used if there are unknown or 427 unsupported elements in the quality request. 429 4. Location Quality Schema 431 Note that the pattern rules in the following schema wrap due to 432 length constraints in RFC documents. None of the patterns contain 433 whitespace. 435 436 444 445 447 HELD Location Quality 448 449 450 452 This schema defines a framework for location quality requests 453 and indications of whether they are met. 454 455 456 458 459 460 461 462 463 464 465 466 468 469 471 472 473 474 476 477 478 479 480 481 482 483 484 486 487 488 490 491 492 493 494 496 497 498 499 500 501 502 503 505 506 508 510 511 512 513 514 515 516 517 518 519 520 522 523 524 525 526 527 528 529 530 532 533 535 537 5. Security Considerations 539 Location information might be cached by a location server to 540 alleviate load on location generation functions. A location server 541 might provide a means for an attacker to increase the location 542 generation load by forcibly circumventing the cache using the 543 "maxAge" quality constraint. Where caching is used to reduce 544 location generation load, a location server needs mechanisms to 545 control how caching is bypassed. 547 An entity that is concerned about the privacy implications of making 548 its preferences known can choose not to specify location quality 549 requirements. 551 6. IANA Considerations 553 This section registers a schema for the location quality objects and 554 a HELD error code. 556 6.1. URN Sub-Namespace Registration for 557 urn:ietf:params:xml:ns:geopriv:lq 559 This section registers a new XML namespace, 560 "urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in 561 [RFC3688]. 563 URI: urn:ietf:params:xml:ns:geopriv:lq 565 Registrant Contact: IETF, GEOPRIV working group, 566 (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com). 568 XML: 570 BEGIN 571 572 574 575 576 Location Quality 577 578 579

Namespace for Location Quality

580

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

581 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 582 with the RFC number for this specification.]] 583

See RFCXXXX.

584 585 586 END 588 6.2. XML Schema Registration for Location Quality Schema 590 This section registers an XML schema as per the guidelines in 591 [RFC3688]. 593 URI: urn:ietf:params:xml:schema:geopriv:lq 595 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 596 Martin Thomson (martin.thomson@andrew.com). 598 Schema: The XML for this schema can be found in Section 4 of this 599 document. 601 6.3. Registration of HELD 'lowQuality' Error Code 603 This section registers the "lowQuality" error code in the "Geopriv 604 HELD Registries, Error codes for HELD" IANA registry. 606 lowQuality: This error code indicates that the location information 607 that was available did not meet the strict quality constraints 608 specified in the request. 610 7. References 612 7.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 618 January 2004. 620 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 621 Initiation Protocol (SIP)", RFC 3856, August 2004. 623 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 624 Requena, "An Extensible Markup Language (XML)-Based Format 625 for Event Notification Filtering", RFC 4661, 626 September 2006. 628 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 629 Format for Presence Information Data Format Location 630 Object (PIDF-LO)", RFC 5139, February 2008. 632 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 633 Presence Information Data Format Location Object (PIDF-LO) 634 Usage Clarification, Considerations, and Recommendations", 635 RFC 5491, March 2009. 637 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 638 RFC 5985, September 2010. 640 [I-D.thomson-geopriv-uncertainty] 641 Thomson, M. and J. Winterbottom, "Representation of 642 Uncertainty and Confidence in PIDF-LO", 643 draft-thomson-geopriv-uncertainty-06 (work in progress), 644 March 2011. 646 [I-D.thomson-geopriv-confidence] 647 Thomson, M., "Expressing Confidence in a Location Object", 648 draft-thomson-geopriv-confidence-03 (work in progress), 649 October 2010. 651 7.2. Informative References 653 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 654 Requena, "Functional Description of Event Notification 655 Filtering", RFC 4660, September 2006. 657 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 658 Location Configuration Protocol: Problem Statement and 659 Requirements", RFC 5687, March 2010. 661 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 662 Mechanism", RFC 5808, May 2010. 664 [I-D.ietf-geopriv-arch] 665 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 666 Tschofenig, H., and H. Schulzrinne, "An Architecture for 667 Location and Location Privacy in Internet Applications", 668 draft-ietf-geopriv-arch-03 (work in progress), 669 October 2010. 671 [W3C.REC-xpath20-20070123] 672 Fernandez, M., Berglund, A., Simeon, J., Chamberlin, D., 673 Boag, S., Robie, J., and M. Kay, "XML Path Language 674 (XPath) 2.0", World Wide Web Consortium 675 Recommendation REC-xpath20-20070123, January 2007, 676 . 678 Authors' Addresses 680 Martin Thomson 681 Andrew Corporation 682 Andrew Building (39) 683 Wollongong University Campus 684 Northfields Avenue 685 Wollongong, NSW 2522 686 AU 688 Email: martin.thomson@andrew.com 689 James Winterbottom 690 Andrew Corporation 691 Andrew Building (39) 692 Wollongong University Campus 693 Northfields Avenue 694 Wollongong, NSW 2522 695 AU 697 Email: james.winterbottom@andrew.com