idnits 2.17.1 draft-winterbottom-geopriv-held-context-02.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 899. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 923. 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 (February 20, 2008) is 5882 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: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-04 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-06 ** Downref: Normative reference to an Informational draft: draft-ietf-geopriv-l7-lcp-ps (ref. 'I-D.ietf-geopriv-l7-lcp-ps') == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-01 ** 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: August 23, 2008 Nokia Siemens Networks 6 M. Thomson 7 Andrew Corporation 8 February 20, 2008 10 HELD Protocol Context Management Extensions 11 draft-winterbottom-geopriv-held-context-02.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 August 23, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 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 Errors . . . . . . . . . . . . . . . . . . . . . . 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 8.3. New HELD Error Code Registration . . . . . . . . . . . . . 20 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 76 Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22 77 Appendix B. HELD Compliance to IETF Location Configuration 78 Protocol Location Reference Requirements . . . . . . 24 79 10. Normative References . . . . . . . . . . . . . . . . . . . . . 26 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 81 Intellectual Property and Copyright Statements . . . . . . . . . . 28 83 1. Introduction 85 The HTTP Enabled Location Delivery (HELD) protocol specification 86 [I-D.ietf-geopriv-http-location-delivery] provides a set of features 87 that can be used by a Target to retrieve location information from a 88 Location Information Server (LIS). The basic HELD specification does 89 this in a more or less stateless manner, and when a location URI is 90 retrieved the Target has no way of controlling how the URI is used; a 91 Location Recipient in pocession of the location URI can get the 92 Target's location until the URI expires. This basic mechanism may be 93 reasonable in a limited set of applications, but is unacceptable in a 94 broader range of applications. This position is highlighted in 95 [I-D.ietf-geopriv-lbyr-requirements] which describes requirements for 96 constraints relating to location URIs. This specification provides 97 support for these requirements in HELD. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 This document reuses the terms Target, as defined in [RFC3693]. 107 This document uses the term Location Information Server (LIS) as the 108 node in the access network that provides location information about a 109 Target. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps]. 111 3. What is a Context? 113 A Location URI points to a LIS that is able to provide the location 114 of a specific Target. The LIS is able to map the URI to the location 115 of the Target inside its administrative domain. We call this mapping 116 a "context". In the basic HELD specification the context is 117 implicitly created with the request for a location URI in the 118 locationRequest message. The Target has no control of the mapping 119 from the URI to the Target's location. This specification provides a 120 degree of control to the Target, allowing it to specify rules to the 121 LIS on how a context should map a URI to location information. 123 A context expires when it reaches a certain age, at which time the 124 mapping between the URI and the Target's location ceases. In the 125 basic HELD specification the exiry time of the context is determined 126 by the LIS when the Target requests a location URI. By allowing the 127 Target to specify and change the life time of a context the Target is 128 able to create URIs for limited periods, or to terminate URIs for 129 which it no longer wishes its location to be returned. This 130 specification provides explicit support for this functionality. 132 4. Constraints 134 Constraints restrict the ability of a Location Recipient to resolve a 135 location URI to location information. The constraints are selected 136 by the Target and they are provided to the LIS that maintains them 137 along with the context. A LIS, understanding this specification, 138 receives constraints provided by the Target, and returns a set of 139 URIs influenced by the constraints. 141 A single Target may want to place different contraints on different 142 references and hence may have multiple contexts on the LIS. The 143 constraints describe what actions the LIS MUST take when a URI 144 associated with the context is accessed. This document describes 145 three basic constraints that a Target can use in combination for the 146 same context. Once set, these rules remain in force of the life of 147 the context. 149 4.1. Limited Use URIs 151 A limited use URI can only be accessed a fixed number of times to 152 yield the location of the Target. Each time the URI is used to 153 provide the location of the Target one usage is consumed. Once the 154 limit is reached the URI no longer yields the location of the Target 155 and the URI is deemed spent. 157 By setting the usage limit to 1, the Target is able to create a one- 158 time-URI permitting a Location Recipient to obtain the Target's 159 location only once. Setting the usage limit to something higher than 160 1 creates functionality analogous to a metro-ticket, where a Location 161 Recipient in possession of the URI can access the Target's location 162 many more times, but not exceeding the imposed limit. 164 Not setting a usage limit provides similar semantics to the URI in 165 the base HELD specification, enabling a Location Recipient to 166 continually obtain the Target's location until the URI expires due to 167 age. 169 When a HELD URI is assigned to a context, the limit is the number of 170 times that the URI can be accessed before the LIS returns an error. 171 In the case of SIP or pres URIs it is the number of NOTIFY messages 172 that are sent prior to the LIS returning an error. Where a context 173 supports SIP, pres, and HELD URIs it is the combination of URI 174 accesses and NOTIFY messages that constitutes the usage value, each 175 time the Target's location is provided constitutes a usage. 177 4.2. Snapshot URIs 179 A snapshot URI points to the location of the Target at a specific 180 point in time, and no matter how many times the URI is accessed it 181 will always yield the same location. This is useful if, for example, 182 the Target does not want to be tracked. In this specification the 183 location snapshot to which a snapshot URIs points is captured when 184 the context is created on the LIS. 186 4.3. Location Type URIs 188 A location type URI controls the form of location that can be 189 accessed; This may be geodetic, civic, or both. 191 5. Protocol Details 193 This specification introduces three new HELD messages, create context 194 (), update context (), and context 195 response (). A LIS that does not understand this 196 specification is expected to return a HELD _unsupportedMessage_ error 197 code in a HELD error message. A LIS that does understand this 198 specification returns errors associated with context operations in a 199 HELD error message. New error codes relating to failed context 200 operations are defined in this specification. 202 The specification assumes that the LIS was discovered as part of the 203 general HELD LIS discovery process. All messages are sent using the 204 application/held+xml MIME type as defined in 205 [I-D.ietf-geopriv-http-location-delivery]. 207 5.1. Create Context Message 209 The Target creates a context on the LIS using a create context 210 message. The basic create context message supports the constraints 211 described in Section 4 and consist of three attributes and one 212 element described below: 214 o "uses": an optional attribute instructing the LIS on how many 215 times a URI may yield the location of the Target. This is a 216 positive integer, and has a default value of _unlimited_. The LIS 217 SHOULD support the Target specifying up to at least 100 uses. 219 o "snapshot": an optional attribute instructing the LIS to take a 220 snapshot of the Target's location for use with the context. This 221 a boolean value and has a default of _false_ meaning that a 222 snapshot is not taken, and the Target's location is determined 223 each time the URI is accessed. 225 o "locationType": an optional attribute instructing the LIS on the 226 form of location that the URI MUST return. This is an enumeration 227 and may have a value of _geodetic_, _civic_, or _any_. If 228 unspecified by the Target the LIS will use a value of _any_. If 229 the Target specifies a location type that the LIS cannot provide, 230 then the LIS MUST fail the context creation. 232 o "lifeTime": is a mandatory element that defines the maximum period 233 in seconds that the LIS should keep the context for. The LIS MAY 234 create the context with a shorter life time than was requested, 235 but the life time MUST NOT be longer than was requested. 237 242 7200 243 245 Figure 1: createContext Example 247 Figure 1 shows a create context message defining a context which: 249 o may be accessed 10 times 251 o will determine the location of the Target each time it is accessed 253 o will return the location in either geodetic or civic form 254 depending on the request to the URI 256 o will be valid for 2 hours from the time of context creation 258 5.2. Update Context Message 260 A Target can change the life time of a context using an update 261 context message. As stated in Section 4 the three attributes used in 262 the context creation, "uses", "snapshot", and "locationType" cannot 263 be changed once a context is created. 265 Since the Target may have more than one context on the LIS, the 266 Target needs to identify the context to be updated. It does this by 267 including a context identifier that is provided to it by the LIS when 268 the context is created. 270 273 3600 274 276 Figure 2: updateContext Life Time Change Example 278 When a Target includes a life time element in an update context 279 message, the LIS needs to calculate a new context expiry time. The 280 LIS MUST do this by adding the new life time value to the current 281 time on the LIS. This mechanism means the Target can terminate a 282 context at any time. It does this by updating the context with a 283 life time of 0, which results in the LIS setting the context expiry 284 time to the present. The LIS MAY also terminate a context if the 285 life time value is set to less than 10 seconds. 287 290 0 291 293 Figure 3: updateContext Termination Example 295 5.3. Context Response Message 297 The LIS informs the Target about the outcome of context operations 298 through the context response message. The LIS MUST always send a 299 context response message to a Target in response to a create context 300 or update context message when the outcome was successful. The 301 context response message contains a "code" attribute indicating the 302 performed operation, and the other attributes and elements indicating 303 the state of the context. 305 The "code" attribute is an enumerated type and has one of the 306 following values: 308 o _created_: The context was successfully created. 310 o _destroyed_: The context was destroyed. 312 o _updated_: The context was successfully updated. 314 The following list details the other attributes that may be returned 315 in a context response message. 317 id: The identifier allocated to the context by the LIS. This 318 identifier is unique in the scope of the LIS. The Target MUST 319 keep this secret and MUST included it in all update requests. The 320 LIS MUST return an "id" in all context response messages. 322 uses: The number of times that the context will yield the Target's 323 location. The LIS MAY report either the original value, or the 324 number of remaining uses. The LIS MUST report this value for all 325 responses pertaining to a known and valid context. This value MAY 326 be ommitted when indicating that a context has been destroyed. 328 snapshot: The value of the snapshot attribute in the context. The 329 LIS MUST report this value for all responses pertaining to a known 330 and valid context. This value MAY be ommitted when indicating 331 that a context has been destroyed. 333 locationType: The type of location information that can be acquired 334 through URIs addressing the context. The LIS MUST report this 335 value for all responses pertaining to a known and valid context. 336 This value MAY be omitted when indicating that a context has been 337 destroyed. 339 expiry: The time at which the context will expire. After this time, 340 all location URIs that reference this context no longer work. The 341 LIS MUST report this value for all responses pertaining to a known 342 context. This attribute MUST be provided even when a "code" value 343 of _destroyed_ is included in the context repsonse message. 345 In addition to the above attributes, the LIS also provides a set of 346 URIs that can used to access the Target's location with the surety 347 that the context constraints will be applied. A URI set is returned 348 whenever a context is successfully created on the LIS, and this set 349 remains unchanged for the lifetime of the context. A context 350 response message sent in reply to the create context message in 351 Figure 1 might look like Figure 4. 353 361 362 363 held://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4 364 365 366 sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769 367 368 369 371 Figure 4: contextResponse Example 373 5.4. Context Errors 375 When the LIS unable to perform the requested context operation it 376 need to inform the Target of this. It does this using a held error 377 message. New codes are defined for context operation errors: 379 o _badContextMessage_: The LIS was unable to understand the content 380 of the message. In general this will apply to context messages 381 containing extensions that the LIS does not understand. 383 o _unknownContext_: The LIS was unable to find the context. 385 o _updateContextFailed_: The LIS was unable to updated the requested 386 context. 388 o _createContextFailed_: The LIS was unable to created the requested 389 context. 391 A Target implementing this specification MUST accept a any HELD error 392 message as a valid response to a create context or update context 393 message as a LIS may not understand context messages. A LIS that 394 does understand context messages is expected to return the error 395 codes above unde the prescribed circumstances. 397 401 Figure 5: Example Error Message 403 5.5. Location URI and Context Identifier Generation Rules 405 A primary aim of this specification is to provide a Target a means to 406 cancel a location URI so that it can no longer be used to provide its 407 location. To achieve this, a location URI generated as part of a 408 context creation needs to be unique with in the scope of the LIS, and 409 identify only that context. If the Target destroys a context and 410 subsequently creates a new one, URIs associated the new context MUST 411 be different from those generated for the previous context. 412 [I-D.ietf-geopriv-http-location-delivery] and 413 [I-D.ietf-geopriv-lbyr-requirements] provide guidance on the creation 414 and desired characteristcs of a location URI. 416 The context identifier provided by the LIS to the Target in the 417 context response message MUST be unique and MUST be different from 418 the identifier provided in any location URI, and it MUST NOT be 419 feasible to determine the context-ID from the location URI. This 420 constraint ensures that possession of a location URI does not 421 automatically provide access and control over the internals of the 422 context. It MAY be feasible to determined the location URI knowing 423 the context-ID however. 425 A context identifier is generated by a LIS to uniquely identify a 426 context. It MUST NOT be feasible for a third-party to easily 427 determine a context identifier by knowing the identity of the Target. 428 This implies that internal correlation (using a hash-table or 429 similar) is the only method that the LIS can use to associate a 430 context id with a particular Target. 432 6. XML Schema 434 435 442 443 444 445 446 447 448 450 451 452 453 454 455 456 458 459 460 461 462 463 464 465 466 468 469 470 471 472 474 476 477 480 482 484 485 486 487 489 490 491 492 493 495 496 497 498 500 501 502 503 504 506 508 509 511 513 515 517 519 521 522 523 524 526 527 528 529 530 532 534 535 537 538 539 540 542 543 544 546 548 Figure 6: Context Management Schema 550 7. Security Considerations 552 There are several security concerns associated with the details in 553 this specification. The first is to do with the nature of the 554 sensitivity of any data passed from the Target to the LIS for 555 inclusion in a context. The second is the ability of the LIS to 556 contain the number of contexts that it will permit to exist for a 557 given Target address. Finally, there is a threat of Targets 558 performing DoS attacks on the LIS by trying to create large numbers 559 of short-lived contexts that result in the LIS expending resources in 560 message processing. 562 HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of 563 TLS for exchanges between a Target and the LIS. This is deemed 564 adequate to provide confidentiality to any contextual data in 565 transit. The LIS implementation and the operator of the LIS need to 566 take sufficient steps to ensure that active contextual data on the 567 LIS is not readily available to anyone other than the Target. The 568 Target MUST NOT provide any information to the LIS that it does not 569 want the LIS to know or be able to use in some capacity associated 570 with determination or providing of the Target's location. 572 It is quite conceivable that a LIS will be required to provide 573 location to Targets residing behind a NAT; a DSL home router with 5 574 PCs attached is a good example this situation. In this case it is 575 reasonable for each device to create its own context on the LIS, and 576 for the LIS to treat each context individually even though the LIS 577 cannot make any other distinction between the end hosts; that is, 578 they share a common IP address/identity from the LIS perspective. 580 Given the constraints that can be added to a context and the way that 581 a Target might want to manage expiry separately, a Target may use 582 multiple contexts as a way to isolate applications from each other. 583 For instance, a Target can create a context for each application so 584 that it can revoke access to its location information for each 585 without affecting other applications' access. This environment, 586 however, opens the LIS to a type of denial of service attack through 587 an overload of contexts. It is RECOMMENDED that an implementer of 588 this specification include mechanisms to restrict to the maximum 589 number of contexts that can be created on the LIS by an individual 590 Target. 592 Using short-term location URIs in a carefully controlled manner may 593 obviate the need for individual location authorization policies on 594 the LIS. This leads to reduced LIS complexity and the amount of 595 private information that the Target need share with the LIS. This 596 specification provides the ability for a Target to cancel a location 597 URI which extends the Target's ability to enforce its entitlement to 598 privacy. Using the mechanisms described in this memo a target can 599 create URIs with short validity periods; this restricts how long a 600 third-party is able to obtain the location of the Target while still 601 allowing the Target the convenience of using a location reference. 603 The generation of context identifiers by the LIS is a critical 604 component to supporting the functionality described in this memo. 605 The LIS MUST follow the rules described in Section 5.5 for generating 606 context identifiers. 608 8. IANA Considerations 610 This document registers the schema and associated namespace with 611 IANA. 613 8.1. URN Sub-Namespace Registration for 614 urn:ietf:params:xml:ns:geopriv:held:context 616 This section registers a new XML namespace, 617 "urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines 618 in [RFC3688]. 620 URI: urn:ietf:params:xml:ns:geopriv:held:context 622 Registrant Contact: IETF, GEOPRIV working group, 623 (geopriv@ietf.org), James Winterbottom 624 (james.winterbottom@andrew.com). 626 XML: 628 BEGIN 629 630 632 633 634 HELD Context Management Messages 635 636 637

Namespace for HELD Context Management Messages

638

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

639 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 640 with the RFC number for this specification.]] 641

See RFCXXXX.

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