idnits 2.17.1 draft-ietf-geopriv-loc-filters-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (October 26, 2009) is 5293 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 634, but no explicit reference was found in the text == Unused Reference: 'RFC3023' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC4288' is defined on line 674, 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-00 == 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 (~~), 9 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: April 29, 2010 NeuStar 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 26, 2009 10 Filtering Location Notifications in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-geopriv-loc-filters-07.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document describes filters that limit asynchronous location 51 notifications to compelling events, designed as an extension to RFC 52 4661, an XML-based format for event notification filtering, and based 53 on RFC 3856, the SIP presence event package. The resulting location 54 information is conveyed in existing location formats wrapped in the 55 Presence Information Data Format Location Object (PIDF-LO). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 6 65 3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 7 66 3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 9 67 3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 11 68 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 6.1. URN Sub-Namespace Registration for 72 urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16 73 6.2. Schema Registration For location-filter . . . . . . . . . 16 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 9.2. Informational References . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 Conveying location information encapsulated with a PIDF-LO [RFC4119] 84 document within SIP is described in 85 [I-D.ietf-sipcore-location-conveyance]. An alternative signaling 86 approach, which uses asynchronous communication, is available with 87 the SIP event notification mechanisms (see RFC 3265 [RFC3265]) and is 88 used by this document. Unfortunately, it is more complex since many 89 forms of location are measured as a continuous gradient. Unlike 90 notifications using discret quantities, it is difficult to know when 91 a change in location is large enough to warrant a notification. SIP 92 events [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) 93 that allows the number of notifications to be reduced. The mechanism 94 described in this document defines an extension to RFC 4661 95 [RFC4661], which limits location notification to events that are of 96 relevance to the subscriber. These filters persist until they are 97 changed with a replacement filter. 99 The frequency of notifications necessary for various geographic 100 location applications varies dramatically. The subscriber should be 101 able to get asynchronous notifications with appropriate frequency and 102 granularity, without having to issue a large number of notifications 103 that are not important to the application. 105 This document defines a few new event filters and describes others 106 using existing mechanisms that may be relevant to a subscriber in the 107 context of location filtering: 109 1. the Device moves more than a specified distance since the last 110 notification 112 2. the Device exceeds a specified speed 114 3. the Device enters or exits a region (described by a circle or a 115 polygon) 117 4. one or more of the values of the specified address labels have 118 changed for the location of the Device. For example, the value 119 of the civic address element has changed from 'California' 120 to 'Nevada'. 122 5. the type of location information being requested. 124 6. the rate at which location information delivery is desired. 126 This document builds on the presence event package [RFC3856], i.e. an 127 existing event package for communicating location information inside 128 the PIDF-LO. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 This document reuses terminology from [I-D.ietf-geopriv-arch]. 138 3. Filter Definitions 140 This specification builds on top of a number of other specifications, 141 as noted in Section 1. In order to reduce the number of options (and 142 thereby increase the chance of interoperability problems), only the 143 functionality described in this document MUST be implemented. Only 144 the functionality of [RFC4661] listed in the sub-sections below MUST 145 be implemented, namely the (see Section 3.3 of 146 [RFC4661]), the (Section 3.4 of [RFC4661]), and the 147 (Section 3.6 of [RFC4661] excluding the functionality of 148 the and element). 150 3.1. Movement 152 The element with a value in meters indicates the minimum 153 distance that the resource must have moved from the location of the 154 resource when the last notification was sent in order to trigger this 155 event. The distance is measured in meters absolutely from the point 156 of last notification rather than in terms of cumulative motion. The 157 element MUST only appear once as a child element of . 159 160 163 164 300 165 166 168 Figure 1: Movement Filter Example 170 3.2. Speed Changes 172 Speed changes can be filtered with the help of RFC 4661 and the 173 functionality provided in [I-D.singh-geopriv-pidf-lo-dynamic], which 174 extends the PIDF-LO with support for spatial orientation, speed, 175 heading, and acceleration. The value of in 176 [I-D.singh-geopriv-pidf-lo-dynamic] is defined in meters per second. 177 This is the only supported measure and hence the value in the 'by' 178 attribute MUST be expressed in meters per second. 180 Figure 2 shows an example for a trigger that fires when the speed of 181 the Target changes by 3 meters per second. 183 184 185 186 188 189 190 191 192 //dyn:speed 193 194 195 196 198 Figure 2: Speed Change Example 200 An implementation MUST support the functionality as shown in Figure 2 201 with replacing the prefix. No other variant is 202 supported. The element comes with a few attributes but 203 only the 'by' attribute MUST be implemented by this specification. 205 3.3. Element Value Changes 207 Changes in values, for example related to civic location information, 208 is provided by the base functionality offered with RFC 4661 utilizing 209 the element. 211 Figure 3 shows an example where a notification is sent when the civic 212 address tokens A1, A2, A3, or PC change (all 4 must change in order 213 to let the element evaluate to TRUE). 215 216 217 218 220 221 222 223 //ca:A1 224 //ca:A2 225 //ca:A3 226 //ca:PC 227 228 229 231 Figure 3: Speed Change Example 233 The following example illustrates a filter that triggers when the 234 Target's location changes from 'FR' (France) to some other country. 236 237 238 239 241 242 243 244 //ca:country 245 246 247 249 Figure 4: Speed Change Example (Country Change) 251 An implementation MUST support the functionality as shown in Figure 3 252 with replacing the prefix. No other variant is 253 supported. The element comes with a few attributes and the 254 'by', 'to' and 'from' attribute MUST be implemented by this 255 specification. 257 3.4. Entering or Exiting a Region 259 The condition is satisfied when the Target enters or 260 exits a named 2-dimensional region described by a polygon (as defined 261 in Section 5.2.2 of [RFC5491]), or a circle (as defined in Section 262 5.2.3 of [RFC5491]). The element MUST have contain 263 either a polygon or a circle as a child element. More than one a 264 polygon and/or a circle as a child element of MUST NOT 265 occur. 267 If the Target was previously outside the region, the notifier sends a 268 notification when the Target's location is within the region with at 269 least 50% confidence. Similarly, when a Target starts within the 270 region, a notification is sent when the Target's location moves 271 outside the region with at least 50% confidence. 273 Note that having 50% confidence that the Target is inside the area 274 does not correspond to 50% outside. Confidence that the location is 275 within the region, plus confidence that the location is outside the 276 region cannot be 100%. The total confidence depends on the 277 confidence in the original location, which is always less than 100% 278 (95% is recommended in [RFC5491]). The benefit of this is that 279 notifications are naturally limited: small movements at the borders 280 of the region do not trigger notifications. 282 Figure 5 shows filter examples whereby a notification is sent when 283 the Target enters or exits an area described by a circle and Figure 6 284 describes an area using a polygon. 286 287 293 294 295 296 42.5463 -73.2512 297 298 850.24 299 300 301 302 303 305 Figure 5: Circle Filter Example 307 308 312 313 314 315 316 317 318 43.311 -73.422 43.111 -73.322 319 43.111 -73.222 43.311 -73.122 320 43.411 -73.222 43.411 -73.322 321 43.311 -73.422 322 323 324 325 326 327 328 330 Figure 6: Polygon Filter Example 332 3.5. Location Type 334 The element MAY be included as a child element of the 335 element and it contains a list of location information types 336 that are requested by the subscriber. The following list describes 337 the possible values: 339 any: The Notifier SHOULD attempt to provide LI in all forms 340 available to it. 342 geodetic: The Notifier SHOULD return a location by value in the form 343 of a geodetic location. 345 civic: The Notifier SHOULD return a location by value in the form of 346 a civic address. 348 The Notifier SHOULD return the requested location type or types. The 349 location types the LIS returns also depend on the setting of the 350 optional "exact" attribute. If the 'exact' attribute is set to 351 "true" then the Notifier MUST return either the requested location 352 type or no location information. The 'exact' attribute does not 353 apply (is ignored) for a request for a location type of "any". 355 In the case of a request for specific locationType(s) and the 'exact' 356 attribute is false, the Notifier MAY provide additional location 357 types, or it MAY provide alternative types if the request cannot be 358 satisfied for a requested location type. The "SHOULD"-strength 359 requirements on this parameter for specific location types are 360 included to allow for soft-failover. 362 If the element is absent, a value of "any" MUST be 363 assumed as the default. 365 The Notifier SHOULD provide location in the response in the same 366 order in which they were included in the "locationType" element in 367 the request. Indeed, the primary advantage of including specific 368 location types in a request when the 'exact' attribute is set to 369 "false" is to ensure that one receives the available locations in a 370 specific order. For example, a subscription for "civic" (with the 371 'exact' attribute set to "false") could yield any of the following 372 location types in the response: 374 o civic 376 o civic, geodetic 378 o geodetic (only if civic is not available) 380 For the example above, if the 'exact' attribute was "true", then the 381 only possible response is either a "civic" location or an error 382 message. 384 As stated above, the element MAY carry the 'exact' 385 attribute. When the 'exact' attribute is set to "true", it indicates 386 to the Notifier that the contents of the element MUST 387 be strictly followed. The default value of "false" 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. A value of "true" indicates that the Notifier MUST 391 provide a location of the requested type or types or MUST provide an 392 error. 394 An example is shown in Figure 7 that utilizes the 395 element with the 'exact' and the 'responseTime' attribute. 397 398 401 402 403 geodetic 404 405 406 408 Figure 7: Filter Example 410 3.6. Rate Control 412 [I-D.ietf-sipcore-event-rate-control] defines an extension to the SIP 413 events framework defining the following three "Event" header field 414 parameters that allow a subscriber to set a minimum, a maximum and an 415 average rate of event notifications generated by the notifier. This 416 document makes use of two of the parameters to accomplish 417 functionality equivalent to the 'responseTime' attribute used in HELD 418 [I-D.ietf-geopriv-http-location-delivery], namely "min-interval" 419 (which specifies a minimum notification time period between two 420 notifications, in seconds) and "max-interval" (which specifies a 421 maximum notification time period between two notifications, in 422 seconds.). This specification only defines the semantic for these 423 two attributes and requires implementation of these two from the set 424 of attributes defined in [I-D.ietf-sipcore-event-rate-control]. 425 Whenever the time since the most recent notification exceeds the 426 value in the "max-interval" parameter, then the current state would 427 be sent in its entirety, just like after a subscription refresh. 429 If complete state is not immediately available, a NOTIFY containing 430 state (i.e. location) is generated some time between the time 431 included in 'min-interval' and the time in 'max-interval'. An 432 important use case for location based applications focuses on the 433 behavior of the initial NOTIFY message(s) and the information it 434 returns, for example in case of emergency call routing. When an 435 initial NOTIFY is transmitted it might not include complete state. 437 Subscriber Notifier 438 |---SUBSCRIBE(1)--->| Request state subscription 439 |<-------200--------| Acknowledge subscription 440 |<-----NOTIFY(2)----| Return current state information 441 |-------200(3)----->| 442 |<-----NOTIFY(4)----| Return current state information 443 |--------200------->| 445 Figure 8: SUBSCRIBE/NOTIFY with Rate Control 447 Figure 8 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE 448 message (1) has filters attached and contains a 'max-interval' rate 449 control parameter. In certain situations it is important to obtain 450 some amount of location information within a relatively short and 451 pre-defined period of time even if the obtained location information 452 contains a high amount of uncertainty and location information with 453 less uncertainty at a later point in time. An example is emergency 454 call routing where a emergency services routing proxy may need to 455 obtain location information suitable for routing rather quickly and 456 subsequently a Public Safety Answering Point requests location 457 information for dispatch. 459 To obtain location information in a timely fashion using the 460 SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial 461 SUBSCRIBE contains a 'max-interval' rate control parameter (with a 462 small value) that is in a later message updated to a more sensible 463 value. The 'max-interval' for this first request is therefore much 464 lower than thereafter. Updating the 'max-interval' for the 465 subscription can be performed in the 200 response (see message 3) to 466 the NOTIFY that contains state. Depending on the value in the 'max- 467 interval' parameter the Notifier may create a NOTIFY message (see 468 message 2) immediately in response to the SUBSCRIBE that might be 469 empty in case no location information is available at this point in 470 time. The desired location information may then arrive in the 471 subsequent NOTIFY message (see message 4). 473 4. XML Schema 475 476 482 486 488 490 491 492 493 494 495 496 498 500 501 502 503 504 505 506 507 508 509 510 511 512 513 515 516 517 518 519 520 521 522 523 524 526 527 528 529 531 532 533 534 536 Figure 9: XML Schema 538 5. Security Considerations 540 This document builds on a number of specifications, namely 542 o the SIP event notification mechanism, described in RFC 3265 543 [RFC3265], defining the SUBSCRIBE/NOTIFY messages. 545 o the presence event package, described in RFC 3856 [RFC3856], which 546 is a concrete instantiation of the general event notification 547 framework. 549 o the filter framework, described in RFC 4661 [RFC4661], to offer 550 the ability to reduce the amount of notifications being sent. 552 Finally, this document indirectly (via the SIP presence event 553 package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the 554 XML container that carries location information. 556 Each of these documents listed above comes with a security 557 consideration section but the security and privacy aspects are best 558 covered by the SIP presence event package, see Section 9 of 559 [RFC3856], and with the GEOPRIV architectural description found in 560 [I-D.ietf-geopriv-arch]. The functionality for uploading 561 authorization policies and other information that limit access to 562 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]. The functionality described 566 in this document extends the filter framework with location specific 567 filters. Local policies might be associated with the usage of 568 certain filter constructs and with the amount of notifications 569 specific filter settings might cause. 571 Although [I-D.ietf-geopriv-policy] defines a standardized format for 572 authorization policies but it does not define specific policies for 573 controlling filters specifically. 575 6. IANA Considerations 577 6.1. URN Sub-Namespace Registration for 578 urn:ietf:params:xml:ns:location-filter 580 This section registers a new XML namespace, as per the guidelines in 581 [RFC3688]. 583 URI: urn:ietf:params:xml:ns:location-filter 585 Registrant Contact: IETF, GEOPRIV working group, , 586 as delegated by the IESG . 588 XML: 590 BEGIN 591 592 594 595 596 598 Location Filter Namespace 599 600 601

Namespace for PIDF-LO Location Filters

602

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

603

See RFCXXXX.

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