idnits 2.17.1 draft-ietf-geopriv-loc-filters-10.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 6, 2010) is 5164 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 690, but no explicit reference was found in the text == Unused Reference: 'RFC3023' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC4288' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-http-location-delivery' is defined on line 746, 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 == Outdated reference: A later version (-09) exists of draft-singh-geopriv-pidf-lo-dynamic-07 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == 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: 4 errors (**), 0 flaws (~~), 10 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 7, 2010 NeuStar 6 H. Tschofenig 7 Nokia Siemens Networks 8 March 6, 2010 10 Filtering Location Notifications in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-geopriv-loc-filters-10.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 7, 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 . . . . . . . . . . . . . . . 9 70 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 11 71 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 13 72 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 6.1. URN Sub-Namespace Registration for 76 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 18 77 6.2. Schema Registration For location-filter . . . . . . . . . 18 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 82 9.2. Informational References . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 85 1. Introduction 87 Conveying location information encapsulated with a PIDF-LO [RFC4119] 88 document within SIP is described in 89 [I-D.ietf-sipcore-location-conveyance]. An alternative signaling 90 approach, which uses asynchronous communication, is available with 91 the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This 92 document focuses on the event notification paradigm. Event 93 notifications are technical more complex since location may be 94 measured as a continuous gradient and unlike notifications using 95 discrete-valued quantities, it is difficult to know when a change in 96 location is large enough to warrant a notification. Event 97 notifications [RFC3265] can be used with filters (see RFC 4661 98 [RFC4661]) that allows the number of notifications to be reduced. 99 The mechanism described in this document defines an extension to RFC 100 4661 [RFC4661], which limits location notification to events that are 101 of relevance to the subscriber. These filters persist until they are 102 changed with a replacement filter. 104 The frequency of notifications necessary for various geographic 105 location applications varies dramatically. The subscriber should be 106 able to get asynchronous notifications with appropriate frequency and 107 granularity, without having to issue a large number of notifications 108 that are not important to the application. 110 This document defines a new event filters and describes others using 111 existing mechanisms that may be relevant to a subscriber in the 112 context of location filtering: 114 1. the Device moves more than a specified distance since the last 115 notification (see Section 3.1). 117 2. the Device exceeds a specified speed (see Section 3.2). 119 3. the Device enters or exits a region, described by a circle or a 120 polygon (see Section 3.4). 122 4. one or more of the values of the specified address labels have 123 changed for the location of the Device (see Section 3.3). For 124 example, the value of the civic address element has changed 125 from 'California' to 'Nevada'. 127 5. the type of location information being requested (see 128 Section 3.5). 130 6. the rate at which location information delivery is desired (see 131 Section 3.6). 133 This document builds on the presence event package [RFC3856], i.e. an 134 existing event package for communicating location information inside 135 the PIDF-LO. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 This document reuses terminology from [I-D.ietf-geopriv-arch]. 145 3. Filter Definitions 147 This specification builds on top of a number of other specifications, 148 as noted in Section 1. In order to reduce the number of options (and 149 thereby decrease the chance of interoperability problems), the 150 functionality of [RFC4661] listed in the sub-sections below MUST be 151 implemented, namely the (see Section 3.3 of [RFC4661]), 152 the (Section 3.4 of [RFC4661]), and the (Section 153 3.6 of [RFC4661] excluding the functionality of the and 154 element). 156 3.1. Movement 158 The element MUST contain a value in meters indicates the 159 minimum distance that the resource must have moved from the location 160 of the resource since the last notification was sent in order to 161 trigger this event. Note that the condition could be met by a change 162 in any axis including altitude. The distance MUST be measured in 163 meters absolutely from the point of last notification. The 164 element MUST NOT appear more than once as a child element of the 165 element. 167 168 171 172 173 300 174 175 176 178 Figure 1: Movement Filter Example 180 3.2. Speed Changes 182 Speed changes can be filtered by combining functionality from RFC 183 4661 with the PIDF-LO extensions for spatial orientation, speed, 184 heading, and acceleration defined in 185 [I-D.singh-geopriv-pidf-lo-dynamic]. The value of the 186 element from [I-D.singh-geopriv-pidf-lo-dynamic] MUST be defined in 187 meters per second. Note that the condition could be met by a change 188 in any axis including altitude. 190 Figure 2 shows an example for a trigger that fires when the speed of 191 the Target changes by 3 meters per second. 193 194 195 196 198 199 200 201 202 //dyn:speed 203 204 205 206 208 Figure 2: Speed Change Example 210 An implementation MUST support the functionality as shown in Figure 2 211 with replacing the prefix. No other variant is 212 supported. The element comes with a few attributes but 213 only the 'by' attribute MUST be implemented by this specification. 215 3.3. Element Value Changes 217 Changes in values, for example related to civic location information, 218 is provided by the base functionality offered with RFC 4661 utilizing 219 the element. 221 Figure 3 shows an example where a notification is sent when the civic 222 address tokens A1, A2, A3, or PC change (all four must change in 223 order to let the element evaluate to TRUE). 225 226 227 228 230 231 232 233 //ca:A1 234 //ca:A2 235 //ca:A3 236 //ca:PC 237 238 239 241 Figure 3: Element Value Change Example 243 In times where it is desireable to know if any one element of a list 244 of CAtypes changes, then they have to be put into separate 245 filters to ensure you are notified when any of the element values 246 change. Figure 4 shows such an example that illustrates the 247 difference. 249 250 251 252 254 255 256 257 //ca:A1 258 259 260 //ca:A2 261 262 263 //ca:A3 264 265 266 //ca:PC 267 268 269 271 Figure 4: Element Value Change Example 273 The following example illustrates a filter that triggers when the 274 Target's location changes from 'FR' (France) to some other country. 276 277 278 279 281 282 283 284 //ca:country 285 286 287 289 Figure 5: Element Value Change Example (Country Change) 291 An implementation MUST support the functionality as shown in Figure 3 292 with replacing the prefix. No other variant is 293 supported. The element comes with a few attributes and the 294 'by', 'to' and 'from' attribute MUST be implemented to support this 295 specification. 297 3.4. Entering or Exiting a Region 299 The condition is satisfied when the Target enters or 300 exits a named 2-dimensional region described by a polygon (as defined 301 in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section 302 5.2.3 of [RFC5491]). The element MUST contain either a 303 polygon or a circle as a child element. The element 304 MUST NOT have more than one polygon and/or circle. 306 If the Target was previously outside the region, the notifier sends a 307 notification when the Target's location is within the region with at 308 least 50% confidence. Similarly, when a Target starts within the 309 region, a notification is sent when the Target's location moves 310 outside the region with at least 50% confidence. 312 Note that having 50% confidence that the Target is inside the area 313 does not correspond to 50% outside. The confidence that the location 314 is within the region, plus the confidence that the location is 315 outside the region is limited to the confidence of the location. The 316 total confidence depends on the confidence in the location, which is 317 always less than 100% (95% is recommended in [RFC5491]). The benefit 318 of this is that notifications are naturally limited: small movements 319 at the borders of the region do not trigger notifications. 321 Figure 6 shows filter examples whereby a notification is sent when 322 the Target enters or exits an area described by a circle and Figure 7 323 describes an area using a polygon. 325 326 332 333 334 335 337 42.5463 -73.2512 338 340 850.24 341 342 343 344 345 346 348 Figure 6: Circle Filter Example 350 351 356 357 358 359 360 361 362 43.311 -73.422 363 364 43.111 -73.322 365 366 43.111 -73.222 367 368 43.311 -73.122 369 370 43.411 -73.222 371 372 43.411 -73.322 373 374 43.311 -73.422 375 376 377 378 379 380 381 382 384 Figure 7: Polygon Filter Example 386 3.5. Location Type 388 The element MAY be included as a child element of the 389 element and it contains a list of location information types 390 that are requested by the subscriber. The following list describes 391 the possible values: 393 any: The Notifier SHOULD attempt to provide LI in all forms 394 available to it. 396 geodetic: The Notifier SHOULD return a location by value in the form 397 of a geodetic location. 399 civic: The Notifier SHOULD return a location by value in the form of 400 a civic address. 402 The Notifier SHOULD return the requested location type or types. The 403 location types the Notifier returns also depends on the setting of 404 the optional 'exact' attribute. If the 'exact' attribute is set to 405 "true" then the Notifier MUST return either the requested location 406 type or no location information. The 'exact' attribute does not 407 apply (is ignored) for a request for a location type of "any". 409 In the case of a request for specific locationType(s) and the 'exact' 410 attribute is "false", the Notifier MAY provide additional location 411 types, or it MAY provide alternative types if the request cannot be 412 satisfied for a requested location type. 414 If the element is absent, a value of "any" MUST be 415 assumed as the default. 417 The Notifier SHOULD provide location in the response in the same 418 order in which they were included in the "locationType" element in 419 the request. Indeed, the primary advantage of including specific 420 location types in a request when the 'exact' attribute is set to 421 "false" is to ensure that one receives the available locations in a 422 specific order. For example, a subscription for "civic" (with the 423 'exact' attribute set to "false") could yield any of the following 424 location types in the response: 426 o civic 428 o civic, geodetic 430 o geodetic (only if civic is not available) 432 The default value of "false" for the 'exact' attribute allows the 433 Notifier the option of returning something beyond what is specified, 434 such as a set of location URIs when only a civic location was 435 requested. 437 An example is shown in Figure 8 that utilizes the 438 element with the 'exact' and the 'responseTime' attribute. 440 441 444 445 446 447 geodetic 448 449 450 451 453 Figure 8: Filter Example 455 3.6. Rate Control 457 [I-D.ietf-sipcore-event-rate-control] extends the SIP events 458 framework by defining the following three "Event" header field 459 parameters that allow a subscriber to set a minimum, a maximum and an 460 average rate of event notifications generated by the notifier. This 461 allows a subscriber to have overall control over the stream of 462 notifications, for example to avoid being flooded. Two of the 463 parameters, namely "min-interval" (which specifies a minimum 464 notification time period between two notifications, in seconds) and 465 "max-interval" (which specifies a maximum notification time period 466 between two notifications, in seconds.) are used by this document. 467 The implementation of only these two attributes is required from the 468 complete set of attributes defined in 469 [I-D.ietf-sipcore-event-rate-control]. Whenever the time since the 470 most recent notification exceeds the value in the "max-interval" 471 parameter, the current state would be sent in its entirety, just like 472 after a subscription refresh. 474 If complete state is not immediately available, then an empty NOTIFY 475 is sent immediately and subsequently a separate NOTIFY containing 476 location is generated some time between the time included in 'min- 477 interval' and the time in 'max-interval'. An important use case for 478 location based applications focuses on the behavior of the initial 479 NOTIFY message(s) and the information it returns, for example in case 480 of emergency call routing. When an initial NOTIFY is transmitted it 481 might not include complete state. 483 Subscriber Notifier 484 |---SUBSCRIBE(1)--->| Request state subscription 485 |<-------200--------| Acknowledge subscription 486 |<-----NOTIFY(2)----| Return current state information 487 |-------200(3)----->| 488 |<-----NOTIFY(4)----| Return current state information 489 |--------200------->| 491 Figure 9: SUBSCRIBE/NOTIFY with Rate Control 493 Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE 494 message (1) has filters attached and contains a 'max-interval' rate 495 control parameter. In certain situations it is important to obtain 496 some amount of location information within a relatively short and 497 pre-defined period of time even if the obtained location information 498 contains a high amount of uncertainty and location information with 499 less uncertainty at a later point in time. An example is emergency 500 call routing where a emergency services routing proxy may need to 501 obtain location information suitable for routing rather quickly and 502 subsequently a Public Safety Answering Point requests location 503 information for dispatch. 505 To obtain location information in a timely fashion using the 506 SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial 507 SUBSCRIBE contains a 'max-interval' rate control parameter (with a 508 small value) that is in a later message updated to a more sensible 509 value. The 'max-interval' for this first request is therefore much 510 lower than thereafter. Updating the 'max-interval' for the 511 subscription can be performed in the 200 response (see message 3) to 512 the NOTIFY that contains state. Depending on the value in the 'max- 513 interval' parameter the Notifier may create a NOTIFY message (see 514 message 2) immediately in response to the SUBSCRIBE that might be 515 empty in case no location information is available at this point in 516 time. The desired location information may then arrive in the 517 subsequent NOTIFY message (see message 4). 519 4. XML Schema 521 522 528 530 532 533 534 535 536 537 538 540 542 543 544 545 546 547 548 549 550 551 552 553 554 555 557 558 559 560 561 562 563 564 565 567 569 570 571 572 574 575 576 577 579 Figure 10: XML Schema 581 5. Security Considerations 583 This document specifies one piece, namely filters, utilized in larger 584 system. As such, this document builds on a number of specifications 585 for the security of the complete solution, namely 587 o the SIP event notification mechanism, described in RFC 3265 588 [RFC3265], defining the SUBSCRIBE/NOTIFY messages. 590 o the presence event package, described in RFC 3856 [RFC3856], which 591 is a concrete instantiation of the general event notification 592 framework. 594 o the filter framework, described in RFC 4661 [RFC4661], to offer 595 the ability to reduce the amount of notifications being sent. 597 Finally, this document indirectly (via the SIP presence event 598 package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the 599 XML container that carries location information. 601 Each of these documents listed above comes with a security 602 consideration section but the security and privacy aspects are best 603 covered by the SIP presence event package, see Section 9 of 604 [RFC3856], and with the GEOPRIV architectural description found in 605 [I-D.ietf-geopriv-arch]. 607 The functionality offered by authorization policies to limit access 608 to location information are provided by other protocols, such Common 609 Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or 610 more recent work around HELD context 611 [I-D.winterbottom-geopriv-held-context]. Although 612 [I-D.ietf-geopriv-policy] defines a standardized format for 613 geolocation authorization policies it does not define specific 614 policies for controlling filters. 616 The functionality described in this document extends the filter 617 framework with location specific filters. Local policies might be 618 associated with the usage of certain filter constructs and with the 619 amount of notifications specific filter settings might cause. 620 Uploading filters have a significant effect on the ways in which the 621 request is handled at a server. As a result, it is especially 622 important that messages containing this extension be authenticated 623 and authorised. RFC 4661 [RFC4661] discusses this security threat 624 and proposed authentication and authorization solutions applicable by 625 this specification. 627 6. IANA Considerations 629 6.1. URN Sub-Namespace Registration for 630 urn:ietf:params:xml:ns:location-filter 632 This section registers a new XML namespace, as per the guidelines in 633 [RFC3688]. 635 URI: urn:ietf:params:xml:ns:location-filter 637 Registrant Contact: IETF, GEOPRIV working group, , 638 as delegated by the IESG . 640 XML: 642 BEGIN 643 644 646 647 648 650 Location Filter Namespace 651 652 653

Namespace for PIDF-LO Location Filters

654

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

655

See RFCXXXX.

656 657 658 END 660 6.2. Schema Registration For location-filter 662 This specification registers a schema, as per the guidelines in 663 [RFC3688]. 665 URI: urn:ietf:params:xml:schema:location-filter 667 Registrant Contact: IETF, GEOPRIV Working Group 668 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 670 XML: The XML can be found as the sole content of Section 4. 672 7. Contributors 674 We would like to thank Martin Thomson and James Polk for their 675 contributions to this document. 677 8. Acknowledgments 679 Thanks to Richard Barnes and Alissa Cooper, Randall Gellens, Carl 680 Reed, Adam Roach, Allan Thomson, James Winterbottom for their 681 comments. 683 Furthermore, we would like to thank Alexey Melnikov for his IESG 684 review comments. 686 9. References 688 9.1. Normative References 690 [GML] OpenGIS, "Open Geography Markup Language (GML) 691 Implementation Specification", OpenGIS OGC 02-023r4, 692 January 2003, 693 . 695 [I-D.ietf-geopriv-arch] 696 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 697 Tschofenig, H., and H. Schulzrinne, "An Architecture for 698 Location and Location Privacy in Internet Applications", 699 draft-ietf-geopriv-arch-01 (work in progress), 700 October 2009. 702 [I-D.ietf-sipcore-event-rate-control] 703 Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 704 Protocol (SIP) Event Notification Extension for 705 Notification Rate Control", 706 draft-ietf-sipcore-event-rate-control-03 (work in 707 progress), February 2010. 709 [I-D.singh-geopriv-pidf-lo-dynamic] 710 Schulzrinne, H., Singh, V., Tschofenig, H., and M. 711 Thomson, "Dynamic Extensions to the Presence Information 712 Data Format Location Object (PIDF-LO)", 713 draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress), 714 August 2009. 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 720 Types", RFC 3023, January 2001. 722 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 723 Event Notification", RFC 3265, June 2002. 725 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 726 Initiation Protocol (SIP)", RFC 3856, August 2004. 728 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 729 Format", RFC 4119, December 2005. 731 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 732 Registration Procedures", BCP 13, RFC 4288, December 2005. 734 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 735 Requena, "An Extensible Markup Language (XML)-Based Format 736 for Event Notification Filtering", RFC 4661, 737 September 2006. 739 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 740 Presence Information Data Format Location Object (PIDF-LO) 741 Usage Clarification, Considerations, and Recommendations", 742 RFC 5491, March 2009. 744 9.2. Informational References 746 [I-D.ietf-geopriv-http-location-delivery] 747 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 748 "HTTP Enabled Location Delivery (HELD)", 749 draft-ietf-geopriv-http-location-delivery-16 (work in 750 progress), August 2009. 752 [I-D.ietf-geopriv-policy] 753 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 754 and J. Polk, "Geolocation Policy: A Document Format for 755 Expressing Privacy Preferences for Location Information", 756 draft-ietf-geopriv-policy-21 (work in progress), 757 January 2010. 759 [I-D.ietf-sipcore-location-conveyance] 760 Polk, J. and B. Rosen, "Location Conveyance for the 761 Session Initiation Protocol", 762 draft-ietf-sipcore-location-conveyance-02 (work in 763 progress), February 2010. 765 [I-D.winterbottom-geopriv-held-context] 766 Winterbottom, J., Tschofenig, H., and M. Thomson, 767 "Location URI Contexts in HTTP-Enabled Location Delivery 768 (HELD)", draft-winterbottom-geopriv-held-context-05 (work 769 in progress), October 2009. 771 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 772 January 2004. 774 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 775 Polk, J., and J. Rosenberg, "Common Policy: A Document 776 Format for Expressing Privacy Preferences", RFC 4745, 777 February 2007. 779 Authors' Addresses 781 Rohan Mahy 782 Individual 784 Email: rohan@ekabal.com 786 Brian Rosen 787 NeuStar 788 470 Conrad Dr. 789 Mars, PA 16046 790 US 792 Phone: +1 724 382 1051 793 Email: br@brianrosen.net 795 Hannes Tschofenig 796 Nokia Siemens Networks 797 Linnoitustie 6 798 Espoo 02600 799 Finland 801 Phone: +358 (50) 4871445 802 Email: Hannes.Tschofenig@gmx.net 803 URI: http://www.tschofenig.priv.at