idnits 2.17.00 (12 Aug 2021) /tmp/idnits911/draft-winterbottom-geopriv-held-context-03.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 858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 869. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 882. 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 (September 29, 2008) is 4982 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 2, 2009 Nokia Siemens Networks 6 M. Thomson 7 Andrew Corporation 8 September 29, 2008 10 HELD Protocol Context Management Extensions 11 draft-winterbottom-geopriv-held-context-03.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 2, 2009. 38 Abstract 40 This document describes a protocol extension for the HTTP Enabled 41 Location Delivery (HELD) protocol. It allows a Target to manage 42 their location information on a Location Information Server (LIS) 43 through the application of constraints invoked by accessing a 44 location URI. Constraints described in this memo restrict how often 45 location can be accessed through a location URI, how long the URI is 46 valid for, and the type of location information returned when a 47 location URI is accessed. Extension points are also provided. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6 56 4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8 59 5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9 60 5.3. Context Response Message . . . . . . . . . . . . . . . . . 10 61 5.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11 62 5.5. Location URI and Context Identifier Generation Rules . . . 12 63 6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 66 8.1. URN Sub-Namespace Registration for 67 urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 18 68 8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 18 69 8.3. New HELD Error Code Registration . . . . . . . . . . . . . 19 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 71 Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 21 72 Appendix B. HELD Compliance to IETF Location Configuration 73 Protocol Location Reference Requirements . . . . . . 23 74 10. Normative References . . . . . . . . . . . . . . . . . . . . . 25 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 76 Intellectual Property and Copyright Statements . . . . . . . . . . 27 78 1. Introduction 80 The HTTP Enabled Location Delivery (HELD) protocol specification 81 [I-D.ietf-geopriv-http-location-delivery] provides a set of features 82 that can be used by a Target to retrieve location information from a 83 Location Information Server (LIS). The basic HELD specification does 84 this in a more or less stateless manner, and when a location URI is 85 retrieved the Target has no way of controlling how the URI is used; a 86 Location Recipient in pocession of the location URI can get the 87 Target's location until the URI expires. This basic mechanism may be 88 reasonable in a limited set of applications, but is unacceptable in a 89 broader range of applications. This position is highlighted in 90 [I-D.ietf-geopriv-lbyr-requirements] which describes requirements for 91 constraints relating to location URIs. This specification provides 92 support for these requirements in HELD. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 This document reuses the terms Target, as defined in [RFC3693]. 102 This document uses the term Location Information Server (LIS) as the 103 node in the access network that provides location information about a 104 Target. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps]. 106 3. What is a Context? 108 A Location URI points to a LIS that is able to provide the location 109 of a specific Target. The LIS is able to map the URI to the location 110 of the Target inside its administrative domain. We call this mapping 111 a "context". In the basic HELD specification the context is 112 implicitly created with the request for a location URI in the 113 locationRequest message. The Target has no control of the mapping 114 from the URI to the Target's location. This specification provides a 115 degree of control to the Target, allowing it to specify rules to the 116 LIS on how a context should map a URI to location information. 118 A context expires when it reaches a certain age, at which time the 119 mapping between the URI and the Target's location ceases. In the 120 basic HELD specification the exiry time of the context is determined 121 by the LIS when the Target requests a location URI. By allowing the 122 Target to specify and change the life time of a context the Target is 123 able to create URIs for limited periods, or to terminate URIs for 124 which it no longer wishes its location to be returned. This 125 specification provides explicit support for this functionality. 127 4. Constraints 129 Constraints restrict the ability of a Location Recipient to resolve a 130 location URI to location information. The constraints are selected 131 by the Target and they are provided to the LIS that maintains them 132 along with the context. A LIS, understanding this specification, 133 receives constraints provided by the Target, and returns a set of 134 URIs influenced by the constraints. 136 A single Target may want to place different contraints on different 137 references and hence may have multiple contexts on the LIS. The 138 constraints describe what actions the LIS MUST take when a URI 139 associated with the context is accessed. This document describes two 140 basic constraints that a Target can use in combination for the same 141 context. Once set, these rules remain in force of the life of the 142 context. 144 4.1. Limited Use URIs 146 A limited use URI can only be accessed a fixed number of times to 147 yield the location of the Target. Each time the URI is used to 148 provide the location of the Target one usage is consumed. Once the 149 limit is reached the URI no longer yields the location of the Target 150 and the URI is deemed spent. 152 By setting the usage limit to 1, the Target is able to create a one- 153 time-URI permitting a Location Recipient to obtain the Target's 154 location only once. Setting the usage limit to something higher than 155 1 creates functionality analogous to a metro-ticket, where a Location 156 Recipient in possession of the URI can access the Target's location 157 many more times, but not exceeding the imposed limit. 159 Not setting a usage limit provides similar semantics to the URI in 160 the base HELD specification, enabling a Location Recipient to 161 continually obtain the Target's location until the URI expires due to 162 age. 164 When a HELD URI is assigned to a context, the limit is the number of 165 times that the URI can be accessed before the LIS returns an error. 166 In the case of SIP or pres URIs it is the number of NOTIFY messages 167 that are sent prior to the LIS returning an error. Where a context 168 supports SIP, pres, and HELD URIs it is the combination of URI 169 accesses and NOTIFY messages that constitutes the usage value, each 170 time the Target's location is provided constitutes a usage. 172 4.2. Snapshot URIs 174 A snapshot URI points to the location of the Target at a specific 175 point in time, and no matter how many times the URI is accessed it 176 will always yield the same location. This is useful if, for example, 177 the Target does not want to be tracked. In this specification the 178 location snapshot to which a snapshot URIs points is captured when 179 the context is created on the LIS. 181 5. Protocol Details 183 This specification introduces three new HELD messages, create context 184 (), update context (), and context 185 response (). A LIS that does not understand this 186 specification is expected to return a HELD _unsupportedMessage_ error 187 code in a HELD error message. A LIS that does understand this 188 specification returns errors associated with context operations in a 189 HELD error message. New error codes relating to failed context 190 operations are defined in this specification. 192 The specification assumes that the LIS was discovered as part of the 193 general HELD LIS discovery process. All messages are sent using the 194 application/held+xml MIME type as defined in 195 [I-D.ietf-geopriv-http-location-delivery]. 197 5.1. Create Context Message 199 The Target creates a context on the LIS using a create context 200 message. The basic create context message supports the constraints 201 described in Section 4 and consist of two attributes and one element 202 described below: 204 o "uses": an optional attribute instructing the LIS on how many 205 times a URI may yield the location of the Target. This is a 206 positive integer, and has a default value of _unlimited_. The LIS 207 SHOULD support the Target specifying up to at least 100 uses. 209 o "snapshot": an optional attribute instructing the LIS to take a 210 snapshot of the Target's location for use with the context. This 211 a boolean value and has a default of _false_ meaning that a 212 snapshot is not taken, and the Target's location is determined 213 each time the URI is accessed. 215 o "lifeTime": is a mandatory element that defines the maximum period 216 in seconds that the LIS should keep the context for. The LIS MAY 217 create the context with a shorter life time than was requested, 218 but the life time MUST NOT be longer than was requested. 220 224 7200 225 227 Figure 1: createContext Example 229 Figure 1 shows a create context message defining a context which: 231 o may be accessed 10 times 233 o will determine the location of the Target each time it is accessed 235 o will be valid for 2 hours from the time of context creation 237 5.2. Update Context Message 239 A Target can change the life time of a context using an update 240 context message. As stated in Section 4 the two attributes used in 241 the context creation, "uses" and "snapshot" cannot be changed once a 242 context is created. 244 Since the Target may have more than one context on the LIS, the 245 Target needs to identify the context to be updated. It does this by 246 including a context identifier that is provided to it by the LIS when 247 the context is created. 249 252 3600 253 255 Figure 2: updateContext Life Time Change Example 257 When a Target includes a life time element in an update context 258 message, the LIS needs to calculate a new context expiry time. The 259 LIS MUST do this by adding the new life time value to the current 260 time on the LIS. This mechanism means the Target can terminate a 261 context at any time. It does this by updating the context with a 262 life time of 0, which results in the LIS setting the context expiry 263 time to the present. The LIS MAY also terminate a context if the 264 life time value is set to less than 10 seconds. 266 269 0 270 272 Figure 3: updateContext Termination Example 274 5.3. Context Response Message 276 The LIS informs the Target about the outcome of context operations 277 through the context response message. The LIS MUST always send a 278 context response message to a Target in response to a create context 279 or update context message when the outcome was successful. The 280 context response message contains a "code" attribute indicating the 281 performed operation, and the other attributes and elements indicating 282 the state of the context. 284 The "code" attribute is an enumerated type and has one of the 285 following values: 287 o _created_: The context was successfully created. 289 o _destroyed_: The context was destroyed. 291 o _updated_: The context was successfully updated. 293 The following list details the other attributes that may be returned 294 in a context response message. 296 id: The identifier allocated to the context by the LIS. This 297 identifier is unique in the scope of the LIS. The Target MUST 298 keep this secret and MUST included it in all update requests. The 299 LIS MUST return an "id" in all context response messages. 301 uses: The number of times that the context will yield the Target's 302 location. The LIS MAY report either the original value, or the 303 number of remaining uses. The LIS MUST report this value for all 304 responses pertaining to a known and valid context. This value MAY 305 be ommitted when indicating that a context has been destroyed. 307 snapshot: The value of the snapshot attribute in the context. The 308 LIS MUST report this value for all responses pertaining to a known 309 and valid context. This value MAY be ommitted when indicating 310 that a context has been destroyed. 312 expiry: The time at which the context will expire. After this time, 313 all location URIs that reference this context no longer work. The 314 LIS MUST report this value for all responses pertaining to a known 315 context. This attribute MUST be provided even when a "code" value 316 of _destroyed_ is included in the context repsonse message. 318 In addition to the above attributes, the LIS also provides a set of 319 URIs that can used to access the Target's location with the surety 320 that the context constraints will be applied. A URI set is returned 321 whenever a context is successfully created on the LIS, and this set 322 remains unchanged for the lifetime of the context. A context 323 response message sent in reply to the create context message in 324 Figure 1 might look like Figure 4. 326 333 334 335 held://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4 336 337 338 sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769 339 340 341 343 Figure 4: contextResponse Example 345 5.4. Context Errors 347 When the LIS is unable to perform the requested context operation it 348 need to inform the Target of this. It does this using a held error 349 message. New codes are defined for context operation errors: 351 o _badContextMessage_: The LIS was unable to understand the content 352 of the message. In general this will apply to context messages 353 containing extensions that the LIS does not understand. 355 o _unknownContext_: The LIS was unable to find the context. 357 o _updateContextFailed_: The LIS was unable to updated the requested 358 context. 360 o _createContextFailed_: The LIS was unable to created the requested 361 context. 363 A Target implementing this specification MUST accept a any HELD error 364 message as a valid response to a create context or update context 365 message as a LIS may not understand context messages. A LIS that 366 does understand context messages is expected to return the error 367 codes above under the prescribed circumstances. 369 373 Figure 5: Example Error Message 375 5.5. Location URI and Context Identifier Generation Rules 377 A primary aim of this specification is to provide a Target a means to 378 cancel a location URI so that it can no longer be used to provide its 379 location. To achieve this, a location URI generated as part of a 380 context creation needs to be unique with in the scope of the LIS, and 381 identify only that context. If the Target destroys a context and 382 subsequently creates a new one, URIs associated the new context MUST 383 be different from those generated for the previous context. 384 [I-D.ietf-geopriv-http-location-delivery] and 385 [I-D.ietf-geopriv-lbyr-requirements] provide guidance on the creation 386 and desired characteristcs of a location URI. 388 The context identifier provided by the LIS to the Target in the 389 context response message MUST be unique and MUST be different from 390 the identifier provided in any location URI, and it MUST NOT be 391 feasible to determine the context-ID from the location URI. This 392 constraint ensures that possession of a location URI does not 393 automatically provide access and control over the internals of the 394 context. It MAY be feasible to determined the location URI knowing 395 the context-ID however. 397 A context identifier is generated by a LIS to uniquely identify a 398 context. It MUST NOT be feasible for a third-party to easily 399 determine a context identifier by knowing the identity of the Target. 400 This implies that internal correlation (using a hash-table or 401 similar) is the only method that the LIS can use to associate a 402 context id with a particular Target. 404 6. XML Schema 406 407 414 415 416 417 418 419 420 422 423 424 425 426 427 428 429 430 432 433 434 435 436 438 440 441 443 445 446 447 448 450 451 452 453 454 456 457 458 459 461 462 463 464 465 467 469 470 472 474 476 478 480 481 482 483 485 486 487 488 489 491 493 494 496 497 498 500 502 503 504 506 508 Figure 6: Context Management Schema 510 7. Security Considerations 512 There are several security concerns associated with the details in 513 this specification. The first is to do with the nature of the 514 sensitivity of any data passed from the Target to the LIS for 515 inclusion in a context. The second is the ability of the LIS to 516 contain the number of contexts that it will permit to exist for a 517 given Target address. Finally, there is a threat of Targets 518 performing DoS attacks on the LIS by trying to create large numbers 519 of short-lived contexts that result in the LIS expending resources in 520 message processing. 522 HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of 523 TLS for exchanges between a Target and the LIS. This is deemed 524 adequate to provide confidentiality to any contextual data in 525 transit. The LIS implementation and the operator of the LIS need to 526 take sufficient steps to ensure that active contextual data on the 527 LIS is not readily available to anyone other than the Target. The 528 Target MUST NOT provide any information to the LIS that it does not 529 want the LIS to know or be able to use in some capacity associated 530 with determination or providing of the Target's location. 532 It is quite conceivable that a LIS will be required to provide 533 location to Targets residing behind a NAT; a DSL home router with 5 534 PCs attached is a good example this situation. In this case it is 535 reasonable for each device to create its own context on the LIS, and 536 for the LIS to treat each context individually even though the LIS 537 cannot make any other distinction between the end hosts; that is, 538 they share a common IP address/identity from the LIS perspective. 540 Given the constraints that can be added to a context and the way that 541 a Target might want to manage expiry separately, a Target may use 542 multiple contexts as a way to isolate applications from each other. 543 For instance, a Target can create a context for each application so 544 that it can revoke access to its location information for each 545 without affecting other applications' access. This environment, 546 however, opens the LIS to a type of denial of service attack through 547 an overload of contexts. It is RECOMMENDED that an implementer of 548 this specification include mechanisms to restrict to the maximum 549 number of contexts that can be created on the LIS by an individual 550 Target. 552 Using short-term location URIs in a carefully controlled manner may 553 obviate the need for individual location authorization policies on 554 the LIS. This leads to reduced LIS complexity and the amount of 555 private information that the Target need share with the LIS. This 556 specification provides the ability for a Target to cancel a location 557 URI which extends the Target's ability to enforce its entitlement to 558 privacy. Using the mechanisms described in this memo a target can 559 create URIs with short validity periods; this restricts how long a 560 third-party is able to obtain the location of the Target while still 561 allowing the Target the convenience of using a location reference. 563 The generation of context identifiers by the LIS is a critical 564 component to supporting the functionality described in this memo. 565 The LIS MUST follow the rules described in Section 5.5 for generating 566 context identifiers. 568 8. IANA Considerations 570 This document registers the schema and associated namespace with 571 IANA. 573 8.1. URN Sub-Namespace Registration for 574 urn:ietf:params:xml:ns:geopriv:held:context 576 This section registers a new XML namespace, 577 "urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines 578 in [RFC3688]. 580 URI: urn:ietf:params:xml:ns:geopriv:held:context 582 Registrant Contact: IETF, GEOPRIV working group, 583 (geopriv@ietf.org), James Winterbottom 584 (james.winterbottom@andrew.com). 586 XML: 588 BEGIN 589 590 592 593 594 HELD Context Management Messages 595 596 597

Namespace for HELD Context Management Messages

598

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

599 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 600 with the RFC number for this specification.]] 601

See RFCXXXX.

602 603 604 END 606 8.2. XML Schema Registration 608 This section registers an XML schema as per the guidelines in 609 [RFC3688]. 611 URI: urn:ietf:params:xml:schema:geopriv:held:context 612 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 613 James Winterbottom (james.winterbottom@andrew.com). 615 Schema: The XML for this schema can be found as the entirety of 616 Figure 6 of this document. 618 8.3. New HELD Error Code Registration 620 Reference: RFC-XXXX (i.e., this document)requires the following new 621 HELD error codes to be added the HELD error code respository defined 622 in [I-D.ietf-geopriv-http-location-delivery]. 624 Error code: badContextMessage 626 Error code: unknownContext 628 Error code: updateContextFailed 630 Error code: createContextFailed 632 9. Acknowledgements 634 Thanks to Adam Muhlbauer and Neil Justusson for their comments on the 635 pre-version of this draft. 637 Thanks also to Tim Zelinski and Michael Diponio , who pointed out a 638 problems while implementing an early revision of this specification. 640 Appendix A. Context Extensions 642 A context contains specific information about a Target and is stored 643 on the LIS. As with other protocols it is necessary to consider 644 extensibility. When defining context data extensions it is necessary 645 to consider how they will be used; this includes not only how to 646 provide the information from the Target to the LIS, but also 647 acceptance and error indications from the LIS back to the Target. 648 For example, a context may be created with several extensions 649 included, how does the LIS indicate that extensions 1 and 3 were 650 successful but that extension 2 had a problem in its formatting? 651 Guidelines for designing context extensions that provide 652 functionality are described below. 654 Two basic types of context data extension are envisioned. The first 655 consist of data provided by the Target to be consumed by the LIS; for 656 example information pertaining to PIDF-LO construction, usage-rules, 657 and authorization policies. The second type of data consists of a 658 two way exchange between the Target and the LIS; for example 659 exchanging location determination capabilities. Extensibility to the 660 context scheme is to allow additional elements to be added to the 661 context easily. The general idea is shown in Figure 7. 663 665 7200 666 668 7200 669 670 671 672 . 673 . 674 . 675 676 678 Figure 7: Create Context with Extensions 680 When defining a context data extension it is necessary to ensure that 681 the LIS can provide an adequate response to the Target indicating 682 acceptance or rejection of the data provided. This may be an 683 explicit OK or FAIL message within the extension namespace, it may be 684 an attribute associated with part of a larger data exchange, or it 685 may result in the LIS failing to create the context at all. 686 Regardless, it is mandatory for a context data extension to provide 687 an indication of success or failure. 689 696 697 698 held//ls.example.com:9768/357yc6s64ceyoiuy5ax3o 699 700 701 sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769 702 703 704 706 709 711 data 712 guff in here for extension 713 714 716 Figure 8: LIS response to createContext 718 When defining information to be included in a context data extension 719 consideration should be given to how that data can be removed from 720 the context. In some cases it may be necessary to void the context 721 on the LIS in order to remove information, but this SHOULD be treated 722 as a last resort and not used as the primary mechanism for removing 723 data from the context. 725 Appendix B. HELD Compliance to IETF Location Configuration Protocol 726 Location Reference Requirements 728 This section describes how HELD and this specification comply to the 729 LCP location reference requirements stipulated in 730 [I-D.ietf-geopriv-lbyr-requirements]. 732 High-level requirements for a location configuration protocol. 734 C1. "Location URI support - LCP: The configuration protocol MUST 735 support a location reference in URI form." 737 COMPLY. HELD only provides location references in URI form. 739 C2. "Location URI expiration: The LCP MUST support the ability to 740 specify to the server, the length of time that a location URI 741 will be valid." 743 COMPLY. HELD with the context management extensions described 744 in this document provide the Target the ability to specify 745 expiry times for location URIs. 747 C3. "Location URI cancellation: The LCP MUST support the ability to 748 request a cancellation of a specific location URI." 750 COMPLY. HELD with the context management extensions described 751 in this document provide the Target the ability to void location 752 URIs when required. 754 C4. "Random Generated: The location URI MUST be hard to guess, i.e., 755 it MUST contain a cryptographically random component." 757 COMPLY. The HELD specification and this document provide 758 specific guidance on the security surrounding location URI 759 generation. 761 C5. "Identity Protection - LCP: The location URI MUST NOT contain 762 any information that identifies the user, device or address of 763 record within the URI form." 764 COMPLY. The HELD specification and this document provide 765 specific guidance on the anonymity of the Target with regards to 766 the generation of location URIs. 768 C6. "Reuse flag default: The LCP MUST support the default condition 769 of a requested location URI being repeatedly reused." 771 COMPLY. HELD with the context management extensions described 772 in this document provide the Target the ability to specify how 773 many times a location URI may yield the location of Target. 775 C7. "One-time-use: The LCP MUST support the ability for the client 776 to request a 'one-time-use' location URI (e.g., via a reuse flag 777 setting)." 779 COMPLY. HELD with the context management extensions described 780 in this document provide the Target the ability to specify how 781 many times a location URI may yield the location of Target. 782 This value may be set to 1 to create a one-time URI. 784 10. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, March 1997. 789 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 790 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 792 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 793 January 2004. 795 [I-D.ietf-geopriv-http-location-delivery] 796 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 797 "HTTP Enabled Location Delivery (HELD)", 798 draft-ietf-geopriv-http-location-delivery-09 (work in 799 progress), September 2008. 801 [I-D.ietf-geopriv-l7-lcp-ps] 802 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 803 Location Configuration Protocol; Problem Statement and 804 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 805 progress), June 2008. 807 [I-D.ietf-geopriv-lbyr-requirements] 808 Marshall, R., "Requirements for a Location-by-Reference 809 Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work 810 in progress), July 2008. 812 Authors' Addresses 814 James Winterbottom 815 Andrew Corporation 816 PO Box U40 817 University of Wollongong, NSW 2500 818 AU 820 Phone: +61 242 212938 821 Email: james.winterbottom@andrew.com 822 URI: http://www.andrew.com/products/geometrix 824 Hannes Tschofenig 825 Nokia Siemens Networks 826 Linnoitustie 6 827 Espoo 02600 828 Finland 830 Phone: +358 (50) 4871445 831 Email: Hannes.Tschofenig@gmx.net 832 URI: http://www.tschofenig.priv.at 834 Martin Thomson 835 Andrew Corporation 836 PO Box U40 837 University of Wollongong, NSW 2500 838 AU 840 Phone: +61 242 212915 841 Email: martin.thomson@andrew.com 842 URI: http://www.andrew.com/products/geometrix 844 Full Copyright Statement 846 Copyright (C) The IETF Trust (2008). 848 This document is subject to the rights, licenses and restrictions 849 contained in BCP 78, and except as set forth therein, the authors 850 retain all their rights. 852 This document and the information contained herein are provided on an 853 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 854 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 855 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 856 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 857 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 858 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 860 Intellectual Property 862 The IETF takes no position regarding the validity or scope of any 863 Intellectual Property Rights or other rights that might be claimed to 864 pertain to the implementation or use of the technology described in 865 this document or the extent to which any license under such rights 866 might or might not be available; nor does it represent that it has 867 made any independent effort to identify any such rights. Information 868 on the procedures with respect to rights in RFC documents can be 869 found in BCP 78 and BCP 79. 871 Copies of IPR disclosures made to the IETF Secretariat and any 872 assurances of licenses to be made available, or the result of an 873 attempt made to obtain a general license or permission for the use of 874 such proprietary rights by implementers or users of this 875 specification can be obtained from the IETF on-line IPR repository at 876 http://www.ietf.org/ipr. 878 The IETF invites any interested party to bring to its attention any 879 copyrights, patents or patent applications, or other proprietary 880 rights that may cover technology that may be required to implement 881 this standard. Please address the information to the IETF at 882 ietf-ipr@ietf.org.