idnits 2.17.00 (12 Aug 2021) /tmp/idnits3107/draft-winterbottom-geopriv-held-context-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 921. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2007) is 5341 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) ** Downref: Normative reference to an Informational RFC: RFC 3693 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') == Outdated reference: draft-ietf-geopriv-lbyr-requirements has been published as RFC 5808 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-lbyr-requirements (ref. 'I-D.ietf-geopriv-lbyr-requirements') Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Geopriv J. Winterbottom 3 Internet-Draft Andrew Corporation 4 Intended status: Standards Track H. Tschofenig 5 Expires: April 8, 2008 Nokia Siemens Networks 6 M. Thomson 7 Andrew Corporation 8 October 6, 2007 10 HELD Protocol Context Management Extensions 11 draft-winterbottom-geopriv-held-context-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 8, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes a protocol extension for the HTTP Enabled 45 Location Delivery (HELD) protocol. It allows a Target to manage 46 their location information on a Location Information Server (LIS) 47 through the application of constraints invoked by accessing a 48 location URI. Constraints described in this memo restrict how often 49 location can be accessed through a location URI, how long the URI is 50 valid for, and the type of location information returned when a 51 location URI is accessed. Extension points are also provided. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Location Type URIs . . . . . . . . . . . . . . . . . . . . 7 62 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8 64 5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9 65 5.3. Context Response Message . . . . . . . . . . . . . . . . . 10 66 5.4. Context Error Messages . . . . . . . . . . . . . . . . . . 12 67 5.5. Location URI and Context Identifier Generation Rules . . . 12 68 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 8.1. URN Sub-Namespace Registration for 72 urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 19 73 8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 19 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 75 Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22 76 Appendix B. HELD Compliance to IETF Location Configuration 77 Protocol Location Reference Requirements . . . . . . 24 78 10. Normative References . . . . . . . . . . . . . . . . . . . . . 26 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 80 Intellectual Property and Copyright Statements . . . . . . . . . . 28 82 1. Introduction 84 The HTTP Enabled Location Delivery (HELD) protocol specification 85 [I-D.ietf-geopriv-http-location-delivery] provides a set of features 86 that can be used by a Target to retrieve location information from a 87 Location Information Server (LIS). The basic HELD specification does 88 this in a more or less stateless manner, and when a location URI is 89 retrieved the Target has no way of controlling how the URI is used; a 90 Location Recipient in pocession of the location URI can get the 91 Target's location until the URI expires. This basic mechanism may be 92 reasonable in a limited set of applications, but is unacceptable in a 93 broader range of applications. This position is highlighted in 94 [I-D.ietf-geopriv-lbyr-requirements] which describes requirements for 95 constraints relating to location URIs. This specification provides 96 support for these requirements in HELD. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 This document reuses the terms Target, as defined in [RFC3693]. 106 This document uses the term Location Information Server (LIS) as the 107 node in the access network that provides location information about a 108 Target. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps]. 110 3. What is a Context? 112 A Location URI points to a LIS that is able to provide the location 113 of a specific Target. The LIS is able to map the URI to the location 114 of the Target inside its administrative domain. We call this mapping 115 a "context". In the basic HELD specification the context is 116 implicitly created with the request for a location URI in the 117 locationRequest message. The Target has no control of the mapping 118 from the URI to the Target's location. This specification provides a 119 degree of control to the Target, allowing it to specify rules to the 120 LIS on how a context should map a URI to location information. 122 A context expires when it reaches a certain age, at which time the 123 mapping between the URI and the Target's location ceases. In the 124 basic HELD specification the exiry time of the context is determined 125 by the LIS when the Target requests a location URI. By allowing the 126 Target to specify and change the life time of a context the Target is 127 able to create URIs for limited periods, or to terminate URIs for 128 which it longer wishes its location to be returned. This 129 specification provides explicit support for this functionality. 131 4. Constraints 133 Constraints restrict the ability of a Location Recipient to resolve a 134 location URI to location information. The constraints are selected 135 by the Target and they are provided to the LIS that maintains them 136 along with the context. A LIS, understanding this specification, 137 receives constraints provided by the Target, and returns a set of 138 URIs influenced by the constraints. 140 A single Target may want to place different contraints on different 141 references and hence may have multiple contexts on the LIS. The 142 constraints describe what actions the LIS MUST take when a URI 143 associated with the context is accessed. This document describes 144 three basic constraints that a Target can use in comination for the 145 same context. Once set, these rules remain in force of the life of 146 the context. 148 4.1. Limited Use URIs 150 A limited use URI can only be accessed a fixed number of times to 151 yield the location of the Target. Each time the URI is used to 152 provide the location of the Target one usage is consumed. Once the 153 limit is reached the URI no longer yields the location of the Target 154 and the URI is deemed spent. 156 By setting the usage limit to 1, the Target is able to create a one- 157 time-URI permitting a Location Recipient to obtain the Target's 158 location only once. Setting the usage limit to something higher than 159 1 creates functionality analogous to a metro-ticket, where a Location 160 Recipient in possession of the URI can access the Target's location 161 many more times, but not exceeding the imposed limit. 163 Not setting a usage limit provides similar semantics to the URI in 164 the base HELD specification, enabling a Location Recipient to 165 continually obtain the Target's location until the URI expires due to 166 age. 168 When an HTTP URI is assigned to a context, the limit is the number of 169 times that the URI can be accessed before the LIS returns an error. 170 In the case of SIP it is the number of NOTIFY messages that are sent 171 prior to the LIS returning an error. Where a context supports both 172 SIP and HTTP URIs it is the combination of URI accesses and NOTIFY 173 messages that constitutes the usage value, each time the Target's 174 location is provided constitutes a usage. 176 4.2. Snapshot URIs 178 A snapshot URI points to the location of the Target at a specific 179 point in time, and no matter how many times the URI is accessed it 180 will always yield the same location. This is useful if, for example, 181 the Target does not want to be tracked. In this specification the 182 location snapshot to which a snapshot URIs points is captured when 183 the context is created on the LIS. 185 4.3. Location Type URIs 187 A location type URI controls the form of location that can be 188 accessed; This may be geodetic, civic, or both. 190 5. Protocol Details 192 This specification introduces four new HELD messages, create context 193 (), update context (), context response 194 (), and context error (). A LIS that 195 does not understand this specification is expected to return a HELD 196 _unsupportedMessage_ error code in a HELD error message. 198 The specification assumes that the LIS was discovered as part of the 199 general HELD LIS discovery process. All messages are sent using the 200 application/held+xml MIME type as defined in 201 [I-D.ietf-geopriv-http-location-delivery]. 203 5.1. Create Context Message 205 The Target creates a context on the LIS using a create context 206 message. The basic create context message supports the constraints 207 described in Section 4 and consist of three attributes and one 208 element described below: 210 o "uses": an optional attribute instructing the LIS on how many 211 times a URI may yield the location of the Target. This is a 212 positive integer, and has a default value of _unlimited_. The LIS 213 SHOULD support the Target specifying up to at least 100 uses. 215 o "snapshot": an optional attribute instructing the LIS to take a 216 snapshot of the Target's location for use with the context. This 217 a boolean value and has a default of _false_ meaning that a 218 snapshot is not taken, and the Target's location is determined 219 each time the URI is accessed. 221 o "locationType": an optional attribute instructing the LIS on the 222 form of location that URI MUST provide. This is an enumeration 223 and may have a value of _geodetic_, _civic_, or _any_. If 224 unspecified by the Target the LIS will use a value of _any_. If 225 the Target specifies a location type that the LIS cannot provide, 226 then the LIS MUST fail the context creation. 228 o "lifeTime": is a mandatory element that defines the maximum period 229 in seconds that the LIS should keep the context for. The LIS MAY 230 create the context with a shorter life time than was requested, 231 but the life time MUST NOT be longer than was requested. 233 238 7200 239 241 Figure 1: createContext Example 243 Figure 1 shows a create context message defining a context which: 245 o may be accessed 10 times 247 o will determine the location of the Target each time it is accessed 249 o will return the location in either geodetic or civic form 250 depending on the request tot he URI 252 o will be valid for 2 hours from the time of context creation 254 5.2. Update Context Message 256 A Target can change the life time of a context using an update 257 context message. As stated in Section 4 the three attributes used in 258 the context creation, "uses", "snapshot", and "locationType" cannot 259 be changed once a context is created. 261 Since the Target may have more than one context on the LIS, the 262 Target needs to identify the context to be updated. It does this by 263 including a context identifier that is provided to it by the LIS when 264 the context is created. 266 269 3600 270 272 Figure 2: updateContext Life Time Change Example 274 When a Target includes a life time element in an update context 275 message, the LIS needs to calculate a new context expiry time. The 276 LIS MUST do this by adding the new life time value to the current 277 time on the LIS. This mechanism means the Target can terminate a 278 context at any time. It does this by updating the context with a 279 life time of 0, which results in the LIS setting the context expiry 280 time to the present. The LIS MAY also terminate a context if the 281 life time value is set to less than 10 seconds. 283 286 0 287 289 Figure 3: updateContext Termination Example 291 5.3. Context Response Message 293 The LIS informs the Target about the outcome of context operations 294 through the context response message. The LIS MUST always send a 295 context response message to a Target in response to a create context 296 or update context message when the outcome was successful. The 297 context response message contains a "code" attribute indicating the 298 performed operation, and the other attributes and elements indicating 299 the state of the context. 301 The "code" attribute is an enumerated type and has one of the 302 following values: 304 o _created_: The context was successfully created. 306 o _destroyed_: The context was destroyed. 308 o _updated_: The context was successfully updated. 310 The following list details the other attributes are may be returned 311 in a context response message. 313 id: The identifier allocated to the context by the LIS. This 314 identifier is unique in the scope of the LIS. The Target MUST 315 keep this secret and MUST included it in all update requests. The 316 LIS MUST return and "id" in all context response messages. 318 uses: The number of times that the context will yield the Target's 319 location. The LIS MAY report either the original value, or the 320 number of remaining uses. The LIS MUST report this value for all 321 responses pertaining to a known and valid context. This value MAY 322 be ommitted when indicating that a context has been destroyed. 324 snapshot: The value of the snapshot attribute in the context. The 325 LIS MUST report this value for all responses pertaining to a known 326 and valid context. This value MAY be ommitted when indicating 327 that a context has been destroyed. 329 locationType: The type of location information that can be acquired 330 through URIs addressing the context. The LIS MUST report this 331 value for all responses pertaining to a known and valid context. 332 This value MAY be omitted when indicating that a context has been 333 destroyed. 335 expiry: The time at which the context will expire. After this time, 336 all location URIs that reference this context no longer work. The 337 LIS MUST report this value for all responses pertaining to a known 338 context. This attribute MUST be provided even when a "code" value 339 of _destroyed_ is included in the context repsonse message. 341 In addition to the above attributes, the LIS also provides a set of 342 URIs that can used to access the Target's location with the surety 343 that the context constraints will be applied. A URI set is returned 344 whenever a context is successfully created on the LIS, and this set 345 remains unchanged for the lifetime of the context. A context 346 response message sent in reply to the create context message in 347 Figure 1 might look like Figure 4. 349 357 358 359 https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4 360 361 362 sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769 363 364 365 367 Figure 4: contextResponse Example 369 5.4. Context Error Messages 371 When the LIS unable to perform the requested context operation it 372 need to inform the Target of this. It does this using a context 373 error message. The context error message consists of a "errorCode" 374 and an optional "message" attribute. The code indicates what went 375 wrong, the message is human-readable text that may provide additional 376 information on what occurred. 378 The "errorCode" attribute is an enumerated type and has one of the 379 following values: 381 o _badMessage_: The LIS was unable to understand the content of the 382 message. 384 o _unknownContext_: The LIS was unable to find the context. 386 o _failed_: The LIS was unable to perform the requested operation. 388 A Target implementing this specification MUST accept a HELD error 389 message as a valid response to a create context or update context 390 message. 392 396 398 Figure 5: contextError With Message Example 400 5.5. Location URI and Context Identifier Generation Rules 402 A primary aim of this specification is to provide a Target a means to 403 cancel a location URI so that it can no longer be used to provide its 404 location. To achieve this, a location URI generated as part of a 405 context creation needs to be unique with in the scope of the LIS, and 406 identify only that context. If the Target destroys a context and 407 subsequently creates a new one, URIs associated the new context MUST 408 be different from those generated for the previous context. 409 [I-D.ietf-geopriv-http-location-delivery] and 410 [I-D.ietf-geopriv-lbyr-requirements] provide guideance on the 411 creation and desired characteristcs of a location URI. 413 The context identifier provided by the LIS to the Target in the 414 context response message MUST be unique and MUST be different from 415 the identifier provided in any location URI. This latter constraint 416 ensures that possession of a location URI does not automatically 417 provide access and control over the internals of the context. 419 A context identifier is generated by a LIS to uniquely identify a 420 context. It MUST NOT be feasible for a third-party to easily 421 determine a context identifier by knowing the identity of the Target. 422 This implies that internal correlation (using a hash-table or 423 similar) is the only method that the LIS can use to associate a 424 context id with a particular Target. 426 6. XML Schema 428 429 436 437 438 439 440 441 442 444 445 446 447 448 449 450 452 453 454 455 456 457 458 460 461 462 463 464 465 466 467 468 469 471 472 473 474 475 477 479 480 482 484 486 487 488 489 491 492 493 494 496 497 498 500 501 502 503 504 506 508 509 511 513 515 517 519 522 523 524 525 527 528 529 530 531 533 535 536 538 539 540 541 543 544 545 546 547 549 551 552 553 554 556 557 558 559 561 563 Figure 6: Context Management Schema 565 7. Security Considerations 567 There are several security concerns associated with the details in 568 this specification. The first is to do with the nature of the 569 sensitivity of any data passed from the Target to the LIS for 570 inclusion in a context. The second is the ability of the LIS to 571 contain the number of contexts that it will permit to exist for a 572 given Target address. Finally, there is a threat of Targets 573 performing DoS attacks on the LIS by trying to create large numbers 574 of short-lived contexts that result in the LIS expending resources in 575 message processing. 577 HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of 578 TLS for exchanges between a Target and the LIS. This is deemed 579 adequate to provide confidentiality to any contextual data in 580 transit. The LIS implementation and the operator of the LIS need to 581 take sufficient steps to ensure that active contextual data on the 582 LIS is not readily available to anyone other than the Target. The 583 Target MUST NOT provide any information to the LIS that it does not 584 want the LIS to know or be able to use in some capacity associated 585 with determination or providing of the Target's location. 587 It is quite conceivable that a LIS will be required to provide 588 location to Targets residing behind a NAT; a DSL home router with 5 589 PCs attached is a good example this situation. In this case it is 590 reasonable for each device to create its own context on the LIS, and 591 for the LIS to treat each context individually even though the LIS 592 cannot make any other distinction between the end hosts; that is, 593 they share a common IP address/identity from the LIS perspective. 595 Given the constraints that can be added to a context and the way that 596 a Target might want to manage expiry separately, a Target may use 597 multiple contexts as a way to isolate applications from each other. 598 For instance, a Target can create a context for each application so 599 that it can revoke access to its location information for each 600 without affecting other applications' access. This environment, 601 however, opens the LIS to a type of denial of service attack through 602 an overload of contexts. It is RECOMMENDED that an implementer of 603 this specification include mechanisms to restrict to the maximum 604 number of contexts that can be created on the LIS by an individual 605 Target. 607 Using short-term location URIs in a carefully controlled manner may 608 obviate the need for individual location authorization policies on 609 the LIS. This leads to reduced LIS complexity and the amount of 610 private information that the Target need share with the LIS. This 611 specification provides the ability for a Target to cancel a location 612 URI which extends the Target's ability to enforce its entitlement to 613 privacy. Using the mechanisms described in this memo a target can 614 create URIs with short validity periods; this restricts how long a 615 third-party is able to obtain the location of the Target while still 616 allowing the Target the convenience of using a location reference. 618 The generation of context identifiers by the LIS is a critical 619 component to supporting the functionality described in this memo. 620 The LIS MUST follow the rules described in Section 5.5 for generating 621 context identifiers. 623 8. IANA Considerations 625 This document registers the schema and associated namespace with 626 IANA. 628 8.1. URN Sub-Namespace Registration for 629 urn:ietf:params:xml:ns:geopriv:held:context 631 This section registers a new XML namespace, 632 "urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines 633 in [RFC3688]. 635 URI: urn:ietf:params:xml:ns:geopriv:held:context 637 Registrant Contact: IETF, GEOPRIV working group, 638 (geopriv@ietf.org), James Winterbottom 639 (james.winterbottom@andrew.com). 641 XML: 643 BEGIN 644 645 647 648 649 HELD Context Management Messages 650 651 652

Namespace for HELD Context Management Messages

653

urn:ietf:params:xml:ns:geopriv:held:context

654 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 655 with the RFC number for this specification.]] 656

See RFCXXXX.

657 658 659 END 661 8.2. XML Schema Registration 663 This section registers an XML schema as per the guidelines in 664 [RFC3688]. 666 URI: urn:ietf:params:xml:schema:geopriv:held:context 667 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 668 James Winterbottom (james.winterbottom@andrew.com). 670 Schema: The XML for this schema can be found as the entirety of 671 Figure 6 of this document. 673 9. Acknowledgements 675 Thanks to Adam Muhlbauer and Neil Justusson for their comments on the 676 pre-version of this draft. 678 Appendix A. Context Extensions 680 A context contains specific information about a Target and is stored 681 on the LIS. As with other protocols it is necessary to consider 682 extensibility. When defining context data extensions it is necessary 683 to consider how they will be used; this includes not only how to 684 provide the information from the Target to the LIS, but also 685 acceptance and error indications from the LIS back to the Target. 686 For example, a context may be created with several extensions 687 included, how does the LIS indicate that extensions 1 and 3 were 688 successful but that extension 2 had a problem in its formatting? 689 Guidelines for designing context extensions that provide 690 functionality are described below. 692 Two basic types of context data extension are envisioned. The first 693 consist of data provided by the Target to be consumed by the LIS; for 694 example information pertaining to PIDF-LO construction, usage-rules, 695 and authorization policies. The second type of data consists of a 696 two way exchange between the Target and the LIS; for example 697 exchanging location determination capabilities. Extensibility to the 698 context scheme is to allow additional elements to be added to the 699 context easily. The general idea is shown in Figure 8. 701 703 7200 704 706 7200 707 708 709 710 . 711 . 712 . 713 714 716 Figure 8: Create Context with Extensions 718 When defining a context data extension it is necessary to ensure that 719 the LIS can provide an adequate response to the Target indicating 720 acceptance or rejection of the data provided. This may be an 721 explicit OK or FAIL message within the extension namespace, it may be 722 an attribute associated with part of a larger data exchange, or it 723 may result in the LIS failing to create the context at all. 724 Regardless, it is mandatory for a context data extension to provide 725 an indication of success or failure. 727 735 736 737 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 738 739 740 sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769 741 742 743 745 748 750 data 751 guff in here for extension 752 753 755 Figure 9: LIS response to createContext 757 When defining information to be included in a context data extension 758 consideration should be given to how that data can be removed from 759 the context. In some cases it may be necessary to void the context 760 on the LIS in order to remove information, but this SHOULD be treated 761 as a last resort and not used as the primary mechanism for removing 762 data from the context. 764 Appendix B. HELD Compliance to IETF Location Configuration Protocol 765 Location Reference Requirements 767 This section describes how HELD and this specification comply to the 768 LCP location reference requirements stipulated in 769 [I-D.ietf-geopriv-lbyr-requirements]. 771 High-level requirements for a location configuration protocol. 773 C1. "Location URI support - LCP: The configuration protocol MUST 774 support a location reference in URI form." 776 COMPLY. HELD only provides location references in URI form. 778 C2. "Location URI expiration: The LCP MUST support the ability to 779 specify to the server, the length of time that a location URI 780 will be valid." 782 COMPLY. HELD with the context management extensions described 783 in this document provide the Target the ability to specify 784 expiry times for location URIs. 786 C3. "Location URI cancellation: The LCP MUST support the ability to 787 request a cancellation of a specific location URI." 789 COMPLY. HELD with the context management extensions described 790 in this document provide the Target the ability to void location 791 URIs when required. 793 C4. "Random Generated: The location URI MUST be hard to guess, i.e., 794 it MUST contain a cryptographically random component." 796 COMPLY. The HELD specification and this document provide 797 specific guidance on the security surrounding location URI 798 generation. 800 C5. "Identity Protection - LCP: The location URI MUST NOT contain 801 any information that identifies the user, device or address of 802 record within the URI form." 803 COMPLY. The HELD specification and this document provide 804 specific guidance on the anonymity of the Target with regards to 805 the generation of location URIs. 807 C6. "Reuse flag default: The LCP MUST support the default condition 808 of a requested location URI being repeatedly reused." 810 COMPLY. HELD with the context management extensions described 811 in this document provide the Target the ability to specify how 812 many times a location URI may yield the location of Target. 814 C7. "One-time-use: The LCP MUST support the ability for the client 815 to request a 'one-time-use' location URI (e.g., via a reuse flag 816 setting)." 818 COMPLY. HELD with the context management extensions described 819 in this document provide the Target the ability to specify how 820 many times a location URI may yield the location of Target. 821 This value may be set to 1 to create a one-time URI. 823 10. Normative References 825 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 826 Requirement Levels", BCP 14, RFC 2119, March 1997. 828 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 829 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 831 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 832 January 2004. 834 [I-D.ietf-geopriv-http-location-delivery] 835 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 836 "HTTP Enabled Location Delivery (HELD)", 837 draft-ietf-geopriv-http-location-delivery-02 (work in 838 progress), September 2007. 840 [I-D.ietf-geopriv-l7-lcp-ps] 841 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 842 Location Configuration Protocol; Problem Statement and 843 Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in 844 progress), September 2007. 846 [I-D.ietf-geopriv-lbyr-requirements] 847 Marshall, R., "Requirements for a Location-by-Reference 848 Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work 849 in progress), September 2007. 851 Authors' Addresses 853 James Winterbottom 854 Andrew Corporation 855 PO Box U40 856 University of Wollongong, NSW 2500 857 AU 859 Phone: +61 242 212938 860 Email: james.winterbottom@andrew.com 861 URI: http://www.andrew.com/products/geometrix 863 Hannes Tschofenig 864 Nokia Siemens Networks 865 Otto-Hahn-Ring 6 866 Munich, Bavaria 81739 867 Germany 869 Phone: +49 89 636 40390 870 Email: Hannes.Tschofenig@nsn.com 871 URI: http://www.tschofenig.com 873 Martin Thomson 874 Andrew Corporation 875 PO Box U40 876 University of Wollongong, NSW 2500 877 AU 879 Phone: +61 242 212915 880 Email: martin.thomson@andrew.com 881 URI: http://www.andrew.com/products/geometrix 883 Full Copyright Statement 885 Copyright (C) The IETF Trust (2007). 887 This document is subject to the rights, licenses and restrictions 888 contained in BCP 78, and except as set forth therein, the authors 889 retain all their rights. 891 This document and the information contained herein are provided on an 892 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 893 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 894 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 895 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 896 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 897 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 899 Intellectual Property 901 The IETF takes no position regarding the validity or scope of any 902 Intellectual Property Rights or other rights that might be claimed to 903 pertain to the implementation or use of the technology described in 904 this document or the extent to which any license under such rights 905 might or might not be available; nor does it represent that it has 906 made any independent effort to identify any such rights. Information 907 on the procedures with respect to rights in RFC documents can be 908 found in BCP 78 and BCP 79. 910 Copies of IPR disclosures made to the IETF Secretariat and any 911 assurances of licenses to be made available, or the result of an 912 attempt made to obtain a general license or permission for the use of 913 such proprietary rights by implementers or users of this 914 specification can be obtained from the IETF on-line IPR repository at 915 http://www.ietf.org/ipr. 917 The IETF invites any interested party to bring to its attention any 918 copyrights, patents or patent applications, or other proprietary 919 rights that may cover technology that may be required to implement 920 this standard. Please address the information to the IETF at 921 ietf-ipr@ietf.org. 923 Acknowledgment 925 Funding for the RFC Editor function is provided by the IETF 926 Administrative Support Activity (IASA).