idnits 2.17.1 draft-ietf-geopriv-loc-filters-08.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 (November 8, 2009) is 5282 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 640, but no explicit reference was found in the text == Unused Reference: 'RFC3023' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC4288' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-http-location-delivery' is defined on line 696, 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-00 == 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-01 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: May 12, 2010 NeuStar 6 H. Tschofenig 7 Nokia Siemens Networks 8 November 8, 2009 10 Filtering Location Notifications in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-geopriv-loc-filters-08.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 May 12, 2010. 46 Copyright Notice 48 Copyright (c) 2009 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 . . . . . . . . . . . . . . . 8 70 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10 71 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12 72 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. URN Sub-Namespace Registration for 76 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 17 77 6.2. Schema Registration For location-filter . . . . . . . . . 17 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 82 9.2. Informational References . . . . . . . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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. The distance MUST be measured in meters 162 absolutely from the point of last notification. The element 163 MUST NOT appear more than once as a child element of the 164 element. 166 167 170 171 300 172 173 175 Figure 1: Movement Filter Example 177 3.2. Speed Changes 179 Speed changes can be filtered with the help of RFC 4661 and the 180 functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which 181 extends the PIDF-LO with support for spatial orientation, speed, 182 heading, and acceleration. The value of in 183 [I-D.singh-geopriv-pidf-lo-dynamic] and MUST be defined in meters per 184 second. 186 Figure 2 shows an example for a trigger that fires when the speed of 187 the Target changes by 3 meters per second. 189 190 191 192 194 195 196 197 198 //dyn:speed 199 200 201 202 204 Figure 2: Speed Change Example 206 An implementation MUST support the functionality as shown in Figure 2 207 with replacing the prefix. No other variant is 208 supported. The element comes with a few attributes but 209 only the 'by' attribute MUST be implemented by this specification. 211 3.3. Element Value Changes 213 Changes in values, for example related to civic location information, 214 is provided by the base functionality offered with RFC 4661 utilizing 215 the element. 217 Figure 3 shows an example where a notification is sent when the civic 218 address tokens A1, A2, A3, or PC change (all 4 must change in order 219 to let the element evaluate to TRUE). In times where it is 220 desireable to know if any one individual of a list of CAtypes change, 221 then they have to be put into separate filters to ensure 222 you are notified when any of the element values change. 224 225 226 227 229 230 231 232 //ca:A1 233 //ca:A2 234 //ca:A3 235 //ca:PC 236 237 238 240 Figure 3: Speed Change Example 242 The following example illustrates a filter that triggers when the 243 Target's location changes from 'FR' (France) to some other country. 245 246 247 248 250 251 252 253 //ca:country 254 255 256 258 Figure 4: Speed Change Example (Country Change) 260 An implementation MUST support the functionality as shown in Figure 3 261 with replacing the prefix. No other variant is 262 supported. The element comes with a few attributes and the 263 'by', 'to' and 'from' attribute MUST be implemented to support this 264 specification. 266 3.4. Entering or Exiting a Region 268 The condition is satisfied when the Target enters or 269 exits a named 2-dimensional region described by a polygon (as defined 270 in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section 271 5.2.3 of [RFC5491]). The element MUST contain either a 272 polygon or a circle as a child element. The element 273 MUST NOT have more than one polygon and/or circle. 275 If the Target was previously outside the region, the notifier sends a 276 notification when the Target's location is within the region with at 277 least 50% confidence. Similarly, when a Target starts within the 278 region, a notification is sent when the Target's location moves 279 outside the region with at least 50% confidence. 281 Note that having 50% confidence that the Target is inside the area 282 does not correspond to 50% outside. Confidence that the location is 283 within the region, plus confidence that the location is outside the 284 region cannot be 100%. The total confidence depends on the 285 confidence in the original location, which is always less than 100% 286 (95% is recommended in [RFC5491]). The benefit of this is that 287 notifications are naturally limited: small movements at the borders 288 of the region do not trigger notifications. 290 Figure 5 shows filter examples whereby a notification is sent when 291 the Target enters or exits an area described by a circle and Figure 6 292 describes an area using a polygon. 294 295 301 302 303 304 42.5463 -73.2512 305 306 850.24 307 308 309 310 311 313 Figure 5: Circle Filter Example 315 316 320 321 322 323 324 325 43.311 -73.422 326 43.111 -73.322 327 43.111 -73.222 328 43.311 -73.122 329 43.411 -73.222 330 43.411 -73.322 331 43.311 -73.422 332 333 334 335 336 337 339 Figure 6: Polygon Filter Example 341 3.5. Location Type 343 The element MAY be included as a child element of the 344 element and it contains a list of location information types 345 that are requested by the subscriber. The following list describes 346 the possible values: 348 any: The Notifier SHOULD attempt to provide LI in all forms 349 available to it. 351 geodetic: The Notifier SHOULD return a location by value in the form 352 of a geodetic location. 354 civic: The Notifier SHOULD return a location by value in the form of 355 a civic address. 357 The Notifier SHOULD return the requested location type or types. The 358 location types the Notifier returns also depends on the setting of 359 the optional "exact" attribute. If the 'exact' attribute is set to 360 "true" then the Notifier MUST return either the requested location 361 type or no location information. The 'exact' attribute does not 362 apply (is ignored) for a request for a location type of "any". 364 In the case of a request for specific locationType(s) and the 'exact' 365 attribute is false, the Notifier MAY provide additional location 366 types, or it MAY provide alternative types if the request cannot be 367 satisfied for a requested location type. 369 If the element is absent, a value of "any" MUST be 370 assumed as the default. 372 The Notifier SHOULD provide location in the response in the same 373 order in which they were included in the "locationType" element in 374 the request. Indeed, the primary advantage of including specific 375 location types in a request when the 'exact' attribute is set to 376 "false" is to ensure that one receives the available locations in a 377 specific order. For example, a subscription for "civic" (with the 378 'exact' attribute set to "false") could yield any of the following 379 location types in the response: 381 o civic 383 o civic, geodetic 385 o geodetic (only if civic is not available) 387 The default value of "false" for the 'exact' attribute allows the 388 Notifier the option of returning something beyond what is specified, 389 such as a set of location URIs when only a civic location was 390 requested. 392 An example is shown in Figure 7 that utilizes the 393 element with the 'exact' and the 'responseTime' attribute. 395 396 399 400 401 geodetic 402 403 404 406 Figure 7: Filter Example 408 3.6. Rate Control 410 [I-D.ietf-sipcore-event-rate-control] defines an extension to the SIP 411 events framework defining the following three "Event" header field 412 parameters that allow a subscriber to set a minimum, a maximum and an 413 average rate of event notifications generated by the notifier. This 414 document makes use of two of the parameters, namely "min-interval" 415 (which specifies a minimum notification time period between two 416 notifications, in seconds) and "max-interval" (which specifies a 417 maximum notification time period between two notifications, in 418 seconds.). The implementation of only these two attributes is 419 required from the complete set of attributes defined in 420 [I-D.ietf-sipcore-event-rate-control]. Whenever the time since the 421 most recent notification exceeds the value in the "max-interval" 422 parameter, the current state would be sent in its entirety, just like 423 after a subscription refresh. 425 If complete state is not immediately available, then an empty NOTIFY 426 is sent immediately and subsequently a separate NOTIFY containing 427 location is generated some time between the time included in 'min- 428 interval' and the time in 'max-interval'. An important use case for 429 location based applications focuses on the behavior of the initial 430 NOTIFY message(s) and the information it returns, for example in case 431 of emergency call routing. When an initial NOTIFY is transmitted it 432 might not include complete state. 434 Subscriber Notifier 435 |---SUBSCRIBE(1)--->| Request state subscription 436 |<-------200--------| Acknowledge subscription 437 |<-----NOTIFY(2)----| Return current state information 438 |-------200(3)----->| 439 |<-----NOTIFY(4)----| Return current state information 440 |--------200------->| 442 Figure 8: SUBSCRIBE/NOTIFY with Rate Control 444 Figure 8 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE 445 message (1) has filters attached and contains a 'max-interval' rate 446 control parameter. In certain situations it is important to obtain 447 some amount of location information within a relatively short and 448 pre-defined period of time even if the obtained location information 449 contains a high amount of uncertainty and location information with 450 less uncertainty at a later point in time. An example is emergency 451 call routing where a emergency services routing proxy may need to 452 obtain location information suitable for routing rather quickly and 453 subsequently a Public Safety Answering Point requests location 454 information for dispatch. 456 To obtain location information in a timely fashion using the 457 SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial 458 SUBSCRIBE contains a 'max-interval' rate control parameter (with a 459 small value) that is in a later message updated to a more sensible 460 value. The 'max-interval' for this first request is therefore much 461 lower than thereafter. Updating the 'max-interval' for the 462 subscription can be performed in the 200 response (see message 3) to 463 the NOTIFY that contains state. Depending on the value in the 'max- 464 interval' parameter the Notifier may create a NOTIFY message (see 465 message 2) immediately in response to the SUBSCRIBE that might be 466 empty in case no location information is available at this point in 467 time. The desired location information may then arrive in the 468 subsequent NOTIFY message (see message 4). 470 4. XML Schema 472 473 479 483 485 487 488 489 490 491 492 493 495 497 498 499 500 501 502 503 504 505 506 507 508 509 510 512 513 514 515 516 517 518 519 520 521 523 524 525 526 528 529 530 531 533 Figure 9: XML Schema 535 5. Security Considerations 537 This document specifies one piece, namely filters, utilized in larger 538 system. As such, this document builds on a number of specifications 539 for the security of the complete solution, namely 541 o the SIP event notification mechanism, described in RFC 3265 542 [RFC3265], defining the SUBSCRIBE/NOTIFY messages. 544 o the presence event package, described in RFC 3856 [RFC3856], which 545 is a concrete instantiation of the general event notification 546 framework. 548 o the filter framework, described in RFC 4661 [RFC4661], to offer 549 the ability to reduce the amount of notifications being sent. 551 Finally, this document indirectly (via the SIP presence event 552 package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the 553 XML container that carries location information. 555 Each of these documents listed above comes with a security 556 consideration section but the security and privacy aspects are best 557 covered by the SIP presence event package, see Section 9 of 558 [RFC3856], and with the GEOPRIV architectural description found in 559 [I-D.ietf-geopriv-arch]. 561 The functionality offered by authorization policies to limit access 562 to location information are provided by other protocols, such Common 563 Policy [RFC4745], Geolocation Policy [I-D.ietf-geopriv-policy] or 564 more recent work around HELD context 565 [I-D.winterbottom-geopriv-held-context]. Although 566 [I-D.ietf-geopriv-policy] defines a standardized format for 567 geolocation authorization policies it does not define specific 568 policies for controlling filters. 570 The functionality described in this document extends the filter 571 framework with location specific filters. Local policies might be 572 associated with the usage of certain filter constructs and with the 573 amount of notifications specific filter settings might cause. 574 Uploading filters have a significant effect on the ways in which the 575 request is handled at a server. As a result, it is especially 576 important that messages containing this extension be authenticated 577 and authorised. RFC 4661 [RFC4661] discusses this security threat 578 and proposed authentication and authorization solutions applicable by 579 this specification. 581 6. IANA Considerations 583 6.1. URN Sub-Namespace Registration for 584 urn:ietf:params:xml:ns:location-filter 586 This section registers a new XML namespace, as per the guidelines in 587 [RFC3688]. 589 URI: urn:ietf:params:xml:ns:location-filter 591 Registrant Contact: IETF, GEOPRIV working group, , 592 as delegated by the IESG . 594 XML: 596 BEGIN 597 598 600 601 602 604 Location Filter Namespace 605 606 607

Namespace for PIDF-LO Location Filters

608

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

609

See RFCXXXX.

610 611 612 END 614 6.2. Schema Registration For location-filter 616 This specification registers a schema, as per the guidelines in 617 [RFC3688]. 619 URI: urn:ietf:params:xml:schema:location-filter 621 Registrant Contact: IETF, GEOPRIV Working Group 622 (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org). 624 XML: The XML can be found as the sole content of Section 4. 626 7. Contributors 628 We would like to thank Martin Thomson and James Polk for their 629 contributions to this document. 631 8. Acknowledgments 633 Thanks to Richard Barnes and Alissa Cooper, Carl Reed, Adam Roach, 634 Allan Thomson, James Winterbottom for their comments. 636 9. References 638 9.1. Normative References 640 [GML] OpenGIS, "Open Geography Markup Language (GML) 641 Implementation Specification", OpenGIS OGC 02-023r4, 642 January 2003, 643 . 645 [I-D.ietf-geopriv-arch] 646 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 647 Tschofenig, H., and H. Schulzrinne, "An Architecture for 648 Location and Location Privacy in Internet Applications", 649 draft-ietf-geopriv-arch-01 (work in progress), 650 October 2009. 652 [I-D.ietf-sipcore-event-rate-control] 653 Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 654 Protocol (SIP) Event Notification Extension for 655 Notification Rate Control", 656 draft-ietf-sipcore-event-rate-control-00 (work in 657 progress), May 2009. 659 [I-D.singh-geopriv-pidf-lo-dynamic] 660 Schulzrinne, H., Singh, V., Tschofenig, H., and M. 661 Thomson, "Dynamic Extensions to the Presence Information 662 Data Format Location Object (PIDF-LO)", 663 draft-singh-geopriv-pidf-lo-dynamic-07 (work in progress), 664 August 2009. 666 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", BCP 14, RFC 2119, March 1997. 669 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 670 Types", RFC 3023, January 2001. 672 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 673 Event Notification", RFC 3265, June 2002. 675 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 676 Initiation Protocol (SIP)", RFC 3856, August 2004. 678 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 679 Format", RFC 4119, December 2005. 681 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 682 Registration Procedures", BCP 13, RFC 4288, December 2005. 684 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 685 Requena, "An Extensible Markup Language (XML)-Based Format 686 for Event Notification Filtering", RFC 4661, 687 September 2006. 689 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 690 Presence Information Data Format Location Object (PIDF-LO) 691 Usage Clarification, Considerations, and Recommendations", 692 RFC 5491, March 2009. 694 9.2. Informational References 696 [I-D.ietf-geopriv-http-location-delivery] 697 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 698 "HTTP Enabled Location Delivery (HELD)", 699 draft-ietf-geopriv-http-location-delivery-16 (work in 700 progress), August 2009. 702 [I-D.ietf-geopriv-policy] 703 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 704 and J. Polk, "Geolocation Policy: A Document Format for 705 Expressing Privacy Preferences for Location Information", 706 draft-ietf-geopriv-policy-21 (work in progress), 707 July 2009. 709 [I-D.ietf-sipcore-location-conveyance] 710 Polk, J. and B. Rosen, "Location Conveyance for the 711 Session Initiation Protocol", 712 draft-ietf-sipcore-location-conveyance-01 (work in 713 progress), July 2009. 715 [I-D.winterbottom-geopriv-held-context] 716 Winterbottom, J., Tschofenig, H., and M. Thomson, 717 "Location URI Contexts in HTTP-Enabled Location Delivery 718 (HELD)", draft-winterbottom-geopriv-held-context-05 (work 719 in progress), October 2009. 721 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 722 January 2004. 724 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 725 Polk, J., and J. Rosenberg, "Common Policy: A Document 726 Format for Expressing Privacy Preferences", RFC 4745, 727 February 2007. 729 Authors' Addresses 731 Rohan Mahy 732 Individual 734 Email: rohan@ekabal.com 736 Brian Rosen 737 NeuStar 738 470 Conrad Dr. 739 Mars, PA 16046 740 US 742 Phone: +1 724 382 1051 743 Email: br@brianrosen.net 745 Hannes Tschofenig 746 Nokia Siemens Networks 747 Linnoitustie 6 748 Espoo 02600 749 Finland 751 Phone: +358 (50) 4871445 752 Email: Hannes.Tschofenig@gmx.net 753 URI: http://www.tschofenig.priv.at