idnits 2.17.1 draft-mahy-geopriv-loc-filters-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 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 700. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (March 5, 2006) is 6626 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-02 == Outdated reference: A later version (-03) exists of draft-thomson-geopriv-geo-shape-00 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 2141 (ref. '10') (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WG R. Mahy 3 Internet-Draft Plantronics 4 Expires: September 6, 2006 March 5, 2006 6 A Document Format for Filtering and Reporting Location Notications in 7 PIDF-LO 8 draft-mahy-geopriv-loc-filters-01.txt 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 September 6, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes filters which limit asynchronous location 42 notifications to compelling events. The resulting location 43 information is conveyed in existing location formats wrapped in 44 GEOPRIV privacy extensions to the Presence Information Document 45 Format (PIDF-LO). Location disclosure is limited to voluntary 46 disclosure by a notifier that possesses credentials for the named 47 resource. 49 Table of Contents 51 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Definition of Location Filter Format . . . . . . . . . . . . . 3 54 3.1 Horizontal and Vertical Movement . . . . . . . . . . . . . 4 55 3.2 Changes in value . . . . . . . . . . . . . . . . . . . . . 5 56 3.3 Containment Within a Region . . . . . . . . . . . . . . . 6 57 3.4 XML Schema for filter format . . . . . . . . . . . . . . . 9 58 4. Containment schema . . . . . . . . . . . . . . . . . . . . . . 10 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 6.1 MIME Registration for 62 application/location-delta-filter+xml . . . . . . . . . . 13 63 6.2 URN Sub-Namespace Registration for 64 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 13 65 6.3 Schema Registration For location-filter . . . . . . . . . 14 66 6.4 URN Sub-Namespace Registration for 67 urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 14 68 6.5 Schema Registration For containment . . . . . . . . . . . 15 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 72 8.2 Informational References . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 74 Intellectual Property and Copyright Statements . . . . . . . . 17 76 1. Conventions 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC-2119 [2]. 82 2. Overview 84 Conveying static location in PIDF-LO [1] bodies is straightforward. 85 However the difficult part about asynchronous notification of 86 location information is that many forms of location are measured as a 87 continuous gradient. Unlike notifications using discreet quantities, 88 it is difficult to know when a change in location is large enough to 89 warrant a notification. Moreover, different applications require a 90 wide variety of location resolutions. Any optimization made for one 91 application would ultimately result in wasteful polling or a sluggish 92 user interface for other applications. 94 The mechanism described here defines filters in XML [3] documents 95 which limit location notification to events which are of relevance to 96 the subscriber. These filters persist until they are changed with a 97 replacement filter. 99 In addition to the relevant filters, this document also defines a new 100 XML schema [4] which can be included in PIDF-LO documents to indicate 101 that the resource is inside or outside of a container region. 103 3. Definition of Location Filter Format 105 The granularity of notifications necessary for various geographic 106 location applications varies dramatically. The subscriber should be 107 able to get asynchronous notifications with appropriate granularity 108 and accuracy, without having to poll or flood the network with 109 notifications which are not important to the application. 110 Notifications should only happen when the notification would be 111 considered an Interesting Event to the subscriber. This section of 112 this document defines an XML filter format to describe interesting 113 conditions or events. The terminal elements in this format are 114 defined in terms of existing Geographic Markup Language (GML) [9] 115 data types. 117 This document also defines a MIME type for this location filter 118 format: application/location-delta-filter+xml. 120 This document defines the following as an initial list of Interesting 121 Events: 123 1. the resource moves more than a specific distance horizontally or 124 vertically since the last notification 125 2. the resource exceeds a specific speed 126 3. the resource enters or exits one or more GML objects (for 127 example, a set of 2-dimensional or 3-dimensional regions) 128 included or referenced in the filter. 129 4. one or more of the values of the specified address labels has 130 changed for the resource (for example, the A1 value of the 131 civilAddress has changed from California to Nevada) 132 This specification makes use of XML namespaces [5] for identifying 133 location filter documents and document fragments. The namespace URI 134 for elements defined by this specification is a URN [10], using the 135 namespace identifier 'ietf' defined by [11] and extended by [12]. 136 This URN is: 138 urn:ietf:params:xml:ns:location-filter 140 The filter format starts with a top-level XML element called 141 "", which contains one or more filter events. The 142 semantics of multiple elements inside a location-filter is a logical 143 OR. In other words, if any of the individual filter events occurs, 144 the event satisfies the location-filter and triggers a notification. 146 3.1 Horizontal and Vertical Movement 148 The movedHoriz and movedVert filter events each indicate a minimum 149 horizontal motion or vertical distance (respectively) that the 150 resource must have moved from the location of the resource when the 151 last notification was sent in order to trigger this event. The 152 distance is measured absolutely from the point of last notification 153 rather than in terms of cumulative motion (For example, someone 154 pacing inside a room will not trigger an event if the trigger 155 threshold is slightly larger than the room.) Each of these events 156 can only appear once in a location-filter. These events have an 157 attribute "uom" (for "units of measure"), which indicates the units 158 of the element. The default unit for these events is meters. 160 Similarly, the speedExceeds filter event indicates a minimum 161 horizontal speed of the resource before the speedExceeds event is 162 triggered. This element can appear only once in a location-filter, 163 and has a "uom" attribute which defaults to meters per second if not 164 present. 165 This filter measures the horizontal component of speed in any 166 direction. It does not measure velocity. Note also that there is 167 no corresponding event triggered when speed drops below a 168 threshold. 170 Below are some examples. In the first example if the resource moves 171 20m in the x,y direction or 3m in the z direction, send a 172 notification: 174 175 20 176 3 177 179 If the resource exceeds 3 meters per second (10.8 km/h), send a 180 notification: 182 183 3 184 186 3.2 Changes in value 188 The valueChanges filter event contains a string which is interpreted 189 as an XPath [6] expression evaluated within the context of the 190 location-info element of the PIDF-LO document which would be 191 generated by the notification. The XPath expression MUST evaluate to 192 only a single Xpath node. If the value of any of the elements in the 193 resulting node changes, then the filter event is triggered. Note 194 that the value of the resulting node changes if any of those nodes or 195 subnodes transitions from having a value to having no value or vice 196 versa. A location-filter may contain multiple valueChanges filters. 198 Note that the example below needs to be updated to use the revised 199 civic location format. 200 For example, given the following logical PIDF-LO document, If the 201 state (A1), county (A2), city (A3), or postal code (PC) changes, send 202 a notification: 204 PIDF-LO Location Document: 205 206 210 211 212 213 214 215 US 216 New York 217 New York 218 Broadway 219 123 220 Suite 75 221 10027 222 223 224 225 yes 226 2003-06-23T04:57:29Z 227 228 229 230 231 2003-06-22T20:57:29Z 232 233 235 Filter Document: 236 239 cl:civilAddress/cl:A1 240 cl:civilAddress/cl:A2 241 cl:civilAddress/cl:A3 242 cl:civilAddress/cl:PC 243 245 3.3 Containment Within a Region 247 Finally, the "enterOrExit" filter event is satisfied when the 248 resource enters or exits a named 2-dimensional or 3-dimensional 249 region described by one of the shapes defined in [8]. These regions 250 can be defined using inline snippets of GML, or externally referenced 251 using a URI (Uniform Resource Identifier). 252 These regions need a unique name or identifier so location with 253 respect to these regions can be described later (for example in a 254 notification). These regions are currently described as GML 255 Features so they can be named with a GML Name. Ideally each 256 region could be described instead as a GML geometry with some 257 associated name or identifier. 259 Any 2-dimensional region MUST be defined using the EPSG 4326 260 coordinate reference system. Any 3-dimensional region MUST be 261 defined using the EPSG 4979 coordinate reference system. A location- 262 filter can contain more than one enterOrExit filter event. 263 Notifiers MAY support other more complex geometries or additional 264 coordinate reference systems. How the Subscriber negotiates 265 support for more complex geometries or reference systems is out of 266 the scope of this document. 267 Likewise, this document does not describe how a subscriber 268 discovers the existence of externally referenced features. This 269 topic is out of scope of this document. 271 In most cases Subscribers that use location filters based on 272 enterOrExit events are especially interested in the resource's 273 relationship to those named features. Consequently, the notifier 274 MUST include either a "containment" element for each feature 275 mentioned in the location-filter which has changed its containment 276 properties with respect to the resource since the last notification. 277 These elements are defined in Section 4. The notifier MAY include 278 any other form of location that is relevant. 280 For example, if the resource enters or exits Building 10 (which is 281 defined by specific 2-D or 3-D rectangular coordinates), send a 282 notification: 284 Version in 2-Dimensions: 285 286 287 288 Building 10 289 290 293 294 295 302 303 304 305 306 307 308 310 Version in 3-Dimensions: 311 312 313 314 Building 10 315 319 320 321 322 323 324 37.41188 -121.93243 0 325 37.41142 -121.93242 0 326 37.41142 -121.93132 0 327 37.41188 -121.93132 0 328 37.41188 -121.93243 0 329 330 331 332 333 334 335 24 336 337 338 339 340 342 If the resource enters or exits either the parking garage or any of 343 the conference rooms (both of which are externally defined), send a 344 notification: 346 347 348 350 351 352 354 355 357 3.4 XML Schema for filter format 359 The XML Schema for this format is defined below. 361 362 367 368 369 370 372 374 377 378 381 384 385 387 388 389 390 392 4. Containment schema 394 This section describes a schema for describing the resource's 395 location relative to a region or list of regions which might contain 396 the resource. (These regions can be defined dynamically in an 397 "enterOrExit" element in a subscription filter, or defined on the 398 notifier using some out-of-band mechanism.) The "pidfResource" 399 element is placed inside the location-info element in a PIDF-LO 400 document. The pidfResource element can contain zero or more 401 "containment" elements. Each containment element has a GML Feature 402 sub-element (of type "FeaturePropertyType") and a mandatory attribute 403 which specifies if the PIDF resource is inside or outside of the 404 feature, or if the position of the resource with respect to the 405 region or region list is undefined. 406 In a future version of this specification, the GML Feature can 407 become a reference to a more preferable name or identifier type. 408 The GML Feature type is only used because it includes a name to 409 reference it. 411 If the subscriber is not authorized to know the relative position, 412 the notifier MUST NOT reveal this private information. The 413 RECOMMENDED way to prevent the subscriber from seeing private 414 location data of this type is to return a containment element whose 415 position attribute is "undefined". Note that in some cases, the 416 containment information may be more interesting than the actual raw 417 location. It is not necessary to convey a concrete civic or geo 418 location in a PIDF-LO if the subscriber is only interested in or 419 authorized to see the containment status. 421 422 427 428 429 430 432 433 434 435 436 437 438 440 441 442 443 444 445 446 447 448 449 450 451 452 454 Below is an example PIDF-LO document which indicates that the 455 resource is inside building 10, not outside the parking garage, and 456 not permitted to know if the resource is in a conference room. Note 457 that in GML, these features could be referenced by their unique 458 identifiers instead. 460 461 465 466 467 468 469 470 471 472 Building 10 473 474 475 476 478 479 480 482 483 484 485 486 yes 487 2003-06-23T04:57:29Z 488 489 490 491 492 2003-06-22T20:57:29Z 493 494 496 5. Security Considerations 498 Location information is typically very privacy sensitive. As such, 499 GEOPRIV requires that notifications MUST be encrypted and integrity 500 protected. 502 Additional privacy and security considerations are discussed in 503 detail in [7]. 505 6. IANA Considerations 507 6.1 MIME Registration for application/location-delta-filter+xml 509 MIME media type name: application 511 MIME subtype name: application/location-delta-filter+xml 513 Required parameters: none. 515 Optional parameters: none. 517 Encoding considerations: Same as for XML. 519 Security considerations: See the "Security Considerations" 520 section in this document. 522 Interoperability considerations: none 524 Published specification: This document. 526 Applications which use this media: The application/ 527 location-delta-filter+xml application subtype supports the exchange 528 of filters to throttle asynchronous notifications of location 529 information. 531 Additional information: 533 1. Magic number(s): N/A 535 2. File extension(s): N/A 537 3. Macintosh file type code: N/A 539 6.2 URN Sub-Namespace Registration for 540 urn:ietf:params:xml:ns:location-filter 542 This section registers a new XML namespace, as per the guidelines in 543 [12]. 544 URI: The URI for this namespace is 545 urn:ietf:params:xml:ns:location-filter. 546 Registrant Contact: IETF, GEOPRIV working group, , 547 as delegated by the IESG . 549 XML: 551 BEGIN 552 553 555 556 557 559 Location Filter Namespace 560 561 562

Namespace for PIDF-LO Location Filters

563

urn:ietf:params:xml:ns:location-filter

564

See RFCXXXX.

565 566 567 END 569 6.3 Schema Registration For location-filter 571 This specification registers a schema, as per the guidelines in [12]. 572 URI: please assign. 573 Registrant Contact: IETF, GEOPRIV Working Group 574 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 575 XML: The XML can be found as the sole content of Section 3.4. 577 6.4 URN Sub-Namespace Registration for 578 urn:ietf:params:xml:ns:pidf:geopriv10:containment 580 This section registers a new XML namespace, as per the guidelines in 581 [12]. 582 URI: The URI for this namespace is 583 urn:ietf:params:xml:ns:pidf:geopriv10:containment. 584 Registrant Contact: IETF, GEOPRIV working group, , 585 as delegated by the IESG . 586 XML: 588 BEGIN 589 590 592 593 594 596 PIDF-LO Location Containment Namespace 597 598 599

Namespace for PIDF-LO location containment elements

600

urn:ietf:params:xml:ns:pidf:geopriv10:containment

601

See RFCXXXX.

602 603 604 END 606 6.5 Schema Registration For containment 608 This specification registers a schema, as per the guidelines in [12]. 609 URI: please assign. 610 Registrant Contact: IETF, GEOPRIV Working Group 611 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 612 XML: The XML can be found as the sole content of Section 4. 614 7. Acknowledgments 616 Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for 617 their comments. 619 8. References 621 8.1 Normative References 623 [1] Peterson, J., "A Presence-based GEOPRIV Location Object Format", 624 RFC 4119, December 2005. 626 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 627 Levels", BCP 14, RFC 2119, March 1997. 629 [3] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 630 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, 631 October 2000, . 633 [4] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML 634 Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, 635 . 637 [5] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", 638 W3C REC-xml-names, January 1999, 639 . 641 [6] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 642 1.0", W3C Recommendation xpath, November 1999, 643 . 645 [7] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 646 Considerations and Recommendations", 647 draft-ietf-geopriv-pdif-lo-profile-02 (work in progress), 648 February 2006. 650 [8] Thomson, M., "Geodetic Shapes for the Representation of 651 Uncertainty in PIDF-LO", draft-thomson-geopriv-geo-shape-00 652 (work in progress), February 2006. 654 [9] OpenGIS, "Open Geography Markup Language (GML) Implementation 655 Specification", OpenGIS OGC 02-023r4, January 2003, 656 . 658 8.2 Informational References 660 [10] Moats, R., "URN Syntax", RFC 2141, May 1997. 662 [11] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 663 August 1999. 665 [12] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 666 January 2004. 668 Author's Address 670 Rohan Mahy 671 Plantronics 672 345 Encincal Street 673 Santa Cruz, CA 674 USA 676 Email: rohan@ekabal.com 678 Intellectual Property Statement 680 The IETF takes no position regarding the validity or scope of any 681 Intellectual Property Rights or other rights that might be claimed to 682 pertain to the implementation or use of the technology described in 683 this document or the extent to which any license under such rights 684 might or might not be available; nor does it represent that it has 685 made any independent effort to identify any such rights. Information 686 on the procedures with respect to rights in RFC documents can be 687 found in BCP 78 and BCP 79. 689 Copies of IPR disclosures made to the IETF Secretariat and any 690 assurances of licenses to be made available, or the result of an 691 attempt made to obtain a general license or permission for the use of 692 such proprietary rights by implementers or users of this 693 specification can be obtained from the IETF on-line IPR repository at 694 http://www.ietf.org/ipr. 696 The IETF invites any interested party to bring to its attention any 697 copyrights, patents or patent applications, or other proprietary 698 rights that may cover technology that may be required to implement 699 this standard. Please address the information to the IETF at 700 ietf-ipr@ietf.org. 702 Disclaimer of Validity 704 This document and the information contained herein are provided on an 705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 707 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 708 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 709 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Copyright Statement 714 Copyright (C) The Internet Society (2006). This document is subject 715 to the rights, licenses and restrictions contained in BCP 78, and 716 except as set forth therein, the authors retain all their rights. 718 Acknowledgment 720 Funding for the RFC Editor function is currently provided by the 721 Internet Society.