idnits 2.17.1 draft-ietf-geopriv-loc-filters-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 872. 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 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 (November 3, 2008) is 5654 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. 'GML' == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-13 == Outdated reference: A later version (-08) exists of draft-niemi-sipping-event-throttle-07 -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 geopriv R. Mahy 3 Internet-Draft Plantronics 4 Intended status: Standards Track B. Rosen 5 Expires: May 7, 2009 NeuStar 6 November 3, 2008 8 A Document Format for Filtering and Reporting Location Notications in 9 the Presence Information Document Format Location Object (PIDF-LO) 10 draft-ietf-geopriv-loc-filters-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 7, 2009. 37 Abstract 39 This document describes filters which limit asynchronous location 40 notifications to compelling events. The resulting location 41 information is conveyed in existing location formats wrapped in 42 GEOPRIV privacy extensions to the Presence Information Document 43 Format (PIDF-LO) 45 Table of Contents 47 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Definition of Location Filter Format . . . . . . . . . . . . . 3 50 3.1. Horizontal and Vertical Movement . . . . . . . . . . . . . 4 51 3.2. Changes in value . . . . . . . . . . . . . . . . . . . . . 5 52 3.3. Containment Within a Region . . . . . . . . . . . . . . . 6 53 3.4. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 9 54 3.5. XML Schema for filter format . . . . . . . . . . . . . . . 9 55 4. Containment schema . . . . . . . . . . . . . . . . . . . . . . 12 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 58 6.1. MIME Registration for 59 application/location-delta-filter+xml . . . . . . . . . . 16 60 6.2. URN Sub-Namespace Registration for 61 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16 62 6.3. Schema Registration For location-filter . . . . . . . . . 17 63 6.4. URN Sub-Namespace Registration for 64 urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 17 65 6.5. Schema Registration For containment . . . . . . . . . . . 18 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 69 8.2. Informational References . . . . . . . . . . . . . . . . . 19 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 71 Intellectual Property and Copyright Statements . . . . . . . . . . 21 73 1. Conventions 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC-2119 [RFC2119]. 79 2. Overview 81 Conveying static location in PIDF-LO [RFC4119] bodies is 82 straightforward. However the difficult part about asynchronous 83 notification of location information is that many forms of location 84 are measured as a continuous gradient. Unlike notifications using 85 discreet quantities, it is difficult to know when a change in 86 location is large enough to warrant a notification. Moreover, 87 different applications require a wide variety of location 88 resolutions. Any optimization made for one application would 89 ultimately result in wasteful polling or a sluggish user interface 90 for other applications. 92 The mechanism described here defines filters in XML [W3C.REC-xml] 93 documents which limit location notification to events which are of 94 relevance to the subscriber. These filters persist until they are 95 changed with a replacement filter. 97 In addition to the relevant filters, this document also defines a new 98 XML schema [W3C.REC-xmlschema-1] which can be included in PIDF-LO 99 documents to indicate that the resource is inside or outside of a 100 container region. 102 3. Definition of Location Filter Format 104 The granularity of notifications necessary for various geographic 105 location applications varies dramatically. The subscriber should be 106 able to get asynchronous notifications with appropriate granularity 107 and accuracy, without having to poll or flood the network with 108 notifications which are not important to the application. 109 Notifications should only happen when the notification would be 110 considered an Interesting Event to the subscriber. This section of 111 this document defines an XML filter format to describe interesting 112 conditions or events. The terminal elements in this format are 113 defined in terms of existing Geographic Markup Language (GML) [GML] 114 data types or civic address elements. 116 This document also defines a MIME type for this location filter 117 format: application/location-delta-filter+xml. 119 This document defines the following as an initial list of Interesting 120 Events: 121 1. the resource moves more than a specific distance horizontally or 122 vertically since the last notification 123 2. the resource exceeds a specific speed 124 3. the resource enters or exits one or more GML objects (for 125 example, a set of 2-dimensional or 3-dimensional regions) 126 included or referenced in the filter. 127 4. one or more of the values of the specified address labels has 128 changed for the resource (for example, the A1 value of the 129 civilAddress has changed from California to Nevada) 130 5. a mininum and maximum rate of reports regardless of movement 131 This specification makes use of XML namespaces [W3C.REC-xml-names] 132 for identifying location filter documents and document fragments. 133 The namespace URI for elements defined by this specification is a URN 134 [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] 135 and extended by [RFC3688]. This URN is: 137 urn:ietf:params:xml:ns:location-filter 139 The filter format starts with a top-level XML element called 140 "", which contains one or more filter events. The 141 semantics of multiple elements inside a location-filter generally is 142 a logical OR. In other words, if any of the individual filter events 143 occurs, the event satisfies the location-filter and triggers a 144 notification. However the "maxRate" parameter is a logical AND, and 145 will limit events that otherwise would have been reported. 147 3.1. Horizontal and Vertical Movement 149 The movedHoriz and movedVert filter events each indicate a minimum 150 horizontal motion or vertical distance (respectively) that the 151 resource must have moved from the location of the resource when the 152 last notification was sent in order to trigger this event. The 153 distance is measured absolutely from the point of last notification 154 rather than in terms of cumulative motion (For example, someone 155 pacing inside a room will not trigger an event if the trigger 156 threshold is slightly larger than the room.) Each of these events 157 can only appear once in a location-filter. These events have an 158 attribute "uom" (for "units of measure"), which indicates the units 159 of the element. The default unit for these events is meters. 161 Similarly, the speedExceeds filter event indicates a minimum 162 horizontal speed of the resource before the speedExceeds event is 163 triggered. This element can appear only once in a location-filter, 164 and has a "uom" attribute which defaults to meters per second if not 165 present. 167 This filter measures the horizontal component of speed in any 168 direction. It does not measure velocity. Note also that there is 169 no corresponding event triggered when speed drops below a 170 threshold. 172 Below are some examples. In the first example if the resource moves 173 20m in the x,y direction or 3m in the z direction, send a 174 notification: 176 177 20 178 3 179 181 If the resource exceeds 3 meters per second (10.8 km/h), send a 182 notification: 184 185 3 186 188 3.2. Changes in value 190 The valueChanges filter event contains a string which is interpreted 191 as an XPath [W3C.xpath] expression evaluated within the context of 192 the location-info element of the PIDF-LO document which would be 193 generated by the notification. The XPath expression MUST evaluate to 194 only a single Xpath node. If the value of any of the elements in the 195 resulting node changes, then the filter event is triggered. Note 196 that the value of the resulting node changes if any of those nodes or 197 subnodes transitions from having a value to having no value or vice 198 versa. A location-filter may contain multiple valueChanges filters. 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 NY 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 The "enterOrExit" filter event is satisfied when the resource enters 248 or exits a named 2-dimensional or 3-dimensional region described by 249 one of the shapes defined in section 5 of 250 [I-D.ietf-geopriv-pdif-lo-profile]. These regions can be defined 251 using inline snippets of GML, or externally referenced using a URI 252 (Uniform Resource Identifier). 253 These regions need a unique name or identifier so location with 254 respect to these regions can be described later (for example in a 255 notification). These regions are currently described as GML 256 Features so they can be named with a GML Name. Ideally each 257 region could be described instead as a GML geometry with some 258 associated name or identifier. 260 Any 2-dimensional region MUST be defined using the EPSG 4326 261 coordinate reference system. Any 3-dimensional region MUST be 262 defined using the EPSG 4979 coordinate reference system. A location- 263 filter can contain more than one enterOrExit filter event. 265 Notifiers MAY support other more complex geometries or additional 266 coordinate reference systems. How the Subscriber negotiates 267 support for more complex geometries or reference systems is out of 268 the scope of this document. 269 Likewise, this document does not describe how a subscriber 270 discovers the existence of externally referenced features. This 271 topic is out of scope of this document. 273 In most cases Subscribers that use location filters based on 274 enterOrExit events are especially interested in the resource's 275 relationship to those named features. Consequently, the notifier 276 MUST include either a "containment" element for each feature 277 mentioned in the location-filter which has changed its containment 278 properties with respect to the resource since the last notification. 279 These elements are defined in Section 4. The notifier MAY include 280 any other form of location that is relevant. 282 For example, if the resource enters or exits Building 10 (which is 283 defined by specific 2-D or 3-D rectangular coordinates), send a 284 notification: 286 Version in 2-Dimensions: 287 288 289 290 Building 10 291 292 295 296 297 304 305 306 307 308 309 310 312 Version in 3-Dimensions: 313 314 315 316 Building 10 317 321 322 323 324 325 326 37.41188 -121.93243 0 327 37.41142 -121.93242 0 328 37.41142 -121.93132 0 329 37.41188 -121.93132 0 330 37.41188 -121.93243 0 331 332 333 334 335 336 337 24 338 339 340 341 342 344 If the resource enters or exits either the parking garage or any of 345 the conference rooms (both of which are externally defined), send a 346 notification: 348 349 350 352 353 354 356 357 359 3.4. Rate Control 361 Although not part of the loc-filter function, the throttle mechanisms 362 [I-D.niemi-sipping-event-throttle] can be used to control the rate of 363 notifications. The "throttle", "force" and "average" settings can 364 filter notications by time 366 3.5. XML Schema for filter format 368 The XML Schema for this format is defined below. 370 371 376 377 378 379 381 383 386 387 390 392 394 397 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 422 423 428 429 430 431 433 435 438 439 442 444 446 448 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 473 474 479 480 481 482 484 486 489 490 493 495 497 499 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 524 4. Containment schema 526 This section describes a schema for describing the resource's 527 location relative to a region or list of regions which might contain 528 the resource. (These regions can be defined dynamically in an 529 "enterOrExit" element in a subscription filter, or defined on the 530 notifier using some out-of-band mechanism.) The "pidfResource" 531 element is placed inside the location-info element in a PIDF-LO 532 document. The pidfResource element can contain zero or more 533 "containment" elements. Each containment element has a GML Feature 534 sub-element (of type "FeaturePropertyType") and a mandatory attribute 535 which specifies if the PIDF resource is inside or outside of the 536 feature, or if the position of the resource with respect to the 537 region or region list is undefined. 538 In a future version of this specification, the GML Feature can 539 become a reference to a more preferable name or identifier type. 540 The GML Feature type is only used because it includes a name to 541 reference it. 543 If the subscriber is not authorized to know the relative position, 544 the notifier MUST NOT reveal this private information. The 545 RECOMMENDED way to prevent the subscriber from seeing private 546 location data of this type is to return a containment element whose 547 position attribute is "undefined". Note that in some cases, the 548 containment information may be more interesting than the actual raw 549 location. It is not necessary to convey a concrete civic or geo 550 location in a PIDF-LO if the subscriber is only interested in or 551 authorized to see the containment status. 553 554 559 560 561 562 564 565 566 567 568 569 570 572 573 574 575 576 577 578 579 580 581 582 583 584 586 Below is an example PIDF-LO document which indicates that the 587 resource is inside building 10, not outside the parking garage, and 588 not permitted to know if the resource is in a conference room. Note 589 that in GML, these features could be referenced by their unique 590 identifiers instead. 592 593 597 598 599 600 601 602 603 604 Building 10 605 606 607 608 610 611 612 614 615 616 617 618 yes 619 2003-06-23T04:57:29Z 620 621 622 623 624 2003-06-22T20:57:29Z 625 626 628 5. Security Considerations 630 Location information is typically very privacy sensitive. As such, 631 GEOPRIV requires that notifications MUST be encrypted and integrity 632 protected. 634 Additional privacy and security considerations are discussed in 635 detail in [I-D.ietf-geopriv-pdif-lo-profile]. 637 6. IANA Considerations 639 6.1. MIME Registration for application/location-delta-filter+xml 641 MIME media type name: application 643 MIME subtype name: application/location-delta-filter+xml 645 Required parameters: none. 647 Optional parameters: none. 649 Encoding considerations: Same as for XML. 651 Security considerations: See the "Security Considerations" 652 section in this document. 654 Interoperability considerations: none 656 Published specification: This document. 658 Applications which use this media: The application/ 659 location-delta-filter+xml application subtype supports the exchange 660 of filters to throttle asynchronous notifications of location 661 information. 663 Additional information: 665 1. Magic number(s): N/A 667 2. File extension(s): N/A 669 3. Macintosh file type code: N/A 671 6.2. URN Sub-Namespace Registration for 672 urn:ietf:params:xml:ns:location-filter 674 This section registers a new XML namespace, as per the guidelines in 675 [RFC3688]. 677 URI: The URI for this namespace is 678 urn:ietf:params:xml:ns:location-filter. 679 Registrant Contact: IETF, GEOPRIV working group, , 680 as delegated by the IESG . 682 XML: 684 BEGIN 685 686 688 689 690 692 Location Filter Namespace 693 694 695

Namespace for PIDF-LO Location Filters

696

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

697

See RFCXXXX.

698 699 700 END 702 6.3. Schema Registration For location-filter 704 This specification registers a schema, as per the guidelines in 705 [RFC3688]. 707 URI: please assign. 708 Registrant Contact: IETF, GEOPRIV Working Group 709 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 710 XML: The XML can be found as the sole content of Section 3.5. 712 6.4. URN Sub-Namespace Registration for 713 urn:ietf:params:xml:ns:pidf:geopriv10:containment 715 This section registers a new XML namespace, as per the guidelines in 716 [RFC3688]. 718 URI: The URI for this namespace is 719 urn:ietf:params:xml:ns:pidf:geopriv10:containment. 720 Registrant Contact: IETF, GEOPRIV working group, , 721 as delegated by the IESG . 722 XML: 724 BEGIN 725 726 728 729 730 732 PIDF-LO Location Containment Namespace 733 734 735

Namespace for PIDF-LO location containment elements

736

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

737

See RFCXXXX.

738 739 740 END 742 6.5. Schema Registration For containment 744 This specification registers a schema, as per the guidelines in 745 [RFC3688]. 747 URI: please assign. 748 Registrant Contact: IETF, GEOPRIV Working Group 749 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 750 XML: The XML can be found as the sole content of Section 4. 752 7. Acknowledgments 754 Thanks to Allan Thompson, James Winterbottom, and Martin Thomson for 755 their comments. 757 8. References 759 8.1. Normative References 761 [GML] OpenGIS, "Open Geography Markup Language (GML) 762 Implementation Specification", OpenGIS OGC 02-023r4, 763 January 2003, 764 . 766 [I-D.ietf-geopriv-pdif-lo-profile] 767 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 768 PIDF-LO Usage Clarification, Considerations and 769 Recommendations", draft-ietf-geopriv-pdif-lo-profile-13 770 (work in progress), September 2008. 772 [I-D.niemi-sipping-event-throttle] 773 Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 774 Protocol (SIP) Event Notification Extension for 775 Notification Throttling", 776 draft-niemi-sipping-event-throttle-07 (work in progress), 777 October 2008. 779 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 780 Requirement Levels", BCP 14, RFC 2119, March 1997. 782 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 783 Format", RFC 4119, December 2005. 785 [W3C.REC-xml] 786 Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 787 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- 788 xml, October 2000, . 790 [W3C.REC-xml-names] 791 Bray, T., Hollander, D., and A. Layman, "Namespaces in 792 XML", W3C REC-xml-names, January 1999, 793 . 795 [W3C.REC-xmlschema-1] 796 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 797 "XML Schema Part 1: Structures", W3C REC-xmlschema-1, 798 May 2001, . 800 [W3C.xpath] 801 Clark, J. and S. DeRose, "XML Path Language (XPath) 802 Version 1.0", W3C Recommendation xpath, November 1999, 803 . 805 8.2. Informational References 807 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 809 [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 810 August 1999. 812 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 813 January 2004. 815 Authors' Addresses 817 Rohan Mahy 818 Plantronics 819 345 Encincal Street 820 Santa Cruz, CA 821 USA 823 Email: rohan@ekabal.com 825 Brian Rosen 826 NeuStar 827 470 Conrad Dr. 828 Mars, PA 16046 829 US 831 Phone: +1 724 382 1051 832 Email: br@brianrosen.net 834 Full Copyright Statement 836 Copyright (C) The IETF Trust (2008). 838 This document is subject to the rights, licenses and restrictions 839 contained in BCP 78, and except as set forth therein, the authors 840 retain all their rights. 842 This document and the information contained herein are provided on an 843 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 844 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 845 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 846 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 847 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 848 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 850 Intellectual Property 852 The IETF takes no position regarding the validity or scope of any 853 Intellectual Property Rights or other rights that might be claimed to 854 pertain to the implementation or use of the technology described in 855 this document or the extent to which any license under such rights 856 might or might not be available; nor does it represent that it has 857 made any independent effort to identify any such rights. Information 858 on the procedures with respect to rights in RFC documents can be 859 found in BCP 78 and BCP 79. 861 Copies of IPR disclosures made to the IETF Secretariat and any 862 assurances of licenses to be made available, or the result of an 863 attempt made to obtain a general license or permission for the use of 864 such proprietary rights by implementers or users of this 865 specification can be obtained from the IETF on-line IPR repository at 866 http://www.ietf.org/ipr. 868 The IETF invites any interested party to bring to its attention any 869 copyrights, patents or patent applications, or other proprietary 870 rights that may cover technology that may be required to implement 871 this standard. Please address the information to the IETF at 872 ietf-ipr@ietf.org.