idnits 2.17.1 draft-ietf-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 748. 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 (March 4, 2007) is 6260 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-05 -- 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: 1 error (**), 0 flaws (~~), 2 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 Intended status: Standards Track March 4, 2007 5 Expires: September 5, 2007 7 A Document Format for Filtering and Reporting Location Notications in 8 the Presence Information Document Format Location Object (PIDF-LO) 9 draft-ietf-geopriv-loc-filters-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 5, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes filters which limit asynchronous location 43 notifications to compelling events. The resulting location 44 information is conveyed in existing location formats wrapped in 45 GEOPRIV privacy extensions to the Presence Information Document 46 Format (PIDF-LO). Location disclosure is limited to voluntary 47 disclosure by a notifier that possesses credentials for the named 48 resource. 50 Table of Contents 52 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Definition of Location Filter Format . . . . . . . . . . . . . 3 55 3.1. Horizontal and Vertical Movement . . . . . . . . . . . . . 4 56 3.2. Changes in value . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Containment Within a Region . . . . . . . . . . . . . . . 6 58 3.4. XML Schema for filter format . . . . . . . . . . . . . . . 9 59 4. Containment schema . . . . . . . . . . . . . . . . . . . . . . 10 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 6.1. MIME Registration for 63 application/location-delta-filter+xml . . . . . . . . . . 13 64 6.2. URN Sub-Namespace Registration for 65 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 13 66 6.3. Schema Registration For location-filter . . . . . . . . . 14 67 6.4. URN Sub-Namespace Registration for 68 urn:ietf:params:xml:ns:pidf:geopriv10:containment . . . . 14 69 6.5. Schema Registration For containment . . . . . . . . . . . 15 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 8.2. Informational References . . . . . . . . . . . . . . . . . 16 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Intellectual Property and Copyright Statements . . . . . . . . . . 17 77 1. Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC-2119 [2]. 83 2. Overview 85 Conveying static location in PIDF-LO [1] bodies is straightforward. 86 However the difficult part about asynchronous notification of 87 location information is that many forms of location are measured as a 88 continuous gradient. Unlike notifications using discreet quantities, 89 it is difficult to know when a change in location is large enough to 90 warrant a notification. Moreover, different applications require a 91 wide variety of location resolutions. Any optimization made for one 92 application would ultimately result in wasteful polling or a sluggish 93 user interface for other applications. 95 The mechanism described here defines filters in XML [3] documents 96 which limit location notification to events which are of relevance to 97 the subscriber. These filters persist until they are changed with a 98 replacement filter. 100 In addition to the relevant filters, this document also defines a new 101 XML schema [4] which can be included in PIDF-LO documents to indicate 102 that the resource is inside or outside of a container region. 104 3. Definition of Location Filter Format 106 The granularity of notifications necessary for various geographic 107 location applications varies dramatically. The subscriber should be 108 able to get asynchronous notifications with appropriate granularity 109 and accuracy, without having to poll or flood the network with 110 notifications which are not important to the application. 111 Notifications should only happen when the notification would be 112 considered an Interesting Event to the subscriber. This section of 113 this document defines an XML filter format to describe interesting 114 conditions or events. The terminal elements in this format are 115 defined in terms of existing Geographic Markup Language (GML) [9] 116 data types. 118 This document also defines a MIME type for this location filter 119 format: application/location-delta-filter+xml. 121 This document defines the following as an initial list of Interesting 122 Events: 124 1. the resource moves more than a specific distance horizontally or 125 vertically since the last notification 126 2. the resource exceeds a specific speed 127 3. the resource enters or exits one or more GML objects (for 128 example, a set of 2-dimensional or 3-dimensional regions) 129 included or referenced in the filter. 130 4. one or more of the values of the specified address labels has 131 changed for the resource (for example, the A1 value of the 132 civilAddress has changed from California to Nevada) 133 This specification makes use of XML namespaces [5] for identifying 134 location filter documents and document fragments. The namespace URI 135 for elements defined by this specification is a URN [10], using the 136 namespace identifier 'ietf' defined by [11] and extended by [12]. 137 This URN is: 139 urn:ietf:params:xml:ns:location-filter 141 The filter format starts with a top-level XML element called 142 "", which contains one or more filter events. The 143 semantics of multiple elements inside a location-filter is a logical 144 OR. In other words, if any of the individual filter events occurs, 145 the event satisfies the location-filter and triggers a notification. 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. 166 This filter measures the horizontal component of speed in any 167 direction. It does not measure velocity. Note also that there is 168 no corresponding event triggered when speed drops below a 169 threshold. 171 Below are some examples. In the first example if the resource moves 172 20m in the x,y direction or 3m in the z direction, send a 173 notification: 175 176 20 177 3 178 180 If the resource exceeds 3 meters per second (10.8 km/h), send a 181 notification: 183 184 3 185 187 3.2. Changes in value 189 The valueChanges filter event contains a string which is interpreted 190 as an XPath [6] expression evaluated within the context of the 191 location-info element of the PIDF-LO document which would be 192 generated by the notification. The XPath expression MUST evaluate to 193 only a single Xpath node. If the value of any of the elements in the 194 resulting node changes, then the filter event is triggered. Note 195 that the value of the resulting node changes if any of those nodes or 196 subnodes transitions from having a value to having no value or vice 197 versa. A location-filter may contain multiple valueChanges filters. 199 Note that the example below needs to be updated to use the revised 200 civic location format. 201 For example, given the following logical PIDF-LO document, If the 202 state (A1), county (A2), city (A3), or postal code (PC) changes, send 203 a notification: 205 PIDF-LO Location Document: 206 207 211 212 213 214 215 216 US 217 New York 218 New York 219 Broadway 220 123 221 Suite 75 222 10027 223 224 225 226 yes 227 2003-06-23T04:57:29Z 228 229 230 231 232 2003-06-22T20:57:29Z 233 234 236 Filter Document: 237 240 cl:civilAddress/cl:A1 241 cl:civilAddress/cl:A2 242 cl:civilAddress/cl:A3 243 cl:civilAddress/cl:PC 244 246 3.3. Containment Within a Region 248 Finally, the "enterOrExit" filter event is satisfied when the 249 resource enters or exits a named 2-dimensional or 3-dimensional 250 region described by one of the shapes defined in [8]. These regions 251 can be defined using inline snippets of GML, or externally referenced 252 using a URI (Uniform Resource Identifier). 254 These regions need a unique name or identifier so location with 255 respect to these regions can be described later (for example in a 256 notification). These regions are currently described as GML 257 Features so they can be named with a GML Name. Ideally each 258 region could be described instead as a GML geometry with some 259 associated name or identifier. 261 Any 2-dimensional region MUST be defined using the EPSG 4326 262 coordinate reference system. Any 3-dimensional region MUST be 263 defined using the EPSG 4979 coordinate reference system. A location- 264 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. XML Schema for filter format 361 The XML Schema for this format is defined below. 363 364 369 370 371 372 374 376 379 380 383 386 387 389 390 391 392 393 394 399 400 401 402 404 406 409 410 413 416 417 419 420 421 422 424 4. Containment schema 426 This section describes a schema for describing the resource's 427 location relative to a region or list of regions which might contain 428 the resource. (These regions can be defined dynamically in an 429 "enterOrExit" element in a subscription filter, or defined on the 430 notifier using some out-of-band mechanism.) The "pidfResource" 431 element is placed inside the location-info element in a PIDF-LO 432 document. The pidfResource element can contain zero or more 433 "containment" elements. Each containment element has a GML Feature 434 sub-element (of type "FeaturePropertyType") and a mandatory attribute 435 which specifies if the PIDF resource is inside or outside of the 436 feature, or if the position of the resource with respect to the 437 region or region list is undefined. 439 In a future version of this specification, the GML Feature can 440 become a reference to a more preferable name or identifier type. 441 The GML Feature type is only used because it includes a name to 442 reference it. 444 If the subscriber is not authorized to know the relative position, 445 the notifier MUST NOT reveal this private information. The 446 RECOMMENDED way to prevent the subscriber from seeing private 447 location data of this type is to return a containment element whose 448 position attribute is "undefined". Note that in some cases, the 449 containment information may be more interesting than the actual raw 450 location. It is not necessary to convey a concrete civic or geo 451 location in a PIDF-LO if the subscriber is only interested in or 452 authorized to see the containment status. 454 455 460 461 462 463 465 466 467 468 469 470 471 473 474 475 476 477 478 479 480 481 482 483 484 485 486 Below is an example PIDF-LO document which indicates that the 487 resource is inside building 10, not outside the parking garage, and 488 not permitted to know if the resource is in a conference room. Note 489 that in GML, these features could be referenced by their unique 490 identifiers instead. 492 493 497 498 499 500 501 502 503 504 Building 10 505 506 507 508 510 511 512 514 515 516 517 518 yes 519 2003-06-23T04:57:29Z 520 521 522 523 524 2003-06-22T20:57:29Z 525 526 528 5. Security Considerations 530 Location information is typically very privacy sensitive. As such, 531 GEOPRIV requires that notifications MUST be encrypted and integrity 532 protected. 534 Additional privacy and security considerations are discussed in 535 detail in [7]. 537 6. IANA Considerations 539 6.1. MIME Registration for application/location-delta-filter+xml 541 MIME media type name: application 543 MIME subtype name: application/location-delta-filter+xml 545 Required parameters: none. 547 Optional parameters: none. 549 Encoding considerations: Same as for XML. 551 Security considerations: See the "Security Considerations" 552 section in this document. 554 Interoperability considerations: none 556 Published specification: This document. 558 Applications which use this media: The application/ 559 location-delta-filter+xml application subtype supports the exchange 560 of filters to throttle asynchronous notifications of location 561 information. 563 Additional information: 565 1. Magic number(s): N/A 567 2. File extension(s): N/A 569 3. Macintosh file type code: N/A 571 6.2. URN Sub-Namespace Registration for 572 urn:ietf:params:xml:ns:location-filter 574 This section registers a new XML namespace, as per the guidelines in 575 [12]. 576 URI: The URI for this namespace is 577 urn:ietf:params:xml:ns:location-filter. 579 Registrant Contact: IETF, GEOPRIV working group, , 580 as delegated by the IESG . 581 XML: 583 BEGIN 584 585 587 588 589 591 Location Filter Namespace 592 593 594

Namespace for PIDF-LO Location Filters

595

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

596

See RFCXXXX.

597 598 599 END 601 6.3. Schema Registration For location-filter 603 This specification registers a schema, as per the guidelines in [12]. 604 URI: please assign. 605 Registrant Contact: IETF, GEOPRIV Working Group 606 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 607 XML: The XML can be found as the sole content of Section 3.4. 609 6.4. URN Sub-Namespace Registration for 610 urn:ietf:params:xml:ns:pidf:geopriv10:containment 612 This section registers a new XML namespace, as per the guidelines in 613 [12]. 614 URI: The URI for this namespace is 615 urn:ietf:params:xml:ns:pidf:geopriv10:containment. 616 Registrant Contact: IETF, GEOPRIV working group, , 617 as delegated by the IESG . 618 XML: 620 BEGIN 621 622 624 625 626 628 PIDF-LO Location Containment Namespace 629 630 631

Namespace for PIDF-LO location containment elements

632

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

633

See RFCXXXX.

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