idnits 2.17.1 draft-ietf-geopriv-loc-filters-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 27, 2010) is 5137 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) == Unused Reference: 'GML' is defined on line 712, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GML' == Outdated reference: A later version (-03) exists of draft-ietf-geopriv-arch-01 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-event-rate-control-03 ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-21 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV R. Mahy 3 Internet-Draft Individual 4 Intended status: Standards Track B. Rosen 5 Expires: September 28, 2010 NeuStar 6 H. Tschofenig 7 Nokia Siemens Networks 8 March 27, 2010 10 Filtering Location Notifications in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-geopriv-loc-filters-11.txt 14 Abstract 16 This document describes filters that limit asynchronous location 17 notifications to compelling events, designed as an extension to RFC 18 4661, an XML-based format for event notification filtering, and based 19 on RFC 3856, the SIP presence event package. The resulting location 20 information is conveyed in existing location formats wrapped in the 21 Presence Information Data Format Location Object (PIDF-LO). 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 28, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 7 69 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 10 70 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 12 71 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 14 72 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 75 6.1. URN Sub-Namespace Registration for 76 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 19 77 6.2. Schema Registration For location-filter . . . . . . . . . 19 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 82 9.2. Informational References . . . . . . . . . . . . . . . . . 24 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 85 1. Introduction 87 Conveying location information encapsulated with a Presence 88 Information Data Format Location Object (PIDF-LO) [RFC4119] document 89 within SIP is described in [I-D.ietf-sipcore-location-conveyance]. 90 An alternative signaling approach to location conveyance, which uses 91 asynchronous communication, is available with the SIP event 92 notification mechanisms (see RFC 3265 [RFC3265]). This document 93 focuses on the event notification paradigm. Event notifications are 94 technically more complex since location may be measured as a 95 continuous gradient and unlike notifications using discrete-valued 96 quantities, it is difficult to know when a change in location is 97 large enough to warrant a notification. Event notifications 98 [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) that 99 allow the number of notifications to be reduced. The mechanism 100 described in this document defines an extension to RFC 4661 101 [RFC4661], which limits location notification to events that are of 102 relevance to the subscriber. These filters persist until they are 103 changed with a replacement filter or when the subscription itself is 104 terminated. 106 The frequency of notifications necessary for various geographic 107 location applications varies dramatically. The subscriber should be 108 able to get asynchronous notifications with appropriate frequency and 109 granularity, without being flooded with a large number of 110 notifications that are not important to the application. 112 This document defines a new event filters and describes others using 113 existing mechanisms that may be relevant to a subscriber in the 114 context of location filtering. Based on the functionality defined in 115 this document notifications can be provided in the following cases: 117 1. the Device moves more than a specified distance since the last 118 notification (see Section 3.1). 120 2. the Device exceeds a specified speed (see Section 3.2). 122 3. the Device enters or exits a region, described by a circle or a 123 polygon (see Section 3.4). 125 4. one or more of the values of the specified address labels have 126 changed for the location of the Device (see Section 3.3). For 127 example, the value of the civic address element has changed 128 from 'California' to 'Nevada'. 130 5. the type of location information being requested (see 131 Section 3.5). 133 6. a certain amount of time passes (see Section 3.6). 135 This document builds on the presence event package [RFC3856], i. e. 136 an existing event package for communicating location information 137 inside the PIDF-LO. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 This document reuses terminology from [I-D.ietf-geopriv-arch]. 147 3. Filter Definitions 149 This specification builds on top of a number of other specifications, 150 as noted in Section 1. In order to reduce the number of options (and 151 thereby decrease the chance of interoperability problems), the 152 functionality of [RFC4661] listed in the sub-sections below MUST be 153 implemented, namely the (see Section 3.3 of [RFC4661]), 154 the (Section 3.4 of [RFC4661]), and the (Section 155 3.6 of [RFC4661] excluding the functionality of the and 156 element). 158 3.1. Movement 160 The element MUST contain a value in meters indicates the 161 minimum distance that the resource must have moved from the location 162 of the resource since the last notification was sent in order to 163 trigger this event. The distance MUST be measured in meters 164 absolutely from the point of last notification, and must include 165 vertical movement. The element MUST NOT appear more than 166 once as a child element of the element. 168 169 172 173 174 300 175 176 177 179 Figure 1: Movement Filter Example 181 3.2. Speed Changes 183 Speed changes can be filtered by combining functionality from RFC 184 4661 with the PIDF-LO extensions for spatial orientation, speed, 185 heading, and acceleration defined in 186 [I-D.singh-geopriv-pidf-lo-dynamic]. The value of the 187 element from [I-D.singh-geopriv-pidf-lo-dynamic] MUST be defined in 188 meters per second. Note that the condition could be met by a change 189 in any axis including altitude. 191 Figure 2 shows an example for a trigger that fires when the speed of 192 the Target changes by 3 meters per second. 194 195 196 197 199 200 201 202 203 //dyn:speed 204 205 206 207 209 Figure 2: Speed Change Example 211 An implementation MUST support to replace the namespace 212 prefix. The XPath expression MUST start with a '//' followed by a 213 single element. No other form of XPath expression is supported. The 214 element comes with a few attributes but only the 'by' 215 attribute MUST be implemented by this specification. 217 3.3. Element Value Changes 219 Changes in values, for example related to civic location information, 220 is provided by the base functionality offered with RFC 4661 utilizing 221 the element. 223 Figure 3 shows an example where a notification is sent when the civic 224 address tokens A1, A2, A3, and PC change (all four must change in 225 order to let the element evaluate to TRUE). 227 (A change in ALL four tokens triggers an event.) 229 230 231 232 234 235 236 237 //ca:country 238 //ca:A1 239 //ca:A2 240 //ca:A3 241 //ca:PC 242 243 244 246 Figure 3: Element Value Change Example 248 Note: The civic address tokens country, A1, A2, ..., A6 are 249 hierachical. It is likely that a change in one civic address token 250 therefore leads to changes of tokens lower in the hiearchy, e.g., a 251 change in A3 ('city or town') may cause a change in A4, A5, and A6. 253 In times where it is desirable to know if any one element of a list 254 of CAtypes changes, then they have to be put into separate 255 filters to ensure you are notified when any of the element values 256 change. Figure 4 shows such an example that illustrates the 257 difference. 259 (A change in value of ANY of the four tokens triggers an event.) 261 262 263 264 266 267 268 269 //ca:country 270 271 272 //ca:A1 273 274 275 //ca:A2 276 277 278 //ca:A3 279 280 281 //ca:PC 282 283 284 286 Figure 4: Element Value Change Example 288 The following example illustrates a filter that triggers when the 289 Target's location changes from 'FR' (France) to some other country. 291 292 293 294 296 297 298 299 //ca:country 300 301 302 304 Figure 5: Element Value Change Example (Country Change) 306 An implementation MUST support to replace the namespace 307 prefix. The XPath expression MUST start with a '//' followed by a 308 single element. No other form of XPath expression is supported. No 309 other variant is supported. The element comes with a few 310 attributes and the 'by', 'to' and 'from' attribute MUST be 311 implemented to support this specification. 313 3.4. Entering or Exiting a Region 315 The condition is satisfied when the Target enters or 316 exits a named 2-dimensional region described by a polygon (as defined 317 in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section 318 5.2.3 of [RFC5491]). The element MUST contain either a 319 polygon or a circle as a child element. The element 320 MUST NOT have more than one polygon and/or circle. 322 If the Target was previously outside the region, the notifier sends a 323 notification when the Target's location is within the region with at 324 least 50% confidence. Similarly, when a Target starts within the 325 region, a notification is sent when the Target's location moves 326 outside the region with at least 50% confidence. 328 Note that having 50% confidence that the Target is inside the area 329 does not correspond to 50% outside. The confidence that the location 330 is within the region, plus the confidence that the location is 331 outside the region is limited to the confidence of the location. The 332 total confidence depends on the confidence in the location, which is 333 always less than 100% (95% is recommended in [RFC5491]). The benefit 334 of this is that notifications are naturally limited: small movements 335 (relative to the uncertainty of the location) at the borders of the 336 region do not trigger notifications. 338 Figure 6 shows filter examples whereby a notification is sent when 339 the Target enters or exits an area described by a circle and Figure 7 340 describes an area using a polygon. 342 343 349 350 351 352 354 42.5463 -73.2512 355 357 850.24 358 359 360 361 362 363 365 Figure 6: Circle Filter Example 367 368 373 374 375 376 377 378 379 43.311 -73.422 380 381 43.111 -73.322 382 383 43.111 -73.222 384 385 43.311 -73.122 386 387 43.411 -73.222 388 389 43.411 -73.322 390 391 43.311 -73.422 392 393 394 395 396 397 398 399 401 Figure 7: Polygon Filter Example 403 3.5. Location Type 405 The element MAY be included as a child element of the 406 element and it contains a list of location information types 407 that are requested by the subscriber. The following list describes 408 the possible values: 410 any: The Notifier SHOULD attempt to provide LI in all forms 411 available to it. 413 geodetic: The Notifier SHOULD return a location by value in the form 414 of a geodetic location. 416 civic: The Notifier SHOULD return a location by value in the form of 417 a civic address. 419 The Notifier SHOULD return the requested location type or types. The 420 location types the Notifier returns also depends on the setting of 421 the optional 'exact' attribute. If the 'exact' attribute is set to 422 "true" then the Notifier MUST return either the requested location 423 type or no location information. The 'exact' attribute does not 424 apply (is ignored) for a request for a location type of "any". 426 In the case of a request for specific locationType(s) and the 'exact' 427 attribute is "false", the Notifier MAY provide additional location 428 types, or it MAY provide alternative types if the request cannot be 429 satisfied for a requested location type. 431 If the element is absent, a value of "any" MUST be 432 assumed as the default. 434 The Notifier SHOULD provide location in the response in the same 435 order in which they were included in the "locationType" element in 436 the request. Indeed, the primary advantage of including specific 437 location types in a request when the 'exact' attribute is set to 438 "false" is to ensure that one receives the available locations in a 439 specific order. For example, a subscription for "civic" (with the 440 'exact' attribute set to "false") could yield any of the following 441 location types in the response: 443 o civic 445 o civic, geodetic 447 o geodetic (only if civic is not available) 449 The default value of "false" for the 'exact' attribute allows the 450 Notifier the option of returning something beyond what is specified, 451 such as a set of location URIs when only a civic location was 452 requested. 454 An example is shown in Figure 8 that utilizes the 455 element with the 'exact' and the 'responseTime' attribute. 457 458 461 462 463 464 geodetic 465 466 467 468 470 Figure 8: Filter Example 472 3.6. Rate Control 474 [I-D.ietf-sipcore-event-rate-control] extends the SIP events 475 framework by defining the following three "Event" header field 476 parameters that allow a subscriber to set a minimum, a maximum and an 477 average rate of event notifications generated by the notifier. This 478 allows a subscriber to have overall control over the stream of 479 notifications, for example to avoid being flooded. Two of the 480 parameters, namely "min-interval" (which specifies a minimum 481 notification time period between two notifications, in seconds) and 482 "max-interval" (which specifies a maximum notification time period 483 between two notifications, in seconds.) are used by this document. 484 Only the implementation of these two attributes is required from the 485 attributes defined in [I-D.ietf-sipcore-event-rate-control]. 486 Whenever the time since the most recent notification exceeds the 487 value in the "max-interval" parameter, the current state would be 488 sent in its entirety, just like after a subscription refresh. 490 A notifier is required to send a NOTIFY request immediately after 491 creation of a subscription. If state is not available at that time, 492 then the NOTIFY request may be sent with no content. A separate 493 NOTIFY containing location is subsequently generated some time 494 between the time included in 'min-interval' and the time in 'max- 495 interval'. An important use case for location based applications 496 focuses on the behavior of the initial NOTIFY message(s) and the 497 information it returns, for example in case of emergency call 498 routing. When an initial NOTIFY is transmitted it might not include 499 complete state. 501 Subscriber Notifier 502 |---SUBSCRIBE(1)--->| Create subscription (w/small value 503 |<-------200--------| for min-interval and max-interval) 504 |<-----NOTIFY(2)----| Return initial notify with no state 505 |--------200------->| 506 |<-----NOTIFY(3)----| Return full state (between min-interval 507 |--------200------->| and max-interval) 508 |---SUBSCRIBE(4)--->| Update subscription (to update 509 |<-------200--------| min-interval and max-interval) 511 Figure 9: SUBSCRIBE/NOTIFY with Rate Control 513 Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE 514 message (1) has filters attached and contains a 'max-interval' rate 515 control parameter. In certain situations it is important to obtain 516 some amount of location information within a relatively short and 517 pre-defined period of time even if the obtained location information 518 contains a high amount of uncertainty and location information with 519 less uncertainty at a later point in time. An example is emergency 520 call routing where a emergency services routing proxy may need to 521 obtain location information suitable for routing rather quickly and 522 subsequently a Public Safety Answering Point requests location 523 information for dispatch. 525 To obtain location information in a timely fashion using the 526 SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial 527 SUBSCRIBE contains a 'max-interval' rate control parameter (with a 528 small value) that is in a later message updated to a more sensible 529 value. This provides equivalent functionality to the 'responseTime' 530 attribute in Section 6.1 of 531 [I-D.ietf-geopriv-http-location-delivery]. The 'max-interval' for 532 this first request is therefore much lower than thereafter. Updating 533 the 'max-interval' for the subscription can be performed in the 200 534 response (see message 3) to the NOTIFY that contains state. 535 Depending on the value in the 'max-interval' parameter the Notifier 536 may create a NOTIFY message (see message 2) immediately in response 537 to the SUBSCRIBE that might be empty in case no location information 538 is available at this point in time. The desired location information 539 may then arrive in the subsequent NOTIFY message (see message 4). 541 4. XML Schema 543 544 550 552 554 555 556 557 558 559 560 562 564 565 566 567 568 569 570 571 572 573 574 575 576 577 579 580 581 582 583 584 585 586 587 589 591 592 593 594 596 597 598 599 601 Figure 10: XML Schema 603 5. Security Considerations 605 This document specifies one piece, namely filters, utilized in larger 606 system. As such, this document builds on a number of specifications 607 for the security of the complete solution, namely 609 o the SIP event notification mechanism, described in RFC 3265 610 [RFC3265], defining the SUBSCRIBE/NOTIFY messages. 612 o the presence event package, described in RFC 3856 [RFC3856], which 613 is a concrete instantiation of the general event notification 614 framework. 616 o the filter framework, described in RFC 4661 [RFC4661], to offer 617 the ability to reduce the amount of notifications being sent. 619 Finally, this document indirectly (via the SIP presence event 620 package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the 621 XML container that carries location information. 623 Each of these documents listed above comes with a security 624 consideration section but the security and privacy aspects are best 625 covered by the SIP presence event package, see Section 9 of 626 [RFC3856], and with the GEOPRIV architectural description found in 627 [I-D.ietf-geopriv-arch]. 629 The functionality offered by authorization policies to limit access 630 to location information are provided by other protocols, such Common 631 Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or 632 more recent work around HELD context 633 [I-D.winterbottom-geopriv-held-context]. Although 634 [I-D.ietf-geopriv-policy] defines a standardized format for 635 geolocation authorization policies it does not define specific 636 policies for controlling filters. 638 The functionality described in this document extends the filter 639 framework with location specific filters. Local policies might be 640 associated with the usage of certain filter constructs and with the 641 amount of notifications specific filter settings might cause. 642 Uploading filters have a significant effect on the ways in which the 643 request is handled at a server. As a result, it is especially 644 important that messages containing this extension be authenticated 645 and authorised. RFC 4661 [RFC4661] discusses this security threat 646 and proposed authentication and authorization solutions applicable by 647 this specification. 649 6. IANA Considerations 651 6.1. URN Sub-Namespace Registration for 652 urn:ietf:params:xml:ns:location-filter 654 This section registers a new XML namespace, as per the guidelines in 655 [RFC3688]. 657 URI: urn:ietf:params:xml:ns:location-filter 659 Registrant Contact: IETF, GEOPRIV working group, , 660 as delegated by the IESG . 662 XML: 664 BEGIN 665 666 668 669 670 672 Location Filter Namespace 673 674 675

Namespace for PIDF-LO Location Filters

676

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

677

See RFCXXXX.

678 679 680 END 682 6.2. Schema Registration For location-filter 684 This specification registers a schema, as per the guidelines in 685 [RFC3688]. 687 URI: urn:ietf:params:xml:schema:location-filter 689 Registrant Contact: IETF, GEOPRIV Working Group 690 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 692 XML: The XML can be found as the sole content of Section 4. 694 7. Contributors 696 We would like to thank Martin Thomson and James Polk for their 697 contributions to this document. 699 8. Acknowledgments 701 Thanks to Richard Barnes and Alissa Cooper, Randall Gellens, Carl 702 Reed, Ben Campbell, Adam Roach, Allan Thomson, James Winterbottom for 703 their comments. 705 Furthermore, we would like to thank Alexey Melnikov for his IESG 706 review comments. 708 9. References 710 9.1. Normative References 712 [GML] OpenGIS, "Open Geography Markup Language (GML) 713 Implementation Specification", OpenGIS OGC 02-023r4, 714 January 2003, 715 . 717 [I-D.ietf-geopriv-arch] 718 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 719 Tschofenig, H., and H. Schulzrinne, "An Architecture for 720 Location and Location Privacy in Internet Applications", 721 draft-ietf-geopriv-arch-01 (work in progress), 722 October 2009. 724 [I-D.ietf-sipcore-event-rate-control] 725 Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 726 Protocol (SIP) Event Notification Extension for 727 Notification Rate Control", 728 draft-ietf-sipcore-event-rate-control-03 (work in 729 progress), February 2010. 731 [I-D.singh-geopriv-pidf-lo-dynamic] 732 Schulzrinne, H., Singh, V., Tschofenig, H., and M. 733 Thomson, "Dynamic Extensions to the Presence Information 734 Data Format Location Object (PIDF-LO)", 735 draft-singh-geopriv-pidf-lo-dynamic-09 (work in progress), 736 March 2010. 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 742 Event Notification", RFC 3265, June 2002. 744 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 745 Initiation Protocol (SIP)", RFC 3856, August 2004. 747 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 748 Format", RFC 4119, December 2005. 750 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 751 Requena, "An Extensible Markup Language (XML)-Based Format 752 for Event Notification Filtering", RFC 4661, 753 September 2006. 755 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 756 Presence Information Data Format Location Object (PIDF-LO) 757 Usage Clarification, Considerations, and Recommendations", 758 RFC 5491, March 2009. 760 9.2. Informational References 762 [I-D.ietf-geopriv-http-location-delivery] 763 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 764 "HTTP Enabled Location Delivery (HELD)", 765 draft-ietf-geopriv-http-location-delivery-16 (work in 766 progress), August 2009. 768 [I-D.ietf-geopriv-policy] 769 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 770 and J. Polk, "Geolocation Policy: A Document Format for 771 Expressing Privacy Preferences for Location Information", 772 draft-ietf-geopriv-policy-21 (work in progress), 773 January 2010. 775 [I-D.ietf-sipcore-location-conveyance] 776 Polk, J. and B. Rosen, "Location Conveyance for the 777 Session Initiation Protocol", 778 draft-ietf-sipcore-location-conveyance-02 (work in 779 progress), February 2010. 781 [I-D.winterbottom-geopriv-held-context] 782 Winterbottom, J., Tschofenig, H., and M. Thomson, 783 "Location URI Contexts in HTTP-Enabled Location Delivery 784 (HELD)", draft-winterbottom-geopriv-held-context-05 (work 785 in progress), October 2009. 787 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 788 January 2004. 790 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 791 Polk, J., and J. Rosenberg, "Common Policy: A Document 792 Format for Expressing Privacy Preferences", RFC 4745, 793 February 2007. 795 Authors' Addresses 797 Rohan Mahy 798 Individual 800 Email: rohan@ekabal.com 802 Brian Rosen 803 NeuStar 804 470 Conrad Dr. 805 Mars, PA 16046 806 US 808 Phone: +1 724 382 1051 809 Email: br@brianrosen.net 811 Hannes Tschofenig 812 Nokia Siemens Networks 813 Linnoitustie 6 814 Espoo 02600 815 Finland 817 Phone: +358 (50) 4871445 818 Email: Hannes.Tschofenig@gmx.net 819 URI: http://www.tschofenig.priv.at